TokuDB和InnoDB的读写分析与比较

标签: tokudb innodb 分析 | 发表时间:2014-03-14 19:55 | 作者:yueliangdao0608
出处:http://blog.csdn.net
我们知道,在MySQL单机版本里面最流行的也是唯一支持全事务的引擎为INNODB。 其特点是数据本身是用B-TREE来组织,数据本身即是庞大的根据主键聚簇的B-TREE索引。 所以在这点上,写入速度就会有些降低,因为要每次写入要用一次IO来做索引树的重排。 特别是当数据量本身比内存大很多的情况下,CPU本身被磁盘IO纠缠的做不了其他事情了。  这时我们要考虑如何减少对磁盘的IO来排解CPU的处境,那么如何做呢? (当然,如果数据足够放到内存里面,这些事情大可不必考虑。)
1. 可以把INNODB 个PAGE增大?(默认16KB)但是增大也就带来了一些缺陷。 比如,对磁盘进行CHECKPOINT的时间将延后。
2. 把日志文件放到更快速的磁盘上?比如SSD?


其实这时,我们可以考虑用另外一个知名的引擎TokuDB。 谁叫MySQL 天生支持随意可插拔呢!
TokuDB 其实本身数据存储用到了B-TREE的变形版本Fractal-Tree。 Fractal-Tree 也就是在B-Tree原来的非叶子节点增加了一个缓存,无论对这个树怎么操作,都是一个模式:即父亲节点的缓存满了,就流淌到儿子节点,然后儿子节点的缓存满了后,再次流淌到孙子节点等等一系列最后到了叶子节点,然后等到叶子节点的PAGE足够大的时候,进行CHECK POINT。当然不管如何做缓存,每次事务后,还是得首先刷新到REDO 日志,要不数据一致性就很难保证了。


接下来,这里测试下同样的环境InnoDB和TokuDB的性能差异。当然,我没有做压力测试,只是简单的手动执行了几次SQL而已。
(5.6.10-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial))
用来导入的文件大概为35M。

1. INNODB.
对应的参数:
 innodb_buffer_pool_size=32M
 bulk_insert_buffer_size=20M
 query_cache_size = 0


导入性能:(InnoDB在这里慢在CPU一直忙于IO置换。)
mysql> load data infile '/tmp/t3_push.csv' into table t3_push;
Query OK, 955527 rows affected (30 min 44.03 sec)
Records: 955527  Deleted: 0  Skipped: 0  Warnings: 0


读性能:(读的性能还是很好的,这里用到5.6的ICP以及MRR特性。)
mysql> select count(*) from t3_push where rank1 < 20 and rank2 < 30;        
+----------+
| count(*) |
+----------+
|       49 |
+----------+
1 row in set (0.06 sec)


调大
innodb_buffer_pool=128M


mysql> load data infile '/tmp/t3_push.csv' into table t3_push;
Query OK, 955527 rows affected (38.72 sec)
Records: 955527  Deleted: 0  Skipped: 0  Warnings: 0
调大后,其实导入性能还是不错的。


 2. TokuDB.
(5.5.30-tokudb-7.1.0-e-log TokuDB Enterprise Server (GPL) )
对应的参数:
 tokudb_cache_size=32M
 tokudb_loader_memory_size=20M
 query_cache_size = 0


写性能:(这里IO次数很少,所以导入速度很快。)


mysql> load data infile '/tmp/t3_push.csv' into table t3_push;
Query OK, 955527 rows affected (19.73 sec)
Records: 955527  Deleted: 0  Skipped: 0  Warnings: 0


读性能:(读的速度比INNODB稍微慢了些。)
mysql> select count(*) from t3_push where rank1 < 20 and rank2 < 30;   
+----------+
| count(*) |
+----------+
|       49 |
+----------+
1 row in set (0.54 sec)
mysql> select count(*) from t3_push where rank1 < 200 and rank2 < 300;        
+----------+
| count(*) |
+----------+
|     5759 |
+----------+
1 row in set (4.13 sec)
但是TokuDB可以给二级索引变聚簇,所以这点上如果只读的话,还是会比InnoDB快。
给列rank2 加聚簇索引,
mysql> alter table t3_push add clustering index idx_rank2(rank2);
Query OK, 0 rows affected (6.79 sec)
Records: 0  Duplicates: 0  Warnings: 0


现在所有的基于索引idx_rank2 的查询都是瞬间的。
mysql> select count(*) from t3_push where rank1 < 20 and rank2 < 30;
+----------+
| count(*) |
+----------+
|       49 |
+----------+
1 row in set (0.00 sec)


mysql> select count(*) from t3_push where rank1 < 200 and rank2 < 300;        
+----------+
| count(*) |
+----------+
|     5759 |
+----------+
1 row in set (0.01 sec)




