最新文章專題視頻專題問答1問答10問答100問答1000問答2000關(guān)鍵字專題1關(guān)鍵字專題50關(guān)鍵字專題500關(guān)鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專題關(guān)鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
當(dāng)前位置: 首頁 - 科技 - 知識百科 - 正文

TokuMX使用小計(jì)

來源:懂視網(wǎng) 責(zé)編:小采 時間:2020-11-09 13:07:44
文檔

TokuMX使用小計(jì)

TokuMX使用小計(jì):最近因?yàn)楣ぷ鞯木壒剩佑|了TokuMX,嘗試下來感覺不錯,值得介紹給大家。 事情的起因是要解決MongoDB的問題。系統(tǒng)中需要保存程序輸出的運(yùn)行信息,這類信息比程序語言的log更高級,但又不如業(yè)務(wù)操作日志高級,是某些時候發(fā)現(xiàn)問題的關(guān)鍵證據(jù),所以必須保存。因
推薦度:
導(dǎo)讀TokuMX使用小計(jì):最近因?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)楣ぷ鞯木壒?,接觸了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)下去。

Screen Shot 2014-07-01 at 8.44.02 PM

我順手翻譯了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)者,人非常好,大家有問題也可以和他討論。

聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文檔

TokuMX使用小計(jì)

TokuMX使用小計(jì):最近因?yàn)楣ぷ鞯木壒剩佑|了TokuMX,嘗試下來感覺不錯,值得介紹給大家。 事情的起因是要解決MongoDB的問題。系統(tǒng)中需要保存程序輸出的運(yùn)行信息,這類信息比程序語言的log更高級,但又不如業(yè)務(wù)操作日志高級,是某些時候發(fā)現(xiàn)問題的關(guān)鍵證據(jù),所以必須保存。因
推薦度:
標(biāo)簽: 使用 工作 接觸
  • 熱門焦點(diǎn)

最新推薦

猜你喜歡

熱門推薦

專題
Top