當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

TokuMX

發布時間：2024/1/17 编程问答 46 豆豆

生活随笔收集整理的這篇文章主要介紹了 TokuMX 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

之前的文章介紹過TokuTek公司出品的TokuDB，其主要特色是在擁有完整事務處理能力的前提下，實現了大幅度的數據壓縮，并有著良好的性能表現。TokuTek的工程師再接再厲，把目前非常流行的NoSQL數據庫MongoDB的底層替換成與TokuDB同樣的存儲引擎，達到了非常好的效果。

MongoDB擁有靈活的文檔型數據結構和方便的操作語法，在新興的互聯網應用中得到了廣泛的部署，但對于其底層的存儲引擎，我一直有一些保留意見。據我了解，其采用了MMAP的方式來操作數據文件，這就導致我們無法限制MongoDB進程所使用的內存容量，目前最好的部署辦法就只能是將其單獨部署在一臺服務器上。另外，MongoDB也不能嚴格的支持事務，對于并發寫入的鎖的粒度也非常粗。

TokuMX的出現解決了這一切，它為MongoDB替換了一顆真正的數據庫存儲引擎，我們現在可以像使用MySQL數據庫一樣精確的指定TokuMX最大可用內存，它也完整支持的事務處理。當然了，TokuTek引以為傲的數據壓縮能力也是一點也沒落下。

TokuMX經過多次發布，現在是1.3.2版本，是免費開源軟件，官方網站可以下載：

http://www.tokutek.com/products/tokumx-for-mongodb/

軟件體積也比較大（大概73M），國內下載比較慢，我搬運了一份到百度網盤：

http://pan.baidu.com/s/1ksfWj

TokuMX 實現了絕大部分MongoDB 2.4的功能，應用程序無需做任何修改。但需要注意的是，TokuMX的數據存儲格式與MongoDB完全不一樣，需要使用mongodump導出數據，然后用mongorestore導入才可以使用。

官方用戶站內指南下載地址：

http://www.zeuux.com/group/mysql/file/content/443/

來源：http://xmgu2008.blog.163.com/blog/static/13912238020140279353937/

TokuMX的數據壓縮能力令人驚喜

相比原生的MongoDB， TokuMX 提供了三個主要的特性：性能的優化提升，數據壓縮特性，支持事物。不過實際使用中到底怎么樣呢？
作為已經使用兩個月的用戶的我表示很滿意，公司線上的一個產品使用 TokuMX 兩個月以來并沒有出現問題。而且讓我印象最為深刻的是TokuMX對數據的壓縮能力。
因為對寫做了優化和壓縮，在不影響性能的前提下 TokuMX 比原生的 MongoDB 節約了90%的存儲空間。

下面是我們的實際情況：為了比較，我在同一各集群上起了兩套MongoDB，一個是原生的，一個是TukuMx，并使用相同的數據。使用中發現原MongoDB中的數據大小為32GB，而導入到TokuMX中只有3.4GB，果真是節約了90%的存儲空間。?
?
具體數據如下：

# du -sh sudops_tokumx

3.4G????sudops_tokumx

# du -sh sudops_mongodb

32G????sudops_mongodb

# ls -tlrh sudops_mongodb/

total 32G

-rwxr-xr-x 1 root root????6 Mar 20 22:29 mongod.lock

-rw------- 1 root root 2.0G Mar 20 22:54 local.9

-rw------- 1 root root 2.0G Mar 20 22:54 local.8

-rw------- 1 root root 2.0G Mar 20 22:54 local.7

-rw------- 1 root root 2.0G Mar 20 22:54 local.6

-rw------- 1 root root 2.0G Mar 20 22:54 local.5

-rw------- 1 root root 2.0G Mar 20 22:54 local.11

-rw------- 1 root root 2.0G Mar 20 22:54 local.10

-rw------- 1 root root 2.0G Mar 20 22:54 local.4

-rw------- 1 root root 2.0G Mar 20 22:54 local.3

-rw------- 1 root root 2.0G Mar 20 22:54 local.2

-rw------- 1 root root??64M Mar 20 22:54 local.0

-rw------- 1 root root 128M Mar 20 23:23 sudops.1

-rw------- 1 root root 256M Mar 20 23:24 sudops.2

-rw------- 1 root root 2.0G Mar 20 23:25 sudops.5

-rw------- 1 root root 512M Mar 20 23:25 sudops.3

drwxr-xr-x 2 root root 4.0K Mar 20 23:26 journal

-rw------- 1 root root??64M Mar 20 23:27 sudops.0

-rw------- 1 root root??16M Mar 20 23:27 local.ns

drwxr-xr-x 2 root root 4.0K Mar 20 23:27 _tmp

