在最近的报道，Vadim比较了Amazon Aurora和Percona Server在亚马逊云上的性能，这次，我要比较的写InnoDB和TokuDB的性能，在他的实验中使用相同的算例（性能测试集：oltp/update/update_non_index）和一个简单的计划（r3.xlarge实例,与通用的ssd、io2000和io3000卷）。

所有的运行都使用16个线程做系统测试，下面分别是InnoDB和TokuDB的MYSQL配置文件：

和：

你能够看到所有图的设置和完整的结果。

让我首先通过这个总结性的关于io2000流量的图表来说明下测试结果，这个图表展示了每个引擎和工作负载的写吞吐量随时间变化的情况。（所有的图表中，测试数据是1k行， so 1000实际上是 1M）：

我们能看出如下情况:

• 对于较小的表，InnoDB有更好的吞吐性能。

• 反过来也是正确的，表越大，InnoDB的吞吐性能越差（超过10M行）。

• TokuDB在oltp的工作负载上的优势并不明显，相比于InnoDB来说。

让我们再深入分析在极限情况下表大小对性能的影响，表大小从1M行开始：

一直测试到50M行结束：

在第一个场景中，我们可以看到InnoDB不光是显示了较好的写性能，还显示出了较少的偏差。在第二个场景中，我们可以确认在oltp工作负载上两者的差距不大，在其他类型的工作负载上差距就很明显了。

这不足为奇，因为TokuDB的Fractal树和InnoDB的B树之间较大的差异之一就是在添加消息缓冲区到节点的实现，而这用于处理写请求（对我来说另外一个较大的差别是节点大小）。对于写密集型工作负载，TokuDB需要做的树遍历远少于InnoDB（实际上，这只在校验唯一性约束时发生，其他的写操作都是直接插入消息缓冲区，缓冲区异步刷新到更低的树节点，我推荐你去看看这篇文档了解更多细节）。

对于oltp，InnoDB在小表上有优势，因为它读取时不需要去扫描所有的消息缓冲区（在生活中没有什么是免费的，这就是TokuDB写操作的优势所在。）我怀疑在表体积很大时这个优势会失效，因为此时，所有引擎都会变成I/O密集型。

我关注的焦点在写性能上，但是作为一个小例子可以演示下一个50M的表的响应情况，oltp工作负载下线，只跑其他工作负载：

此时，你可能会有疑问为什么我关注io2000的测试结果呢（如果你没有疑问，请忍受我啰嗦两句）。因为io3000的测试结果和通用型号的SSD显示出的特点，我将其归因为延迟。你能在下面io3000的图里看出我的意思：

我说“我归因”是因为，很不幸，我没有除sysbench以外其他的输出指标（我将会在将来的测试中修正这一问题！） 我曾经在工作时在生产环境中见过同样的模式，在那些场景中我能将它与磁盘的stime或者qtime增加联系起来。事实是这在相同工作负载，更低或者更高容量的磁盘中会出现，而在io2000中没有出现，增加了我对自己假设的信心。

结论

我不认为 TokuDB能在所有方面都替代 InnoDB，所以我的意思是我不会贸然推荐其他人从一个迁移到另一个，因为没有一个合适的评估就去做，性能方面会差别很大。

正如我说过的，我相信TokuDB在正确的场景中有巨大优势，这个测试凸显了某些方面的亮点：

• 在较慢的设备和更大的数据集上相比于InnoDB，它有显著的优势。

• 对于足够大的数据集，上述结论在快速设备上和写密集工作负载也是成立的，因为B-tree操作变得IO频繁。

 TokuDB相比较 InnoDB还有一个优势，从上述测试结果中不能直接看到：

• 更好的压缩性（得益于更大的块体积）。

• 更好的SSD生命周期，因为更多的是顺序写入（顺序写在理论上与随机写在时间上没有多大提升，所以尽管使用SSD在进行顺序和随机上没什么区别，但是在生命周期上是有区别的）。

本文由Fernando Ipar完成。