当前位置: 首页 > mongodb > 正文

MongoDB与TokuMX在Sharding Balancer的性能比较

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.

压力测试描述和环境:

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

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

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

原文地址:tokutek.com,转载请注明原链接。

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

该日志由 Fisher 于2014年02月17日发表在 mongodb 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: MongoDB与TokuMX在Sharding Balancer的性能比较 | 运维·速度
关键字:

MongoDB与TokuMX在Sharding Balancer的性能比较:等您坐沙发呢!

发表评论


Time limit is exhausted. Please reload the CAPTCHA.

快捷键:Ctrl+Enter