logo

在TokuMX 1.4.0中,性能改进两个大的变化是更新(updates)的实现方式:

1.在单台机器情况下,不需要修改任何索引字段的更新是通过发送一个小的消息到主键来修改文档。 而不是发送修改后的文档的整个副本去覆盖旧文档,TokuMX只编码消息的修改,当到达树的底部时应用到现有行。

2.在合适的工作负荷下,这可以大大减少内部节点缓冲的缓存使用空间,从而有效增加工作集可用的缓存容量, 在oplog中,记录原文档和更新的修改而不是记录原文档和新文档,新文档在从库重建。 在极端的情况下,这可以减少用于复制约为1.4版本之前的大小的一半OPLOG和网络带宽的大小。

MongoDB中,更新操作是首先搜索要更新的文档,如果该文档大小不增加,然后执行原地更新, 或通过复制文档的一个新的副本,然后更新所有索引而不管更新的影响。 所有从库这个过程是相同的, 这意味着对于工作集比RAM大,更新的工作负载可以迅速消耗所有集群中的I/O资源。

TokuMX中,更新还是做在主库搜索,找到原文档,但是在这之后,更新没有任何随机I/O。 相反,是将消息发送到受影响的索引(何修改操作在分形树索引是如何发生的)删除无效的条目,并用新版本替换。 由于TokuMX辅助索引使用逻辑而非物理的主键标识符 ,文档没有什么特别的增长,实际上只是更新修改的key的更新受影响, 这些跟正常的插入操作一样,都不会再产生随机I/O 。

对于副本集的从库,TokuMX比MongoDB在OPLOG存储了更多信息,从而使从库从OPLOG获取足够的信息来同步更新(删除和插入到受影响的索引) 而不产生任何I/O,这使工作负载是读操作的扩展更有效。 然而,为编码简单起见,直到1.4.0,整个旧版本和新版本的文档都被放入OPLOG。

由于MongoDB中,像许多NoSQL数据库,鼓励反规范化,许多现有的MongoDB的应用程序经常更新的大型文档的一小部分。 对于一个小更新,TokuMX可能会记录一个非常大的文件的两个副本。 这些往往会在OPLOG压缩得很好,但它仍然是空间的显著浪费, MongoDB wire protocol 不支持压缩 (现在),所以使得副本集的网络流量膨胀。

还有剩下的工作,超出了上述更改,在将来的版本中以进一步降低OPLOG大小,但是这对于用户是一个很大的进步。

大多数用户应该简单地升级,并立即看到好处。 有一点要注意的是,由于这些变化主库在OPLOG增加了一个新的类型的消息, ,副本主库是1.4.0或更高版本,从库是较早的版本将不安全。 升级副本集,必须先升级所有从库(为了确保从库不升级为主库,优先级可以设置为零), 然后使其中一个从库成为主库再升级原来的主。用户指南中有提到。

参考: http://www.tokutek.com/2014/02/whats-new-in-tokumx-1-4-part-3-optimized-updates/

5 回复
cevincheung
#1 cevincheung • 2014-02-22 02:55

不错。很好的文章。希望能多出一些tokumx的优化调优方面的和测评。

ps: 网站速度忒慢,用加速乐吧(非ad) 看topic的id,数据库用的mongodb?

ccj
#2 ccj • 2014-02-22 10:18

nodejs+mongodb架构,我这速度很快,稍后试试加速乐。

Hisoka-J
#3 Hisoka-J • 2014-02-27 22:26

@ccj有没有测试快了多少?

ccj
#4 ccj • 2014-02-27 22:49

@Hisoka-J 没用那个,看了觉得不是很喜欢

wuming
#5 wuming • 2014-03-24 12:21

@ccj 确实打开挺慢的,我这儿打开一篇文章要1分多钟 各种js太慢,main.js要1分多钟,js没有加载下来,页面就显示不出来 内容很快,几百ms就下来了。。

需要 登录 后方可回复, 如果你还没有账号你可以 注册 一个帐号。