讓我們從使用TokuDB的背景說起。

這幅圖層現(xiàn)了當(dāng)前我們大部分的游戲架構(gòu)，今天要討論的角色在左下角—logdb，logdb(又叫tlog)，顧名思義，存儲的是玩家的一些流水日志，譬如，登陸/登出；購買的道具記錄等。

非技術(shù)的現(xiàn)狀：

1. 隨著游戲的運(yùn)營策劃，拉新留存，不斷滾服，不同區(qū)服在線不均，導(dǎo)致資源浪費(fèi)；

2. 策劃希望保留更多的數(shù)據(jù)，X業(yè)務(wù)單區(qū)甚至能達(dá)到 2T。

技術(shù)的現(xiàn)狀：

1. 采用InnoDB，一般是游戲大區(qū)：Tlog = 1:1；存儲的硬件成本高；

2. 采用MyISAM，雖然能節(jié)省一半空間，但無法在線加字段，而加字段的變更又是占游戲日常變更的大塊頭。

TokuDB:InnoDB  = 1:10

TokuDB:MyISAM = 1:5

MyISMA:InnoDB  = 1:2

這是一組經(jīng)驗數(shù)據(jù)。

2015年上半年，當(dāng)時部門正在搞成本優(yōu)化，借著這把火，我們發(fā)起了一個項目，叫：端游Tlog成本優(yōu)化。以項目的方式，以TokuDB為技術(shù)，以業(yè)務(wù)的訴求為基礎(chǔ)，按KPI驅(qū)動，逐步建設(shè)，逐步迭代，快速落地。

目前接入TokuDB的業(yè)務(wù)20+，實例200+。

這幅圖是我們最開始推動接入TokuDB的5個業(yè)務(wù)，節(jié)省機(jī)器數(shù) 150臺，按照tlog機(jī)型每個月運(yùn)營成本980/月，這5個業(yè)務(wù)每個月也可以節(jié)省15萬。也許這是技術(shù)變現(xiàn)的另一層意思。

接下來我們正式介紹下TokuDB。

TokuDB作為MySQL的一個存儲引擎，業(yè)務(wù)側(cè)不需要修改任何代碼，開發(fā)可以像使用InnoDB一樣選擇TokuDB。它有如下幾個優(yōu)點：

上線現(xiàn)網(wǎng)前我們對TokuDB進(jìn)行了一些調(diào)研，主要包括：

1. 高壓縮比

2. 查詢

3. 更新

4. 業(yè)務(wù)查詢

5. 業(yè)務(wù)入庫

第4、5是我們基于tlog業(yè)務(wù)個性化的考慮出發(fā)的。

我們先看下TokuDB為人稱道的高壓縮特性。

這是我們從現(xiàn)網(wǎng)來的一組壓縮數(shù)據(jù)。

TokuDB之所以比InnoDB有較高的壓縮優(yōu)勢，可能原因有：

1. TokuDB默認(rèn)塊大小為4M，更適合壓縮。

2. InnoDB需要將壓縮后的數(shù)據(jù)pad到固定大小的padding 空間里，這會降低所能達(dá)到的壓縮效果，而TokuDB是unpadded。

3. InnoDB可能存在碎片，而TokuDB沒有這個問題。

關(guān)于壓力測試，我們使用的工具是自研的test_server：

查詢的測試SQL：SELECT id FROM test.big_tb WHERE id=  ?

原地更新的測試SQL：update test.big_tb set col1=col1+1 whereid = ?

非原地更新的測試SQL：update test.sml_tb set col13 =substr(sha1(rand()), 1, ceil(rand()*8)) where id = ?

首先是select。

MySQL配置

innodb_buffer_pool_size=15G

innodb_flush_log_at_trx_commit=0

sync_binlog=0

row_format=lz_ma(TokuDB)

tokudb_cache_size=15G

全cache

row 2000000 innodb 2.4G  tokudb 20M

非全cache

row 40000000 innodb 48G  tokudb 754M

結(jié)論：

1. 全cache下TokuDB是InnoDB的2/3

2. 非全cache同等數(shù)據(jù)用tokudb后只有754M，所以tokudb 內(nèi)存能緩存大部分?jǐn)?shù)據(jù)下，TokuDB幾乎是InnoDB的10倍

其次是更新。

MySQL配置

innodb_buffer_pool_size=15G

innodb_flush_log_at_trx_commit=0

sync_binlog=0