作者:yueliangdao0608 发表于2014-3-14 11:55:39 原文链接
阅读:127 评论:0 查看评论

相关 [tokudb innodb 分析] 推荐:

TokuDB和InnoDB的读写分析与比较

- - CSDN博客数据库推荐文章
我们知道,在MySQL单机版本里面最流行的也是唯一支持全事务的引擎为INNODB. 其特点是数据本身是用B-TREE来组织,数据本身即是庞大的根据主键聚簇的B-TREE索引. 所以在这点上,写入速度就会有些降低,因为要每次写入要用一次IO来做索引树的重排. 特别是当数据量本身比内存大很多的情况下,CPU本身被磁盘IO纠缠的做不了其他事情了.

Mysql InnoDB锁

- - 数据库 - ITeye博客
抄自:http://www.cnblogs.com/qq78292959/archive/2013/01/30/2882745.html. Mysql常用存储引擎的锁机制. MyISAM和MEMORY采用表级锁(table-level locking). BDB采用页面锁(page-leve locking)或表级锁,默认为页面锁.

RethinkDB & TokuDB调研测试报告

- Frank Cai - 淘宝核心系统团队博客
Rethink db&tokudb调研测试报告 View more presentations from Feng Yu..

迁移Zabbix数据库到TokuDB

- - MySQL中文网 - 叶金荣的技术和生活
线上的Zabbix数据库有几个大表数据量疯狂增长,单表已经超过500G,而且在早期也没做成分区表,后期维护非常麻烦. 比如,想删除过期的历史数据,在原先的模式下,history、history_uint等几个大表是用 (itemid, clock) 两个字段做的联合主键,只用 clock 字段检索效率非常差.

Mysql-innodb-B+索引

- - 掘金后端
这是读书笔记,Mysql,innodb系列一共3篇. Mysql-innodb-B+索引(本篇). Mysql-innodb-锁(预计20200523). Mysql-innodb-事务预计20200530). CREATE TABLE `aid_***_detail` ( //省略所有字段 PRIMARY KEY (`id`), KEY `range_idx` (`range_id`,`is_delete`,`range_detail_num`,`goods_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4复制代码.

[转][转]TokuDB中的COLA-Tree和TokuMax中的Fractal tree(分形树)

- - heiyeluren的blog(黑夜路人的开源世界)
TokuDB中的COLA-Tree.       目前无论是商业的SQL Server,还是开源的MySQL,都基本上还在用比较老的 B+Tree(SQL Server用的是标准的B-Tree)的索引结构. 从原理来说,B系列树在查询过程中应该是不会慢的,而主要问题就是出现在插入. B-Tree在插入的时候,如果是最后一个node,那么速度非常快,因为是顺序写.

MySQL 高性能存储引擎:TokuDB初探

- - 标点符
在安装MariaDB的时候了解到代替InnoDB的TokuDB,看简介非常的棒,这里对ToduDB做一个初步的整理,使用后再做更多的分享. 在MySQL最流行的支持全事务的引擎为INNODB. 其特点是数据本身是用B-TREE来组织,数据本身即是庞大的根据主键聚簇的B-TREE索引. 所以在这点上,写入速度就会有些降低,因为要每次写入要用一次IO来做索引树的重排.

Mysql Innodb 引擎优化

- 彦强 - 阿辉的空间
作/译者:吴炳锡,来源:http://imysql.cn/ & http://www.mysqlsupport.cn 转载请注明作/译者和出处,并且不能用于商业用途,违者必究. InnoDB给MySQL提供了具有提交,回滚和崩溃恢复能力的事务安全(ACID兼容)存储引擎. InnoDB锁定在行级并且也在SELECT语句提供 一个Oracle风格一致的非锁定读.

Percona XtraBackup InnoDB 備份工具

- - 小惡魔 - 電腦技術 - 工作筆記 - AppleBOY
大家可以選擇透過 yum 或 apt Repository 方式安裝,下面介紹 apt 方式即可. 將 apt 伺服器寫入 /etc/apt/sources.list. VERSION 請至換 Ubuntu Server 版號,如果您想測試實驗性版本請加入底下連結. 根據不同的 MySQL 版本來選擇 XtraBackup 指令,可以參考 Choosing the Right Binary,所以大家不要用錯指令了.

MySQL InnoDB B+树索引

- - OurMySQL
B+树索引在DB中有一个特点就是高扇出性,一般在DB中B+树的高度在2-3层左右,也就意味着只需要2-3次的IO操作即可. 而现在的磁盘每秒差不多在100次IO左右,2-3次意味着查询时间只需0.02-0.03秒. InnoDB存储引擎表是索引组织表,即表中数据安装主键顺序存放. 而聚集索引就是按照每张表的主键构造一颗B+,并且叶节点存放着整张表的行记录数据,因此也让聚集索引也是索引的一部分.