我们为什么要从MongoDB迁移到TokuMX

MongoDB使用情况
作为最初使用MongoDB的用户之一，我们线上MongoDB版本从MongoDB 1.8到MongoDB 2.0到MongoDB 2.2再到MongoDB 2.4，我们经历了几乎所有使用MongoDB的用户会遇到的问题，也随着MongoDB版本更新，看到MongoDB这几年取得的改进。
近期随着MongoDB 2.6版本的发布，在国内外又掀起了一股热(tu)潮(cao),然后这一次我们可能不会立即升级或部署新的MongoDB 2.6版本，但我们会保持关注。
去年(2013)6月份我们开始对TokuMX 1.0版本进行测试，关注，一直进行了半年多的观察。在今年2月份在正式在生产环境迁移看了第一套TokuMX 版本1.4.0。为什么是1.4.0?因为之前的版本还不是很完善，不是很友好，也有一些bug没解决。
一直到近期，线上比较重要的系统已陆续迁移到TokuMX 1.4.1（主要使用工具mongosync），开始较大规模的开始使用，并且新上线的系统无特殊原因默认使用TokuMX。

为什么要迁移到TokuMX
尽管TokuMX宣称了很多很好的特性，真正使得我们迁移的原因是如下几种：

• 压缩。MongoDB BSON格式的带来的存储空间消耗实在是太大了，使用TokuMX 默认的zlib压缩可以减少大量的磁盘空间占用（1/3-1/20）。
• 更好的存储空间利用效率。MongoDB 空间释放是个麻烦的事情（需要drop 整个个数据库或者repair），TokuMX drop collect或者index即可释放空间。
• 更好的内存管理。MongoDB nmap简单，但是不方便分配固定内存。caching和 IO都交由操作系统去调度，时间长了，数据大了容易造成内存泄露。TokuMX 通过参数指定cacheSize分配固定大小的内存（多实例环境这个非常适用，虽然不推荐使用多实例）。
• 写优化。这个是TokuMX 最基础最根本的东西，在大数据量的情况下写入速度基本保持不变。MongoDB在超过1亿记录后或在数据比较大的情况下，写性能衰减得比较厉害，这一切归因于40年的B-tree索引，也正是TokuMX 分形树索引优化的地方。
• 其他的特性，如document 级别的锁，事务支持等，这些不是我们所重的，实际效果还需时间检验。

TokuMX目前带来的成本或缺点
尽快TokuMX解决了一系列的问题，但也并非是完美的方案。

• 增加运维成本。对于从MongoDB迁移过来，肯定是需要更多的学习成本和运维成本的，比如新的问题的产生，新的运维工具的开发与支持。从企业角度说，目前国内大多都没有购买原厂支持的情况下，这个可能并不那么突出。
• 查询性能？由于压缩或多或少影响查询性能，目前从我们使用看，没有影响。
• 目前部分功能不支持，如geo索引，全文索引。