TokuMX使用小計

最近因為工作的緣故，接觸了TokuMX，嘗試下來感覺不錯，值得介紹給大家。 事情的起因是要解決MongoDB的問題。系統中需要保存程序輸出的運行信息，這類信息比程序語言的log更高級，但又不如業務操作日志高級，是某些時候發現問題的關鍵證據，所以必須保存。因

最近因為工作的緣故，接觸了TokuMX，嘗試下來感覺不錯，值得介紹給大家。

事情的起因是要解決MongoDB的問題。系統中需要保存程序輸出的運行信息，這類信息比程序語言的log更高級，但又不如業務操作日志高級，是某些時候發現問題的關鍵證據，所以必須保存。因為格式不太規范，又需要方便檢索，所以文檔型NoSQL的MongoDB是比較好的選擇。

但是，選擇MongoDB就必然會面對磁盤空間的問題。我們的數據大概是這樣的：每天的數據量不到200萬條，單條數據的平均大小不超過4k，但MongoDB存一個月的數據就消耗了接近40G，最近三個月的數據則需要接近100G。限于具體的硬件環境，只能保存最近三個月的數據，但這無法滿足業務需求，所以必須另想辦法。

最終我們選定的方案是TokuMX。它是一款開源的、高性能的MongoDB發布（distribution），在提供與MongoDB完全兼容的客戶端、API的同時，號稱可以減少90%的存儲空間，同時提供20倍的性能提升。我也了解到，已經有一些生產系統在使用TokuMX，反饋不錯（比如?這里?和?這里）。

經過我的測試，從MongoDB遷移到TokuMX非常簡單：用mongodump將原有數據導出，再在安裝了TokuMX的機器上mongorestore即可。原先用MongoDB需要102G的數據，采用默認的zlib壓縮方式導入TokuMX之后，只有2.2G，同時導入速度大大提高（至少有10倍的提高），而查詢性能沒有降低（QPS在2位數左右，使用索引）。這個對比是我不敢想像的，它直接解決了現在的問題。

對著這份數據，我不免好奇TokuMX究竟使用了怎樣的技術？就我現在的了解，減少磁盤空間占用主要是在存儲層使用了壓縮方式（TokuMX宣稱，如果不使用壓縮，TokuMX的磁盤占用也比MongoDB少10%左右）。這種思路不稀奇，5.x版本的MySQL中，如果設定file_format為Barracuda，也可以直接對表做壓縮，同時外部操作不需要做任何變化。TokuMX的提高寫入速度則相當有趣，按照TokuMX的做法是使用分形樹索引（Fractal Tree Index），替代了所謂“已經有40年歷史的B樹索引”，按照Wiki上的說法，TokuMX是分形樹索引進行商業應用的典型。

“分形”是一個數學上的概念，大略來說，指的是“事物的每一部分都近似整體縮小后的形狀”。TokuMX的分形樹索引，嚴格說起來更像“B樹 + 批量寫入”，與B樹的不同在于，分形樹的每個內部節點都帶有自己的緩沖區，它存儲尚未落實（pending）到葉子節點的數據，默認情況下寫入只會到緩沖區，緩沖區填滿之后會把所有的寫操作刷（flush）下去。

我順手翻譯了TokuMX的一篇介紹文章，供大家參考。

再附兩份參考資料

percona的TokuDB和TokuMX介紹文檔
http://www.percona.com/live/london-2013/sessions/fractal-tree-indexes-theory-practice

Facebook的人做的性能對比評測
http://smalldatum.blogspot.com/

推特上的 @BohuTang 應該是?TokuTek 的貢獻者，人非常好，大家有問題也可以和他討論。

原文地址：TokuMX使用小計, 感謝原作者分享。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com