TokuDB vs Innodb 基准测试对比

随着业务的发展以及mysql存储数据量的越来越大，很多超大表不仅仅存储变的不易，维护也变得越来越困难，特别是频繁的ddl操作让运维变得痛苦不堪。当然表拆分可以解决类似的问题，但是对一个稳定的系统来说，表拆分对业务的影响（表”路由“或统计等）有时可能无法接受，因此迫切需要一款合适的存储引擎来解决类似的问题，技术圈里近来一直在讨论2013开源的一款TokuDB存储引擎，于是正好拿来进行了一系列的对比测试，看是否可以作为一个解决的备用方案。

硬件及参数配置说明

CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz, 2U 8 cores 32 processes;MEM: 128G ,DISK :SSD RAID1

innodb_buffer_pool_size=16G 单实例

mysql版本：percona 5.6.15

测试表个数：4 总记录数：1亿

数据总大小：24G

TokuDB传说中牛叉的特性

    1，在线创建索引，快速的索引插入和删除

    2，在线添加，扩展，删除和重命名列

    3，超高压缩比，最高25倍的压缩比

    4，一个表可以包含多个聚簇索引

    5，完全支持ACID事物的四大特性

 

   Online DDL对比

   

  通过对比可见：

        1， 在字段的修改方面TokuDB有非常明显的优势，这大大方便了对大表的维护工作

         2，因为TokuDB索引文件独立于数据文件，因此TokuDB删除索引的同时会释放表空间

 

  存储空间对比（该测试表记录 2076884 ）

  表结构：

    CREATE TABLE `toku` (
  `pid` varchar(32) NOT NULL DEFAULT '',
  `CREATETIME` datetime NOT NULL,
  `UPDATETIMES` datetime NOT NULL,
  `USER_ID` bigint(20) NOT NULL,
  `HOMEWORK_ID` varchar(255) DEFAULT NULL,
  `COMPLETE_PRACTICE` int(11) NOT NULL DEFAULT '0',
  `note` varchar(257) NOT NULL DEFAULT '',
  `CLAZZ_ID` bigint(20) NOT NULL DEFAULT '0',
  `score` int(11) NOT NULL DEFAULT '0',
  `NOTE_CHECKEDS` bit(1) NOT NULL DEFAULT b'0',
  PRIMARY KEY (`pid`)
)

   

  通过上图可见InnoDB和TokuDB存储空间的相差大概7倍，即TokuDB大大节省了存储空间。

 

 响应时间对比

 

  从原理上来说TokuDB是压缩存储，故响应时间上肯定要比InnoDB要慢，通过上图可见TokuDB的平均响应时间大概是InnoDB的2倍左右，不过按TokuDB的适用场景（存储非热点数据）来看着这算不上什么缺点。

同理可以参考：

 QPS及TPS的对比

 

     

 通过上述两个图的对比可见：TokuDB 的qps和tps 平均大概是InnoDB的一半左右，当然TokuDB的适用场景并不是高并发场景，该测试只是做一个对比。

 

总结：

TokuDB优点

   1，online ddl 非常给力，特别是对字段的修改非常快

   2，压缩比非常高通常都能达到7,8倍的压缩比

   3，完全支持ACID事物的四大特性

 TokuDB缺点

   1，响应时间相对较长

   2，online ddl 对text,blob等类型的字段不适用

   3，没有合适的备份工具，只能通过mysqldump进行逻辑备份

建议适用场景：

    1，访问频率不高的数据或历史数据归档

    2，表非常大并且时不时还需要进行ddl操作