TokuDB介绍——本质是分形树（一个叶子4MB）+缓存减少写操作

其性能特点见：http://www.cnblogs.com/billyxp/p/3567421.html

TokuDB 是一个高性能、支持事务处理的 MySQL 和 MariaDB 的存储引擎。TokuDB 的主要特点则是对高写压力的支持。

总体来说TokuDB具有：

　　1、高压缩比，官方宣称可以达到1：12。

　　2、高insert性能，官方称至少比innodb高9倍。

　　3、可以在线添加索引和字段，速度快。

TokuDB

它架构的核心基于一个不同的、现代的检索方法，名为分形树索引（FTI，Fractal Tree Indexes）。我所说的“不同”在于，大部分流行的存储引擎，比如MyISAM 、 InnoDB，都是基于B树索引。在过去至少30年内，该索引都保持着，作为某种无法挑战的标准。我所说的“现代”，是因为FTI的设计考虑到了写-密集型操作（这种操作在现在的数据系统中出现的越来越频繁）以及最新存储设备易损耗的特性。 两种数据结构都是基于树的，类似地在叶节点中存数数据，并且利用索引Key值加速排序。但是它们通过树来管理与存储数据的方法是不同的。

TokuDB以及它的分形树索引与基于B树的InnoDB相比，使用的块大小更大（更大的叶子节点），进而数据能够得到更好的压缩（使用更小磁盘空间的关键技术），也提高了范围查询的性能。同样重要的是，TokuDB称能够通过一个消息传递系统与“优化的”缓存机制来更好的利用I/O。 尽管在基于传统B树的系统中，对表的一个改变会触发索引的相应更新，TokuDB最初会将每一个改变都当做一条消息。有意思的是，在消息到达相应的叶子节点并作出修改之前，它所带来的改变就已经存在于数据库中了。

于是，数据库的内容则是叶子节点中存储的数据加上消息循环中的数据。这使存储引擎更加敏捷，举例来说，这会在热模式转换（Hot Schema Changes）中发挥重要的作用。 对于优化的I/O缓存系统的读操作，与更大的叶子节点的使用有关。或者如果你愿意的话，也有另外的方法：更有效的方法来使用缓存，使得更大的叶子节点的使用成为可能。这里提到的有效主要指的是带宽使用程度。

需谨记，从消耗的时间来看，对磁盘的I/O远大于对内存的I/O;这就是使用缓存的原因——更频繁的将数据储存于缓冲中（低消耗），就可以减少将缓存“刷到”磁盘的频率（高消耗）。刷到磁盘的缓冲区越满，可以达到的带宽利用率越高。TokuDB试图最大限度的利用缓存，即“对单个I/O进行成千上万次操作”。B树的问题是因为设计的原因，它很难实现一个有效的缓存系统，而人们经常习惯将不太满的缓存刷到磁盘。因此，对于B树来说，更好的方法是在B树中维持小一些的叶子节点，这样产生的副作用是使压缩变差。

Tokutek的工程负责人Tim Callaghan 11月份时在Percona Live London解释了对比的各种不同，比我解释的要好得多， 优化使用I/O，使得写操作密集型应用受益良多。目前在我们的Percona Cloud Tools （PCT）中使用TokuDB，用来存储和分析来自MySQL服务器的查询日志。选择TokuDB作为PCT存储设备的另一个好处是压缩性能更好，如果没有这个的话，在PCT服务beta阶段，我们会在支持的用户数上受到很多限制。压缩的影响究竟有多大?就像MySQL中的其他事情一样，这取决于你的模式。

据Shlomi Noach报导，他能够把未压缩的InnoDB引擎的4TB数据（或者是使用KEY_BLOCK_SIZE=8压缩的InnoDB引擎的2TB数据）压缩到200GB。这样能够给大家一个感性的认识。 压缩本身就是TokuDB一个很吸引人的特性，但是对于存储空间的大小不是问题的应用场景，这个存储引擎也做的不错。对于写（INSERT）性能而并非网络是性能瓶颈的场景来说，对I/O的优化能够延迟副本操作。如果你需要对一个大表添加一列或者添加第二索引，“热模式转换”功能将助力不少。对于闪存磁盘的持久性也有不少重要影响。Mark Callaghan对于之前的文章做过以下评论：“与InnoDB相比，全磁盘服务器使用TokuDB支持更大的负载压力，全闪存的服务器使用TokuDB是通用的——2倍以上的压缩率（与InnoDB的压缩相比）以及批量的写操作（更多是顺序写）意味着你你可以买更少的闪存、这些闪存可以用更久、买更为廉价的缓存也能够用”。另外，不要忘了TokuDB中让Vadim最赏心悦目的一个特性：支持使用SHOW PROCESSLIST跟踪查询的实时进展。

摘自： http://www.searchdatabase.com.cn/showcontent_85622.htm

更多见分形树这个数据结构的介绍。