Innodb 和 Tokudb 基本性能对比

硬件和参数

测试机器

测试机器是一台建立在 KVM 的 Centos, 4C、8G。作为个人开发所用。测试中只运行 MySQL。

top - 19:33:02 up 176 days,  2:47,  1 user,  load average: 0.08, 0.03, 0.05
Tasks: 139 total,   1 running, 138 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.3 us,  1.3 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.3 us,  0.7 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  8010844 total,   140608 free,  2698796 used,  5171440 buff/cache
KiB Swap:  2097148 total,  2093812 free,     3336 used.  4563576 avail Mem

版本相关

name	version
MariaDB	10.0.13
InnoDB	5.6.19-67.0
TokuDB	7.1.7

MySQL 参数设置

Variable_name	Value	des
innodb_buffer_pool_size	5368709120	5 G
innodb_thread_concurrency	20	并发数
innodb_compression_level	6	压缩等级
tokudb_block_size	4194304
tokudb_cache_size	4101552128
tokudb_read_buf_size	131072
tokudb_row_format	tokudb_zlib	压缩等级

缓存设置

为了避免缓存造成的测试查询结果失真，数据库关闭 Query_cache。

+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| query_cache_type             | OFF   |
+------------------------------+-------+

结构和数据

模拟一张用户激活表，共计1414656条。

TukuDB