row_format=lz_ma(TokuDB)

tokudb_cache_size=15G

全cache

row 2000000 innodb 2.4G  tokudb 20M

非全cache

row 40000000 innodb 48G  tokudb 754M

結(jié)論：

1. 全cache下無論原地更新或非原地更新對于TokuDB的表現(xiàn)均無太大差別

2. 全cache下原地更新TokuDB是InnoDB的1/2,非原地更新TokuDB是InnoDB的2/3 

3. 非全cache同等數(shù)據(jù)用tokudb后只有754M，所以tokudb 內(nèi)存能緩存大部分?jǐn)?shù)據(jù)下，無論原地更新或非原地更新，InnoDB是TokuDB的1/5 

同時，我們也回放了現(xiàn)網(wǎng)tlog的查詢模式。

現(xiàn)網(wǎng)回放的Top 7 SQL屬于范圍查詢，而范圍查詢 TokuDB的表現(xiàn)要優(yōu)于InnoDB。

根據(jù)前面的壓力測試環(huán)節(jié)，可以看出，TokuDB優(yōu)勢在于壓縮和范圍查詢，點查詢不是他的優(yōu)勢所在。所以，稍微總結(jié)下，建議TokuDB的應(yīng)用場景如下：

說完壓測，接下來我們討論下踩坑的正確姿勢。

第1個坑。

來自TMySQL用戶，包括很多開發(fā)和GCS系統(tǒng)，都習(xí)慣mysql –u$USER –p$PASSWD 來執(zhí)行，這條命令在MySQL 5.6會有個warning告警：

單據(jù)或者腳本解析到這個warning，則全部失敗。

所以，為了向前兼容，我們在源碼層面將這個warn關(guān)閉。

看第2個坑。

一般MySQL的升級方法包括：

1. 導(dǎo)入導(dǎo)出

2. 做一個slave

3. 原地升級

根據(jù)數(shù)據(jù)量大小，如果100G內(nèi)的，我們一般選擇原地升級。

某天在某個高星級業(yè)務(wù)上業(yè)務(wù)運(yùn)維發(fā)現(xiàn)TokuDB的加字段很慢。

TokuDB無法在線加字段的條件：

1. 原地升級

2. 表含有數(shù)據(jù)

3. 表含有時間字段

TokuDB無法在線加字段的原因：

MySQL 5.6.4在Server層新增三種時間類型MYSQL_TYPE_TIME2，MYSQL_TYPE_DATETIME2，MYSQL_TYPE_TIMESTAMP2，并在InnoDB層以二進(jìn)制的格式存儲，用這種方式來實現(xiàn)時間類型支持小數(shù)精度并優(yōu)化存儲節(jié)省空間。如果直接使用加字段操作，alter table t1 add c1 int。  

對MySQL 5.6中，通常情形下加字段的隱式行為是走的online ddl，即ALGORITHM=INPLACE。 如若t1滿足上述3個條件，該SQL則隱式走ALGORITHM=COPY，即非在線加字段的邏輯。因此，在系統(tǒng)默認(rèn)行為下，通過原地升級過來的舊版本MySQL時間類型會妨礙后續(xù)的online ddl行為。

修復(fù)的方式有2個：

1. alter table force，這種方式需要拷貝數(shù)據(jù)，成本太高。

2. avoid_temporal_upgrade 把這個參數(shù)打開即可，很贊，建議使用這種方式。

接下來看第3個坑。

某天有開發(fā)投訴，數(shù)據(jù)入庫延遲嚴(yán)重，導(dǎo)致統(tǒng)計任務(wù)失敗，重跑成本極高。

TokuDB官方宣稱Load DATA比InnoDB強(qiáng)；并且我們在預(yù)研階段也驗證過的確如此，BUT WHY ？？

查閱文檔發(fā)現(xiàn)，原來是使用的姿勢不對，Load DATA帶不帶local關(guān)鍵字區(qū)別很大。

有無local走的協(xié)議不同，有l(wèi)ocal，則是通過client讀取后發(fā)送給server；無local，便是server直接讀取。

下面看第4個坑。

現(xiàn)網(wǎng)TokuDB的部署策略是1:2或1:4個大區(qū)共用1個實例，正如這幅圖所展示的：

