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对比

   TokuDB vs Innodb 基准测试对比_第1张图片

  通过对比可见:

        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`)
)

   TokuDB vs Innodb 基准测试对比_第2张图片

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

 

 响应时间对比

 TokuDB vs Innodb 基准测试对比_第3张图片

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

同理可以参考:

 QPS及TPS的对比

 TokuDB vs Innodb 基准测试对比_第4张图片

     

TokuDB vs Innodb 基准测试对比_第5张图片

 通过上述两个图的对比可见: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操作

你可能感兴趣的:(sysbench)