CREATE TABLE `active_tokudb` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '',
  `active_date` int(11) unsigned NOT NULL DEFAULT '19700101' COMMENT '',
  `device_id` varchar(50) NOT NULL DEFAULT '',
  `original_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '',
  
  ..... 省去部分字段 .....
  
  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '',
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `device_id` (`device_id`,`original_id`) USING BTREE,
  KEY `active_date` (`active_date`) USING BTREE
) ENGINE=TokuDB AUTO_INCREMENT=528991 DEFAULT CHARSET=utf8 COMMENT='' `compression`='tokudb_zlib';

InnoDB

CREATE TABLE `active_innodb` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '',
  `active_date` int(11) unsigned NOT NULL DEFAULT '19700101' COMMENT '',
  `device_id` varchar(50) NOT NULL DEFAULT '',
  `original_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '',
  
    ..... 省去部分字段 .....

  `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '',
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `device_id` (`device_id`,`original_id`) USING BTREE,
  KEY `active_date` (`active_date`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=528991 DEFAULT CHARSET=utf8 COMMENT='';

基准测试

压缩对比

两者都设置为中等级压缩

innodb 压缩等级 innodb_compression_level 设置为 6
tokudb 压缩等级 tokudb_row_format 设置为 tokudb_zlib

同数量级数据下，两表的压缩对比如下：

TABLE_NAME	data_size	index_size
active_innodb	263.75 MB	0.00 MB
active_tokudb	249.73 MB	34.23 MB

在百万数据级下似乎 tokudb 的压缩优势并不是很明显。

OnLine DDL

索引操作（Index Operations）

对于添加索引，添加/删除列、修改列NULL/NOT NULL属性等操作，需要修改MySQL内部的数据记录，对这类操作进行Online DDL操作时，需要重建表（rebuild）。

相反，对于删除索引，修改列默认值，修改列名等操作不需要修改MySQL内部的数据记录，只需要修改结构数据frm文件，而不需要重建表（no-rebuild）。

故在此仅仅测试增加索引。

1. 一般索引
   ALTER TABLE test.active_innodb ADD INDEX active_time(active_time) USING BTREE;
   ALTER TABLE test.active_tokedb ADD INDEX active_time(active_time) USING BTREE;

2. 唯一索引
   ALTER TABLE test.active_innodb ADD UNIQUE INDEX device_id(device_id, original_id) USING BTREE;
   ALTER TABLE test.active_tokudb ADD UNIQUE INDEX device_id(device_id, original_id) USING BTREE;

表现如下表：

engine	一般索引	唯一索引
innodb	7.18 s	12.87 s
tokudb	4.46 s	20.46 s

tokudb采用的分型树索引ft-index采用更大的索引页和数据页（ft-index默认为4M, InnoDB默认为16K）， 这使得ft-index的数据页和索引页的压缩比更高。也就是说，在打开索引页和数据页压缩的情况下，插入等量的数据， ft-index占用的存储空间更少。

但tokudb采用压缩索引的速度相对innodb还是会慢一些。

字段操作（schema Operations）

TokuDB支持在轻微阻塞DML情况下，增加或删除表中的字段或者扩展字段长度。

执行在线增减字段时表会锁一小段时间，一般是秒级锁表。锁表时间短得益于fractal tree的实现。TokuDB会把这些操作放到后台去做，具体实现是：往root块推送一个广播msg，通过逐层apply这个广播msg实现增减字段的操作。

但是也要注意一些点：

1. 所有的这些操作不是立即执行， 而是放到后台中由 Fractal Tree 完成, 操作包括主键和非主键索引。也可以手工强制执行这些操作, 使用 OPTIMIZE TABLE X 命令即可, TokuDB 从1.0 开始OPTIMIZE TABLE命令也支持在线完成, 但是不会重建索引。
2. 不要一次更新多列, 分开对每列进行操作。
3. 避免同时对一列进行 add, delete, expand 或 drop 操作。
4. 表锁的时间主要由缓存中的脏页(dirty page)决定, 脏页越多 flush 的时间就越长. 每做一次更新, MySQL 都会关闭一次表的连接以释放之前的资源。
5. 避免删除的列是索引的一部分, 这类操作会特别慢, 非要删除的话可以去掉索引和该列的关联再进行删除操作
   扩充类的操作只支持 char, varchar, varbinary 和 int 类型的字段。
6. 一次只 rename 一列, 操作多列会降级为标准的 MySQL 行为, 语法中列的属性必须要指定上。如：ALTER TABLE table CHANGE column_old column_new DATA_TYPE REQUIRED_NESS DEFAULT
7. rename 操作还不支持字段: TIME, ENUM, BLOB, TINYBLOB, MEDIUMBLOB, LONGBLOB。
8. 不支持更新临时表。

InnoDB中不同的版本或不同的操作对online DDL有不同的实现方式。

早期实现方式(MySQL5.6.7之前版本)

1. COPY方式。这是InnoDB最早期支持的方式，主要实现步骤：

   1. 创建与原表结构定义一致的临时表；
   2. 对原表加锁，不允许执行DML，但允许查询；
   3. 在临时表上执行DDL语句；
   4. 逐行拷贝原表数据到临时表；
   5. 原表与临时表进行RENAME操作，此时会升级原表上的锁，不允许读写，直至完成DDL操作；

2. INPLACE方式。是MySQL5.5及之后版本为了提高创建二级索引效率的方式，所以INPLACE方式仅限于二级索引的创建跟删除。主要实现步骤：

   1. 创建临时的frm文件；
   2. 对原表加锁，不允许执行DML，但允许查询；
   3. 根据聚集索引的顺序，构造新的索引项，按照顺序插入新索引页；
   4. 升级原表上的锁，不允许读写操作；
   5. 进行RENAME操作，替换原表的frm文件，完成DDL操作。

相对于COPY方式，INPLACE方式在原表上进行，不会生成临时表，也不会拷贝原表数据，减少了很多系统I/O资源占用，但还是无法进行DML操作，也只适用于索引的创建与删除，并不适用于其他类型的DDL语句。

当前实现方式(MySQL5.6.7及之后版本)

1. Online DDL方式。

   Online DDL特性是基于MySQL5.5的InnoDB fast index creation上改进增强的。Online DDL同样包含COPY方式、INPLACE方式。
   其中，某些DDL语句不支持Online DDL的就采用COPY方式，支持Online DDL的则采用INPLACE方式，因为Online DDL是对早期INPLACE方式的增加，所以INPLACE方式根据是否涉及到记录格式的修改又分为Rebuilds Table、No-Rebuilds Table两种情形。
   Rebuilds Table操作是因为DDL有涉及到行记录格格式的修改，如字段的增、删、类型修改等。
   No-Rebuilds Table则不涉及行记录格式的修改，如索引删除、字段名修改等。

基于上面了解到的内容开始增减字段的测试。

1. 增加字段

   ALTER TABLE test.active_tokudb ADD COLUMN test_field varchar(50) NOT NULL DEFAULT ‘’ AFTER oaid;

   ALTER TABLE test.active_innodb ADD COLUMN test_field varchar(50) NOT NULL DEFAULT ‘’ AFTER oaid;

2. 删除字段

   ALTER TABLE test.active_tokudb DROP COLUMN test_field;

   ALTER TABLE test.active_innodb DROP COLUMN test_field;

表现如下：

engine	add column	drop column
Tokudb	0.70 s	0.16 s
Innodb	1 min 32.70 s	1 min 4.28 s

Tokudb因为 Fractal-tree 索引的特性, 将随机的 IO 操作替换为顺序 IO 操作。在字段的变更上有着更好的体现。

DML

InnoDB 是以主键组织的B+Tree结构，数据按照主键顺序排列。对于顺序的自增主键有很好的性能，但是不适合随机写入，大量的随机I/O会使数据页分裂产生碎片，索引维护开销很多大。

TokuDB 采用 Fractal Tree的索引结构，使其在随机写数据的处理上有很大提升。
TokuDB 解决随机写入的问题得益于其索引结构，Fractal Tree 和 B-Tree 的差别主要在于索引树的内部节点上，B-Tree索引的内部结构只有指向父节点和子节点的指针，而 Fractal Tree 的内部节点不仅有指向父节点和子节点的指针，还有一块 Buffer 区。

当数据写入时会先落到这个 Buffer 区上，该区是一个 FIFO 结构，写是一个顺序的过程，和其他缓冲区一样，满了就一次性刷写数据。所以 TokuDB上 插入数据基本上变成了一个顺序添加的过程。

Query

1. Point-Query。 where id = ? （其中id是索引）的查询操作称之为Point-Query。
   select * from active_tikedb where active_time = ‘2021-01-10 14:00:20’;
   select * from active_innodb where active_time = ‘2021-01-10 14:00:20’;

   采用分形树索引的 TokuDB 会稍微慢一些，但是在百万数量级并没有啥差距。TokuDB 稍慢是需要加载Root节点，通过二分搜索确定Key落在Root节点的键值区间Range, 找到对应的Range的Child指针。

   加载Child指针对应的的节点。 若该节点为非叶子节点，则继续沿着分形树一直往下查找，一直到叶子节点停止。 若当前节点为叶子节点，则停止查找。

   查找到叶子节点后，我们并不能直接返回叶子节点中的BasementNode的Value给用户。 因为分形树的插入操作是通过消息(Message)的方式插入的， 此时需要把从Root节点到叶子节点这条路径上的所有消息依次apply到叶子节点的BasementNode。 待apply所有的消息完成之后，查找BasementNode中的key对应的value，就是用户需要查找的值。

2. Range-Query。 where id >= ? and id <= ? （其中id是索引）的查询操作称之为Range-Query。
   select * from active_tokudb where active_time >= ‘2021-01-10 14:00:20’ and active_time <= ‘2021-01-11 23:0:00’;
   select * from active_innodb where active_time >= ‘2021-01-10 14:00:20’ and active_time <= ‘2021-01-11 23:0:00’;

   范围查询中 Tokudb 花费了1.23S, Innodb 花费了 0.56 s, 采用了分形树索引的 TokuDB 在查询上慢的特性就体现出来了。

   分形树的 Range-Query 基本等价于进行N次 Point-Query 操作，操作的代价也基本等价于N次 Point-Query 操作的代价。 由于分形树在非叶子节点的 msg_buffer 中存放着 BasementNode 的更新操作，因此在查找每一个 Key 的 Value 时，都需要从根节点查找到叶子节点，然后将这条路径上的消息apply 到 basenmentNode 的 Value上。

   在 B+ 树中，由于底层的各个叶子节点都通过指针组织成一个双向链表。 因此，只需要从跟节点到叶子节点定位到第一个满足条件的Key, 然后不断在叶子节点迭代 next 指针，即可获取到 Range-Query 的所有 Key-Value键值。因此，对于 B+ 树的 Range-Query 操作来说，除了第一次需要从 root 节点遍历到叶子节点做随机写操作，后继数据读取基本可以看做是顺序IO。

   结论通过比较分形树和B+树的 Range-Query 实现可以可知，分形树的 Range-Query 查询代价明显比B+ 树代价高，因为分型树需要遍历 Root 节点的覆盖 Range 的整颗子树，而 B+ 树只需要一次 Seed 到 Range 的起始Key，后续迭代基本等价于顺序IO。

Write (Insert/Delete/Update)

分形树是一种写优化（随机写）的数据结构， 它的写操作性能要优于B+树的写操作性能。而在B+树中，大量的这种随机写操作将导致LRU-Cache中大量的热点数据页落在B+树的上层。这样底层的叶子节点命中Cache的概率降低，从而造成大量的磁盘IO操作，导致B+树的随机写性能瓶颈。但B+树的顺序写操作很快，因为顺序写操作充分利用了局部热点数据，磁盘IO次数大大降低。

分形树插入操作的流程大致可分为以下几点：

1. 加载 Root 节点；
2. 判断 Root 节点是否需要分裂(或合并)，如果满足分裂(或者合并)条件，则分裂(或者合并)Root节点。
3. 当 Root 节点 height > 0, 也就是 Root 是非叶子节点时，通过二分搜索找到Key所在的键值区间Range，将(Key, Value)包装成一条消息(Insert, Key, Value)，放入到键值区间 Range 对应的 Child 指针的 Message Buffer中。
4. 当 Root 节点 height = 0 时，即 Root 是叶子节点时，将消息(Insert, Key, Value)应用(Apply) 到 BasementNode 上，也就是插入(Key, Value)到 BasementNode中。

在大量的插入（包括随机和顺序插入）情况下， Root 节点会经常性的被撑饱满，这将会导致Root节点做大量的分裂操作。然后，Root 节点做了大量的分裂操作之后，产生大量的height=1的节点， 然后height=1的节点被撑爆满之后，又会产生大量height=2的节点， 最终树的高度越来越高。

但每一次插入操作都落在Root节点就马上返回了，每次写操作并不需要搜索树形结构最底层的 BasementNode， 这样会导致大量的热点数据集中落在在 Root 节点的上层，从而充分利用热点数据的局部性，大大减少了磁盘IO操作。

对两表批量插入900条数据，在速度上差距不大，没有测出 TOkudb 的优势，后面想想其他办法再试试。

结论

1. 高压缩比 尤其是对字符串(varchar,text等)类型有非常高的压缩比，比较适合存储日志、原始数据等。但是我测试下来并不是很明显…

2. online DDL HCADER 特性，支持在线字段增加、删除、扩展、重命名操作。上面测试看到相对 Innodb 有明显的优势。

3. 非常快的写入性能。哈哈哈，我没测出来…

4. 支持show processlist 进度查看，这点比较人性化，Innodb 需要借助性能模式实现。

5. 没有完善的热备工具，只能通过mysqldump进行逻辑备份。

6. 不支持外键(foreign key)功能。