最近因?yàn)楣ぷ鞯木壒?,接觸了TokuMX,嘗試下來感覺不錯,值得介紹給大家。 事情的起因是要解決MongoDB的問題。系統(tǒng)中需要保存程序輸出的運(yùn)行信息,這類信息比程序語言的log更高級,但又不如業(yè)務(wù)操作日志高級,是某些時候發(fā)現(xiàn)問題的關(guān)鍵證據(jù),所以必須保存。因
最近因?yàn)楣ぷ鞯木壒?,接觸了TokuMX,嘗試下來感覺不錯,值得介紹給大家。
事情的起因是要解決MongoDB的問題。系統(tǒng)中需要保存程序輸出的運(yùn)行信息,這類信息比程序語言的log更高級,但又不如業(yè)務(wù)操作日志高級,是某些時候發(fā)現(xiàn)問題的關(guān)鍵證據(jù),所以必須保存。因?yàn)楦袷讲惶?guī)范,又需要方便檢索,所以文檔型NoSQL的MongoDB是比較好的選擇。
但是,選擇MongoDB就必然會面對磁盤空間的問題。我們的數(shù)據(jù)大概是這樣的:每天的數(shù)據(jù)量不到200萬條,單條數(shù)據(jù)的平均大小不超過4k,但MongoDB存一個月的數(shù)據(jù)就消耗了接近40G,最近三個月的數(shù)據(jù)則需要接近100G。限于具體的硬件環(huán)境,只能保存最近三個月的數(shù)據(jù),但這無法滿足業(yè)務(wù)需求,所以必須另想辦法。
最終我們選定的方案是TokuMX。它是一款開源的、高性能的MongoDB發(fā)布(distribution),在提供與MongoDB完全兼容的客戶端、API的同時,號稱可以減少90%的存儲空間,同時提供20倍的性能提升。我也了解到,已經(jīng)有一些生產(chǎn)系統(tǒng)在使用TokuMX,反饋不錯(比如?這里?和?這里)。
經(jīng)過我的測試,從MongoDB遷移到TokuMX非常簡單:用mongodump將原有數(shù)據(jù)導(dǎo)出,再在安裝了TokuMX的機(jī)器上mongorestore即可。原先用MongoDB需要102G的數(shù)據(jù),采用默認(rèn)的zlib壓縮方式導(dǎo)入TokuMX之后,只有2.2G,同時導(dǎo)入速度大大提高(至少有10倍的提高),而查詢性能沒有降低(QPS在2位數(shù)左右,使用索引)。這個對比是我不敢想像的,它直接解決了現(xiàn)在的問題。
對著這份數(shù)據(jù),我不免好奇TokuMX究竟使用了怎樣的技術(shù)?就我現(xiàn)在的了解,減少磁盤空間占用主要是在存儲層使用了壓縮方式(TokuMX宣稱,如果不使用壓縮,TokuMX的磁盤占用也比MongoDB少10%左右)。這種思路不稀奇,5.x版本的MySQL中,如果設(shè)定file_format為Barracuda,也可以直接對表做壓縮,同時外部操作不需要做任何變化。TokuMX的提高寫入速度則相當(dāng)有趣,按照TokuMX的做法是使用分形樹索引(Fractal Tree Index),替代了所謂“已經(jīng)有40年歷史的B樹索引”,按照Wiki上的說法,TokuMX是分形樹索引進(jìn)行商業(yè)應(yīng)用的典型。
“分形”是一個數(shù)學(xué)上的概念,大略來說,指的是“事物的每一部分都近似整體縮小后的形狀”。TokuMX的分形樹索引,嚴(yán)格說起來更像“B樹 + 批量寫入”,與B樹的不同在于,分形樹的每個內(nèi)部節(jié)點(diǎn)都帶有自己的緩沖區(qū),它存儲尚未落實(shí)(pending)到葉子節(jié)點(diǎn)的數(shù)據(jù),默認(rèn)情況下寫入只會到緩沖區(qū),緩沖區(qū)填滿之后會把所有的寫操作刷(flush)下去。
我順手翻譯了TokuMX的一篇介紹文章,供大家參考。
再附兩份參考資料
percona的TokuDB和TokuMX介紹文檔
http://www.percona.com/live/london-2013/sessions/fractal-tree-indexes-theory-practice
Facebook的人做的性能對比評測
http://smalldatum.blogspot.com/
推特上的 @BohuTang 應(yīng)該是?TokuTek 的貢獻(xiàn)者,人非常好,大家有問題也可以和他討論。
原文地址:TokuMX使用小計(jì), 感謝原作者分享。
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com