淘寶的MySQL內(nèi)核月報提到TokuDB 分區(qū)表文件數(shù)目計算公式： 分區(qū)數(shù)目 * (1 + 1 + 索引數(shù)目)，這么一算，fd不夠用也就有理有據(jù)了，因為fd是進(jìn)程級別的，所以我們只要進(jìn)行如下調(diào)整即可。

這是我們現(xiàn)網(wǎng)TokuDB實例上架的參數(shù)。

這個坑是業(yè)務(wù)運(yùn)維的兄弟發(fā)現(xiàn)的，他們在查詢時DB經(jīng)常報：MySQL GONE AWAY。

接下來是最后一個坑。

數(shù)據(jù)安全是DBA的生命線，隨著運(yùn)營數(shù)據(jù)的與日俱增，邏輯備份壓力越來越大。我們對比了業(yè)界的2種方案：

為了便于內(nèi)部系統(tǒng)集成，我們采用阿里的方案。

TokuDB物理備份的步驟：

1. 連接mysql，設(shè)置SET TOKUDB_CHECKPOINT_LOCK=ON;

2. 加只讀鎖FLUSH TABLES WITH READ LOCK;

3. 獲取binlog位置，

4. 拷貝tokudb的redolog和一些元數(shù)據(jù)文件（tokudb.****）

5. 釋放只讀鎖UNLOCK TABLES;

6. 拷貝tokudb的數(shù)據(jù)文件和表結(jié)構(gòu)

7. 釋放checkpoint鎖，SET TOKUDB_CHECKPOINT_LOCK=OFF;

但我們發(fā)現(xiàn)，TokuDB把所有的數(shù)據(jù)文件的路徑都寫死了，這樣不同實例跨端口的恢復(fù)就不會報錯。

tokuftdump解析tokudb.directory：

從解析的內(nèi)容可以看出，每個記錄都是一個key，一個value，key就是對應(yīng)的表名，value就是數(shù)據(jù)文件的路徑，tokudb把所有的數(shù)據(jù)文件的路徑寫死，這樣的話恢復(fù)到不同路徑的話當(dāng)然就會報錯。

我們TMySQL 2.x對這個“bug”做了修復(fù)，使directory文件中只存相對路徑，然后和數(shù)據(jù)文件的路徑拼出完整的路徑。

修復(fù)解析的內(nèi)容如下：

至此備份的坑也就解決了。

Q1： Toku的缺點主要有哪些，因為目前innondb還是大量在使用，能否指點一二?

A1：缺點可以從壓力測試的數(shù)據(jù)看下，主要是點查詢比InnoDB差。

Q2：Tokudb的range query比innodb 好？還有原因是cache 命中高嗎？

A2：從我們測試來看，TokuDB的范圍查詢比InnoDB要好；TokuDB能緩存大部分?jǐn)?shù)據(jù)可能是一個原因；不過當(dāng)我們把tokudb的內(nèi)存參數(shù)調(diào)得比數(shù)據(jù)要小一點的時候，TokuDB的范圍查詢?nèi)匀槐菼nnoDB要高一點。

Q3：阿里備份與percona備份有沒詳細(xì)一點的對比?

A3：第一個是官方提供的方案——https://www./blog/2015/02/05/tokudb-hot-backup-now-mysql-plugin/。簡單來說這個方案是做了一個插件，加載了一個so，攔截所有有關(guān)于文件的系統(tǒng)調(diào)用，然后一邊復(fù)制一邊將改動同時應(yīng)用到拷貝上去。

第二個是阿里提供的方案——http://mysql./monthly/2015/12/06/，這個方案聽起來相對簡單，只要加鎖然后拷貝文件就可以了。

Q4：方便的話請介紹一下硬件的配置，cpu (壓縮算法對cpu 的要求），磁盤方面參數(shù)。

A4：我們tlog機(jī)型剛剛在背景那塊稍微提了下，配置不是很高。

Q5：在這配置下，生產(chǎn)最高的QPS,TPS是多少，CPU user是多少？

A5：目前我們TokuDB大部分是在Tlog業(yè)務(wù)應(yīng)用，而Tlog的查詢不會太高，主要是周邊系統(tǒng)拉取的，所以QPS這個指標(biāo)我們之前不是很關(guān)注；這個之前我們采集的某高星級業(yè)務(wù)整點高峰的性能數(shù)據(jù)。

作者介紹  林水彬

• 目前就職于騰訊，主要工作包括MYSQL、Hadoop以及自動化平臺建設(shè)；

• TPUB版主，CSDN社區(qū)技術(shù)專家。