Tokutek®提供了高性能高可用的MongoDB解决方案。

业界认为TokuMX’s Fractal Tree索引是最合适的mongodb分区模块。特别是当需要进行集群数据块平衡的时候。 从整体上看，当一个分区比其他分区的块多很多时就有必要进行数据平衡了。具体的算法在MongoDB的文档中有详细的阐述。分片数据平衡的过程中会影响性能，所以MongoDB执行了一个计划来控制数据平衡的进程。

MongoDB的块迁移有6个步骤，最重要的操作如下所示：
1.Get all the documents for a given chunk from the donor shard.
2.Insert all the documents from step 1 into the receiving shard.
3.Delete all the documents from step 1 on the donor shard.

上面是TokuMX理想状态的工作步骤，尤其是当你有内存操作并且操作的整体数据量要大于现有内存的大小时，其原因如下：

1. Get all the documents for a given chunk from the donor shard.
TokuMX在分区的key上创建一个集群索引，所以数据块中的文档被整体定位到磁盘上，这样大规模的检索将变得很快，并且比起随机IO，序列化IO效率更高。

2. Insert all the documents from step 1 into the receiving shard.
TokuMX拥有无与伦比的索引插入性能，详见性能测试

3. Delete all the documents from step 1 on the donor shard.
TokuMX’s 删除操作需要很少的IO，并且TokuMX支持并发写操作能够消除对压力负载的阻塞，详见Sysbench benchmark.

压力测试描述和环境：

Single Dell R710, (2) Xeon 5540, 16GB RAM, PERC 6/i (256MB, write-back), 8x10K SAS/RAID 10
Ubuntu 13.10 (64-bit), XFS file system
3 mongod shards, 3 config servers, 1 mongos
MongoDB v2.4.9
read-ahead set to 16K
TokuMX v1.4.0
4GB cache per mongod instance, directIO
The schema is Sysbench, with 1 change. Rather than creating 12 tables with 10 million documents each I added a new field “collectionId”, and inserted 10 million documents with each collectionId between 1 and 12.
Sharding is range based
Shard key is collectionId + documentId
Secondary index on collectionId + k
Other benchmark specifics
Pre-split into 12 chunks, 1 each of collectionId 1 through 12
Prior to loading each shard contains 4 chunks
Balancer off for the entire benchmark

Java压力测试代码（http://www.tokutek.com/wp-content/uploads/2014/02/blog-mongodb-15-movechunk.zip）, I’ll have it on GitHub soon.

压力测试结果：
用12个线程插入1.2亿条数据，MongoDB处理插入的吞吐量为4596条/秒，而TokuMX是43769条/秒，是MongoDB的8倍以上。
当数据被加载以后，进行了传统的系统压力测试（精确查询，范围查询，更新，删除，插入等操作），得出吞吐率为MongoDB能够15条事物/秒，TokuMX在30条左右，是Mongo的2倍。
十分钟后，执行了3条sh.moveChunk() 操作，从shard0001移动单独的块到shard0002上，然后从shard0002再到shard0000，最后从shard0000到shard0001，结果如下图所示：

TokuMX集群效率是MongoDB的两倍，并且不受块迁移的影响，MongoDB明显是收到了影响，有时甚至下贱了50%左右。

这个压力测试表明了TokuMX在性能上有大幅度的提高（集群索引，并行写入，索引维护时的低IO），当然还有其他一些，如TokuMX还包含了高压缩率和对事物的支持。

原文地址：tokutek.com，转载请注明原链接。

本文固定链接: https://sudops.com/mongodb-tokumx-sharding-balancer.html | 运维速度