-rw------- 1 root root??16M Mar 20 23:27 sudops.ns

-rw------- 1 root root 1.0G Mar 20 23:27 sudops.4

-rw------- 1 root root 2.0G Mar 20 23:27 local.1

-rw------- 1 root root 2.0G Mar 20 23:28 local.12

# ls -trlh sudops/

total 3.4G

-rw------- 1 root root????0 Mar 18 17:16 __tokumx_lock_dont_delete_me_temp

-rw------- 1 root root????0 Mar 18 17:16 __tokumx_lock_dont_delete_me_recovery

-rw------- 1 root root????0 Mar 18 17:16 __tokumx_lock_dont_delete_me_logs

-rw------- 1 root root????0 Mar 18 17:16 __tokumx_lock_dont_delete_me_environment

-rw------- 1 root root????0 Mar 18 17:16 __tokumx_lock_dont_delete_me_data

-rwxr-xr-x 1 root root??16K Mar 18 17:16 tokumx.environment

-rwxr-xr-x 1 root root??32K Mar 18 17:17 local_system_version_id__2_8_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 18 18:12 local_system_replset_id__a2_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 18 18:33 local_system_indexes__2_a_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 18 18:33 local_me_id__448_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 18 18:33 local_ns_2_7_19.tokumx

-rwxr-xr-x 1 root root????6 Mar 19 13:55 mongod.lock

-rwxr-xr-x 1 root root??32K Mar 19 13:56 local_startup_log_id__5_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 19 15:52 sudops_category_id__2b87_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 19 15:52 sudops_role_id__29cc_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 19 15:55 sudops_menu_id__2a15_1_19.tokumx

-rwxr-xr-x 1 root root??64K Mar 19 18:39 sudops_type_id__2c95_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 19 19:02 sudops_region_id__48de_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 20 19:07 sudops_system_indexes__2965_6_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 20 19:07 sudops_system_namespaces__2965_5_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 20 19:07 sudops_ns_2965_3_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 21 10:48 sudops_searchRecommend_id__3055_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 26 11:19 sudops_cp_id__2b19_1_19.tokumx

-rwxr-xr-x 1 root root??32K Mar 26 17:24 local_oplog_refs_p5_id__1905fa1_2_19.tokumx

-rwxr-xr-x 1 root root??32K Apr??8 18:21 sudops_user_id__2989_1_19.tokumx

-rwxr-xr-x 1 root root??96M Apr??8 18:43 local_oplog_rs_p20_id__1ff054b_1_19.tokumx

-rwxr-xr-x 1 root root??32K Apr??9 17:24 local_oplog_refs_meta_id__a1_3_19.tokumx

-rwxr-xr-x 1 root root 128M Apr??9 18:39 local_oplog_rs_p21_id__20774ee_1_19.tokumx

-rwxr-xr-x 1 root root??32K Apr 14 15:13 sudops_component_id__3019_1_19.tokumx

-rwxr-xr-x 1 root root 144M Apr 14 18:16 local_oplog_rs_p26_id__2338b07_1_19.tokumx

-rwxr-xr-x 1 root root??32K Apr 15 17:54 sudops_channel_id__2f15_1_19.tokumx

-rwxr-xr-x 1 root root 128K Apr 16 15:49 sudops_special_id__2fbb_1_19.tokumx

-rwxr-xr-x 1 root root??32K Apr 21 11:09 sudops_searchWord_id__3062_1_19.tokumx

-rwxr-xr-x 1 root root??64K Apr 21 16:44 sudops_assemble_id__2bd68_1_19.tokumx

-rwxr-xr-x 1 root root??64K Apr 21 16:49 sudops_poster_id__2f3e_1_19.tokumx

-rwxr-xr-x 1 root root??32K Apr 21 17:24 local_system_namespaces__2_9_19.tokumx

-rwxr-xr-x 1 root root??32K Apr 21 17:24 local_oplog_rs_meta_id__a1_1_19.tokumx

當初在選擇TokuMX的時候我選擇了 TokuMX enterprise subscription，號稱其支持Hotbackup，不過還始終無法配置成功，還特意在在線咨詢了TokuMX的brain polansky，他建議我使用community version。如果有什么問題的話，還是推薦大家加入TokuMX 的 Google Groups。

來源：http://www.sudops.com/tokumx-compression-data-save-90-percent-stoage.html

TokuMX vs. MongoDB 插入性能對比

TokuDB 的ft tree 用在MongoDB產品TokuMX已經發布。MongoDB 在大量數據（比如1億條記錄）后，插入性能急劇下降。

Tokutek數據?
帶索引插入性能對比。?

http://www.tokutek.com/2013/06/iibench-benchmark-tokumx-vs-mongodb/

以上為Tokutek的測試數據，下面為我測試的數據：

