当前位置:Gxlcms > mysql > 我们为什么要从MongoDB迁移到TokuMX

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

时间:2021-07-01 10:21:17 帮助过:24人阅读

MongoDB使用情况 作为最初使用MongoDB的用户之一,我们线上MongoDB版本从MongoDB 1.8到MongoDB 2.0到MongoDB 2.2再到MongoDB 2.4,我们经历了几乎所有使用MongoDB的用户会遇到的问题,也随着MongoDB版本更新,看到MongoDB这几年取得的改进。 近期随着MongoDB

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索引,全文索引。

人气教程排行