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索引，全文索引。 原文地址：我们为什么要从mongodb迁移到tokumx, 感谢原作者分享。