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,转载请注明原链接。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值