TokuMX 是基于开源软件 MongoDB 的另一版本，它使用fractal tree index替换了Mongodb默认的B-tree数据结构。这样极大提高了数据存储上的压缩率，看参考之前的文章：《TokuMX的数据压缩能力令人惊喜》和良好的写速度.已经有文章对InnoDB, TokuMX and MongoDB的性能进行了benchmarking，测试结果显示TokuMX拥有超高的写性能和优秀的磁盘空间压缩能力。
我们还是自我娱乐一下，从下面三方面入手再进行一次关于 TokuMX 的压力测试(无聊不，有意思吗?)：
1. 导入和导出大的collections
2. 大量写负荷下的性能表现
3. 对于大数据量应用下的数据存储的压缩情况
1. 导入大量的Collections
我们有时/通常会通过export和import对不同的replica sets进行数据迁移，然后如果这种迁移操作很慢的话那真是一件非常让人痛苦和无奈的事情。特别是对于那些拥有很多小的数据条目或者复杂的索引的时候。
为了测试导入和导出，我们准备了两组大数据
Collection1： 拥有大约3亿条小对象的，总计大小为 143GB 的数据 Collection2： 拥有大约50万条大数据对象的 总计为 147GB 的数据
每一个collections都是从我们现有的MongDB中导出来的，当然，导出collection1花费了6天，collection2花费了6个小时。
我们用mongoimport命令导入collections到MongoDB和TokuMX实例中，Benchmark结果显示Collection1情况下（拥有大量小对象）TokuMX要比MongoDB快3倍。
# Collection1: exported from MongoDB for 6 days Database Import Time --------------------------------------------------------------------- MongoDB 58 hours 37 minutes TokuMX 14 hours 28 minutes
Collection2 （大对象的数据）的测试结果中，二者的性能几乎一样，打成了平手。
# Collection2: exported from MongoDB for 6 hours Database Import Time --------------------------------------------------------------------- MongoDB 48 minutes TokuMX 53 minutes
2. 大量写负荷的情况
使用了一个大量update操作的app，并且是大对象的数据进行压力测试，进行了10个小时的压力测试，结果显示，TokuMX 的写延迟要比 MongoDB好上3倍。
# MongoDB Benchmark Results
- Ops/sec: 1695.81
- Update Latencies:
P50: 5.96ms
P70: 6.59ms
P90: 11.57ms
P95: 18.40ms
P99: 44.37ms
Max: 102.52ms
# TokuMX Benchmark Results
- Ops/sec: 4590.97
- Update Latencies:
P50: 3.98ms
P70: 4.49ms
P90: 6.33ms
P95: 7.61ms
P99: 12.04ms
Max: 16.63ms
3. 磁盘的利用率
TokuMX 对数据的存储进行了压缩优化，我们导入了一个共享的replica sets（拥有2.4T的数据），导入到TokuMX的实例中，结论是：TokuMX仅仅使用了379G的磁盘空间，是原始大小的15%。
怎么样，有意思吧，TokuMX 表现的相当出色，是否还在犹豫是否将 TokuMX 应用到生产环境中呢？别人我不知道，反正我们已经使用TokuMX超过半年了，并没有出现过任何问题。
原文：blog.parse
