TokuDB 与 InnoDB 基准测试

﹏ヽ暗。殇╰゛Y 2022-05-11 02:03 227阅读 0赞

**一、背景介绍**

TokuDB架构的核心是基于一种新的叫做分形树（Fractal Trees）的索引数据结构，故而有非常快的写入性能。

TokuDB还拥有很高的压缩比（官方称最大可达25倍），可以在很大的数据上创建大量的索引，并保持性能不下降。同时，TokuDB支持ACID和MVCC等特性，使其在某些特定的应用领域（如日志存储与分析）有着独特的优势。

在TokuDB的应用场景中，通常是数据库插入操作的量远远大于读取的量，因而本测试主要针对TokuDB的插入性能以及压缩比，以InnoDB作为参考基准。

**硬件及参数配置说明**

<table> 
 <tbody> 
 <tr> 
 <td colspan="4" style="border-color:#a7a7a7;vertical-align:top;"> CPU: Intel Xeon E312xx (Sandy Bridge), cpu cores : 1;8 processes; MEM: 32G </td> 
 </tr> 
 <tr> 
 <td style="border-color:#a7a7a7;vertical-align:top;width:361px;"> innodb_buffer_pool_size=16G 单实例 tokudb_cache_size=16G </td> 
 <td style="vertical-align:top;width:204px;"> mysql版本：percona 5.6.41 </td> 
 <td style="vertical-align:top;width:284px;"> 测试表个数：1 总记录数：1亿 </td> 
 </tr> 
 </tbody> 
</table>

**二、测试方法**

1.采用sysbench进行压测

2.sysbench针对mysql压测的参数有很多，这里选取的是与实际应用场景最为相关的参数：线程数量。线程数对应的到MySQL数据库上的连接。其他的参数，如表的大小，是否是事务等可能影响整体的插入性能，但影响并不显著。

线程数量分别为： 1 2 4 8 16 32 64 128

3.单表，1亿行数据

**三、测试结果**

**1.****在不同线程数下，tokudb 和 innodb 的写性能对比：**

![70][]

图一：innodb

![70 1][]

图二：tokudb

**2.****测试压缩比直接使用的mysqldump工具**

![70 2][]

**3.****压缩算法：**

依次将TokuDB的tokudb\_row\_format设置为不同的压缩算法，得到其导入后的实际存储空间以及导入时间，测试结果显示：

压缩能力：

tokudb\_lzma > zlib >quicklz >snappy

1.  几种压缩算法耗时差不多，相差很小
2.  不同的压缩算法的压缩比差异较大，所消耗的CPU 差距很大。

使用lzma库压缩模式高CPU消耗

quicklz消耗CPU较低

zlib介于两种中间

1.  zlib作为官方选择的默认压缩算法，在压缩比和CPU消耗上有较好的平衡。

结合在测试过程中CPU的使用情况，因而，在实际生产环境中，如果没有特殊的考虑，建议使用zlib压缩（默认）算法。

**四、测试小结**

1. TokuDB在写操作（Insert）的表现优于InnoDB，在并发增长的情况下表现亦优于InnoDB。

2. 在此次实际测试中，InnoDB峰值约为 6571.58per sec，TokuDB峰值约为9362.47 per sec。

3. 在数据压缩方面，同时生成1亿行数据，TokuDB表大小约为19G，InnoDB表大小约为 21G。（说真的压缩效果差强人意）

这里需说明的是测试中TokuDB所启用的默认压缩选项为’zlib’，而InnoDB未启用压缩。InnoDB也具有压缩功能，只不过压缩行为是TokuDB的默认行为。在本文测试中并未使用InnoDB的压缩格式。

[70]: /images/20220511/17ed4c115b934003a32b8259867727dc.png
[70 1]: /images/20220511/3baaa3d712734677b3ec9e83c9453423.png
[70 2]: /images/20220511/d83df94a5c304986a38932383aec6101.png