3.2 Query Cache：
3.3 Storage Engine
A, TokuDB features:
- insert performance accelerated from 20 to 80 times
- the compressed data to reduce the storage space
- the amount of data can be extended to several the TB
- does not index fragmentation
- Support Hot Column Addition, Hot Indexing and MVCC
Storage engine with a highly scalable: TokuDB
ON. Posted
2013 Nian 4 Yue 29 Ri · 5 Comments · 1,429 views
What TokuDB that? TokuDB is an application in MySQL and MariaDB in the storage engine, it uses an index to speed up queries, highly scalable and supports Hot Schema Modification. If you record the number of billions of dollars, store the old records or want to reduce the storage space occupied by the data, it is suitable to use TokuDB. This article is an excerpt from Taobao core system team blog to share documents, and the bottom has the original address and downloads.
A, TokuDB features:- insert performance accelerated from 20 to 80 times Two, TokuDB to install and use:
三、Fractal Tree：TokuDB Fractal Tree index structure is used, the fundamental TokuDB settle down, the insertion performance can be best matching B-tree, the B-tree than two orders of magnitude worst case.
1, Fractal Tree structural characteristics 2, the establishment of Fractal Tree
3, Fractal Tree of establishment (cont.)
4, query on Fractal Tree
Four, TokuDB provide special support:Hot Index Creation，TokuDB允许在已有table上创建索引，同时在索引创建的过程中可以进行insert和query操作。 Hot Column Addition and Deletion(HCAD)，TokuDB允许在已有table上添加或者删除属性列，同时只在很短的时间内阻塞update和query操作。 五、TokuDB占用的存储空间：
六、如何使用TokuDB？如果你要存储blob，不要使用TokuDB，因为它限制记录不能太大； 附上以上相关内容的ppt文档百度网盘下载地址：RethinkDBTokuDB调研测试报告.pptx 以上内容来源于：淘宝核心系统团队博客 |
|
| http://mysql.taobao.org/monthly/2017/07/04/ | |
你需要知道的MySQL开源存储引擎TokuDB在四月份的Percona Live MySQL会议上， TokuDB庆祝自己成为开源存储引擎整一周年。我现在仍能记得一年前它刚创建时的官方声明与对它的期望。当时的情况非常有意思，因为它拥有帮助MySQL管理大数据的潜力，而这是InnoDB无法做到的。TokuDB还有一些有意思的特性，比如”热模式转换（hot schema changes）”，可以使我们昂贵的闪存能够持续更长时间。
尽管在过去这一年里，我一直在关注TokuDB的发展，但我一直认为我不会去尝试使用它。直到最近，Percona Server发布了支持TokuDB插件的beta版本，我才觉得值得一试。 如果你还没有尝试过TokuDB，现在就是一个机会。首先我将介绍TokuDB是如何与MySQL协同工作的。 大家都知道，MySQL的核心在于存储引擎。InnoDB已经完全改变了MySQL，不仅让MySQL支持事务处理，并让整个系统变得更加成熟和稳定。即使是那些并不是事务特性的应用使用InnoDB也自得其乐。但是你是否记得不久之前InnoDB也是第三方专有插件呢?首先你需要将它与MySQL进行编译。然后将能够很容易的将该插件安装或者下载到已存在的服务器中。但是当InnoDB开源之后，一切就变得繁荣昌盛起来：人们越来越能接受它，而且慢慢地，它走上了正轨，得到了人们的推广。任何一个人都能阅读、修复、扩展它的编码，很多公司提交自己的修改融入其中，让InnoDB变得更好，直到它成为MySQL的首屈一指的存储引擎。 平衡大数据与存储成本目前来看，与类似的MyISAM表相比，数据存（即使是压缩存储）到一个InnoDB表中需要的磁盘空间的确要更大，但是没有人会认为在一项新技术发展过程中不会出现缺点和不足。同时，磁盘的存储能力也在增强，这也有助于平衡每字节的价格，而且也能补偿InnoDB的空间需求。 但是磁盘容量的增加也对“什么值得存储”的界限进行了扩展。曾经的GB级磁盘既是近乎无限的存储空间，到如今已经成为有限，而TB级的磁盘成为了标配和基本需求。同时，尽管有大量有意思的东西可以浏览和探索，人们的注意力开始涣散，之前能够牢牢抓住现在却常常难以吸引眼球。如今，如果一个网站需要数秒才能进入，那么有些人就可能会失去兴趣。 SSD磁盘开始进行挽救这种情况，只需普通机械磁盘耗时的一小部分便能访问到数据。然而SSD在容量的扩展性却不太好：每字节成本的增加是跟与数据获取速度成比例的，而且SSD的寿命（或称持久性）不是很好，这是一笔昂贵的支出。需要明智地使用SSD。 基于这个原因，现在人们逐渐开始采用混合使用的方式，用快速、昂贵的SSD磁盘存储“热”的数据，将更慢一些、便宜一些的机械磁盘存储其他所有的数据。当然，这只是一种短期内可使用的方案，因为这难以维护，并要求大量专业人才去决定每一种磁盘存储哪种数据。长期来看作为一种较为便宜的存储，可以预测基于SSD的方案将发展的更好。但是，在此之前，还是很有必要在大数据与硬件投资之间做出权衡，做合乎两方的选择。 TokuDB的前提解决这个问题还有一个办法，就是转变逻辑。如果能够在同样大小的磁盘容量中储存更多数据，而且能够存储、读取的更快，那么我们就可能得到更好的结果（从性能方面来讲）并获得存储投资带来的更好回报。这就是在TokuDB存储引擎发展过程中，Tokutek要达到的目标。它架构的核心基于一个不同的、现代的检索方法，名为分形树索引（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跟踪查询的实时进展。 展望Tokutek擅长打破传统，并从其他角度出发找到了TokuDB发展中的问题。它受益于MySQL的开放性，使用它的引擎API实现了一个完全不同的方案，该方案脱胎于对现实的深思熟虑——更快的多核CPU、现代却又“脆弱”的存储设备以及对“大数据”的渴望。当然，它也受益于对基于B树的存储引擎的观察，该引擎在过去数十年内处理了不断进化的数据，伴随着新方法和新算法到来，一直让事情变得更加简单。与InnoDB相比，TokuDB更容易进行调优：我统计过共有40个“tokudb_”变量，而“innodb_”有超过100个。但是这还需要时间的考验。尽管我们并不是在讨论一个崭新的引擎（Vadim在5年前就记录过他对该引擎的使用经历），但该引擎最近变成了开源的、公共的，并处于初始阶段。尽管在稳步发展，我们也还是能看到很多未解决的bug。 令人担忧的是目前并没有支持TokuDB的开源热备份软件。尽管有一个“可插拔备份工具标准”在GitHub上提供有HotBackup的API，而目前唯一一个可能存在的热备份方案存在于TokuDB的企业版本中。TokuDB的设计并不适用于“拷贝数据库文件、然后在把存有数据库变化的日志应用到文件上”这样的备份方案，而这正是MySQL Enterprise Backup及Xtrabackup的工作方式，所以现在仍然没有希望，简单扩展一个已存在的开源软件来就可以支持TokuDB，如Percona XtraBackup 之类的软件。 我们将充满希望的看到一个新的开源备份软件到来，它将在不久的未来使用对外的API来实现，但是现在看来多数软件还是基于快照的工具，停留在文件系统水平，如mylvmbackup和 xfs_freeze，它们可以暂时作为未来新方法的替代方案。 |
|
| https://dbaplus.cn/news-149-418-1.html 腾讯互娱 DBA 排坑集锦
|
|
在四月份的Percona Live MySQL会议上， TokuDB庆祝自己成为开源存储引擎整一周年。我现在仍能记得一年前它刚创建时的官方声明与对它的期望。当时的情况非常有意思，因为它拥有帮助MySQL管理大数据的潜力，而这是InnoDB无法做到的。TokuDB还有一些有意思的特性，比如”热模式转换（hot schema changes）”，可以使我们昂贵的闪存能够持续更长时间。
尽管在过去这一年里，我一直在关注TokuDB的发展，但我一直认为我不会去尝试使用它。直到最近，Percona Server发布了支持TokuDB插件的beta版本，我才觉得值得一试。
如果你还没有尝试过TokuDB，现在就是一个机会。首先我将介绍TokuDB是如何与MySQL协同工作的。
大家都知道，MySQL的核心在于存储引擎。InnoDB已经完全改变了MySQL，不仅让MySQL支持事务处理，并让整个系统变得更加成熟和稳定。即使是那些并不是事务特性的应用使用InnoDB也自得其乐。但是你是否记得不久之前InnoDB也是第三方专有插件呢?首先你需要将它与MySQL进行编译。然后将能够很容易的将该插件安装或者下载到已存在的服务器中。但是当InnoDB开源之后，一切就变得繁荣昌盛起来：人们越来越能接受它，而且慢慢地，它走上了正轨，得到了人们的推广。任何一个人都能阅读、修复、扩展它的编码，很多公司提交自己的修改融入其中，让InnoDB变得更好，直到它成为MySQL的首屈一指的存储引擎。
平衡大数据与存储成本
目前来看，与类似的MyISAM表相比，数据存（即使是压缩存储）到一个InnoDB表中需要的磁盘空间的确要更大，但是没有人会认为在一项新技术发展过程中不会出现缺点和不足。同时，磁盘的存储能力也在增强，这也有助于平衡每字节的价格，而且也能补偿InnoDB的空间需求。
但是磁盘容量的增加也对“什么值得存储”的界限进行了扩展。曾经的GB级磁盘既是近乎无限的存储空间，到如今已经成为有限，而TB级的磁盘成为了标配和基本需求。同时，尽管有大量有意思的东西可以浏览和探索，人们的注意力开始涣散，之前能够牢牢抓住现在却常常难以吸引眼球。如今，如果一个网站需要数秒才能进入，那么有些人就可能会失去兴趣。
SSD磁盘开始进行挽救这种情况，只需普通机械磁盘耗时的一小部分便能访问到数据。然而SSD在容量的扩展性却不太好：每字节成本的增加是跟与数据获取速度成比例的，而且SSD的寿命（或称持久性）不是很好，这是一笔昂贵的支出。需要明智地使用SSD。
基于这个原因，现在人们逐渐开始采用混合使用的方式，用快速、昂贵的SSD磁盘存储“热”的数据，将更慢一些、便宜一些的机械磁盘存储其他所有的数据。当然，这只是一种短期内可使用的方案，因为这难以维护，并要求大量专业人才去决定每一种磁盘存储哪种数据。长期来看作为一种较为便宜的存储，可以预测基于SSD的方案将发展的更好。但是，在此之前，还是很有必要在大数据与硬件投资之间做出权衡，做合乎两方的选择。
TokuDB的前提
解决这个问题还有一个办法，就是转变逻辑。如果能够在同样大小的磁盘容量中储存更多数据，而且能够存储、读取的更快，那么我们就可能得到更好的结果（从性能方面来讲）并获得存储投资带来的更好回报。这就是在TokuDB存储引擎发展过程中，Tokutek要达到的目标。它架构的核心基于一个不同的、现代的检索方法，名为分形树索引（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跟踪查询的实时进展。
展望
Tokutek擅长打破传统，并从其他角度出发找到了TokuDB发展中的问题。它受益于MySQL的开放性，使用它的引擎API实现了一个完全不同的方案，该方案脱胎于对现实的深思熟虑——更快的多核CPU、现代却又“脆弱”的存储设备以及对“大数据”的渴望。当然，它也受益于对基于B树的存储引擎的观察，该引擎在过去数十年内处理了不断进化的数据，伴随着新方法和新算法到来，一直让事情变得更加简单。与InnoDB相比，TokuDB更容易进行调优：我统计过共有40个“tokudb_”变量，而“innodb_”有超过100个。但是这还需要时间的考验。尽管我们并不是在讨论一个崭新的引擎（Vadim在5年前就记录过他对该引擎的使用经历），但该引擎最近变成了开源的、公共的，并处于初始阶段。尽管在稳步发展，我们也还是能看到很多未解决的bug。
令人担忧的是目前并没有支持TokuDB的开源热备份软件。尽管有一个“可插拔备份工具标准”在GitHub上提供有HotBackup的API，而目前唯一一个可能存在的热备份方案存在于TokuDB的企业版本中。TokuDB的设计并不适用于“拷贝数据库文件、然后在把存有数据库变化的日志应用到文件上”这样的备份方案，而这正是MySQL Enterprise Backup及Xtrabackup的工作方式，所以现在仍然没有希望，简单扩展一个已存在的开源软件来就可以支持TokuDB，如Percona XtraBackup 之类的软件。
我们将充满希望的看到一个新的开源备份软件到来，它将在不久的未来使用对外的API来实现，但是现在看来多数软件还是基于快照的工具，停留在文件系统水平，如mylvmbackup和 xfs_freeze，它们可以暂时作为未来新方法的替代方案。