筆者實際測試?
生產數據2億多條導入測試?
先建集合，創建3個索引，包括_id共4個索引。?
TokuMX 5個多小時導完數據，官方MongoDB 2.2.4版本竟然花了2天2夜多，近58個小時?
使用mongostat統計，每分鐘取值一個，縱坐標為inserts/s,橫坐標為分鐘。?

局部放大圖：?

磁盤空間占用比較：?
TokuMX 18G,MongoDB 80G?
內存使用比較：?
TokuMX,cacheSize設置為30G，開directio，內存使用完沒有cache的。

# free -g

total used free shared buffers cached

Mem: 31 31 0 0 0 0

-/+ buffers/cache: 30 0

Swap: 15 0 15

MongoDB，內存使用完，實際在cache里面

# free -g

total used free shared buffers cached

Mem: 31 31 0 0 0 28

-/+ buffers/cache: 1 29

Swap: 15 0 15

cpu使用：?
未詳細記錄，TokuMX要高10%左右。?
io:?
MongoDB io要高不少。

總結：TokuMX太讓人激動了，沒有不使用它的理由，不過目前有些不支持的功能，如geo索引。?
Currently unsupported functionality?
● dropDups option for unique indexes?
● Background Indexing, the “background” option is ignored when creating indexes.?
● Fulltext indexes?
● Geospatial indexes

來源：http://www.tuicool.com/articles/22IVfi

我們為什么要從MongoDB遷移到TokuMX

http://nosqldb.org/topic/5354c77c3b3af7ad7f126ad4

MongoDB使用情況
作為最初使用MongoDB的用戶之一，我們線上MongoDB版本從MongoDB 1.8到MongoDB 2.0到MongoDB 2.2再到MongoDB 2.4，我們經歷了幾乎所有使用MongoDB的用戶會遇到的問題，也隨著MongoDB版本更新，看到MongoDB這幾年取得的改進。
近期隨著MongoDB 2.6版本的發布，在國內外又掀起了一股熱(tu)潮(cao),然后這一次我們可能不會立即升級或部署新的MongoDB 2.6版本，但我們會保持關注。
去年(2013)6月份我們開始對TokuMX 1.0版本進行測試，關注，一直進行了半年多的觀察。在今年2月份在正式在生產環境遷移看了第一套TokuMX 版本1.4.0。為什么是1.4.0?因為之前的版本還不是很完善，不是很友好，也有一些bug沒解決。
一直到近期，線上比較重要的系統已陸續遷移到TokuMX 1.4.1（主要使用工具mongosync），開始較大規模的開始使用，并且新上線的系統無特殊原因默認使用TokuMX。

為什么要遷移到TokuMX
盡管TokuMX宣稱了很多很好的特性，真正使得我們遷移的原因是如下幾種：

壓縮。MongoDB BSON格式的帶來的存儲空間消耗實在是太大了，使用TokuMX 默認的zlib壓縮可以減少大量的磁盤空間占用（1/3-1/20）。
更好的存儲空間利用效率。MongoDB 空間釋放是個麻煩的事情（需要drop 整個個數據庫或者repair），TokuMX drop collect或者index即可釋放空間。
更好的內存管理。MongoDB nmap簡單，但是不方便分配固定內存。caching和 IO都交由操作系統去調度，時間長了，數據大了容易造成內存泄露。TokuMX 通過參數指定cacheSize分配固定大小的內存（多實例環境這個非常適用，雖然不推薦使用多實例）。
寫優化。這個是TokuMX 最基礎最根本的東西，在大數據量的情況下寫入速度基本保持不變。MongoDB在超過1億記錄后或在數據比較大的情況下，寫性能衰減得比較厲害，這一切歸因于40年的B-tree索引，也正是TokuMX 分形樹索引優化的地方。
其他的特性，如document 級別的鎖，事務支持等，這些不是我們所重的，實際效果還需時間檢驗。

TokuMX目前帶來的成本或缺點
盡快TokuMX解決了一系列的問題，但也并非是完美的方案。

增加運維成本。對于從MongoDB遷移過來，肯定是需要更多的學習成本和運維成本的，比如新的問題的產生，新的運維工具的開發與支持。從企業角度說，目前國內大多都沒有購買原廠支持的情況下，這個可能并不那么突出。
查詢性能？由于壓縮或多或少影響查詢性能，目前從我們使用看，沒有影響。
目前部分功能不支持，如geo索引，全文索引。

TokuMX使用小計

最近因為工作的緣故，接觸了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/

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

參考資料：?http://www.percona.com/live/london-2013/sessions/fractal-tree-indexes-theory-practice

延伸閱讀：http://www.tuicool.com/topics/11030118

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的TokuMX的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

tokumx