logo

1.稳定性不足 TokuMX从目前的生产环境情况下来看,进程crash掉概率远大于MongoDB(虽然MongoDB也存在稳定性问题,概率小很多);原因当然也简单,TokuMX还太年轻,而且系统复杂度高了,不同于MySQL的插件式引擎设计,MongoDB要更改引擎,需要更改的代码较多,因此TokuMX版本基本不会与MongoDB在server层能很好的兼容了(应用层兼容)。 而且TokuMX走的更远,出于设计上一些考虑,如并发,性能等方面,TokuMX改变了oplog结构,同步复制行为也不太一样(从目前实际情况看,TokuMX复制的改造并不够理想),更增加了不稳定因素,原因还是因为诞生时间太短。还没经受住太多考验。

2.应用层兼容性仍有少量问题 TokuMX和MongoDB在应用层接口基本一致,达到比较高的兼容性,日常使用不会出现太大问题。但在一些场合,以及和第三方工具的兼容性上会出现一些问题: 如rockmongo,经常会导致TokuMX server卡死。这进一步加大了运维的成本。 再如TokuMX capped collection 效率太差,严重影响使用,虽然有替代办法,如TTL和分区。 当然目前不支持geo及全文索引,这个都不算问题了。

以上简单总结了下,目前TokuMX存在的问题,尤其是稳定性,这个是非常致命的。这个还需要时间的积累。TokuMX要走的路还非常长。当然MongoDB也有不少缺点,那是另一个话题了。

7 回复
Hisoka-J
#1 Hisoka-J • 3 年前

再如TokuMX capped collection 效率太差,严重影响使用,虽然有替代办法,如TTL和分区。 你错了,不是效率差,在我的测试中,这玩意的capped collection就根本不能用,暂时还没能达到去评测它效率的程度~

Hisoka-J
#2 Hisoka-J • 3 年前

分区非常好,这个强烈好评,性能非常好,并且删除释放立竿见影,有了分区完全没有用TTLcapped collection的必要

Hisoka-J
#3 Hisoka-J • 3 年前

为什么你有了19个粉丝而我没有,妈蛋!

ccj
#4 ccj • 3 年前

这个有啥用。。。。

Hisoka-J
#5 Hisoka-J • 3 年前

@ccj 说明你比我有名多了。。。

ccj
#6 ccj • 3 年前

@Hisoka-J 你贡献太少了,赶紧多发文

Hisoka-J
#7 Hisoka-J • 3 年前

@ccj 大爷的,我发的文仅次于你,囧

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