在去年四月的 Percona Live MySQL 会议暨博览会上，TokuDB庆祝了它作为开源存储引擎的第一个全年。我仍然记得一年前读到的官方公告和它所带来的期望。这个前提非常有趣，因为它有潜力帮助 MySQL 以 InnoDB 无法做到的方式管理“大数据”。它还提供了其他有趣的功能，例如“热模式更改”，同时使我们亲爱的闪存存储的使用寿命更长。
虽然我在过去的一年中一直关注 TokuDB 的发展，但我认为我还没有没有尝试过……直到最近，Percona Server 的 abeta 版本发布，支持 TokuDB 作为插件。
如果您还没有尝试过 TokuDB，这里有一个机会。第一篇文章探讨了一些有关 TokuDB 如何融入 MySQL 的背景信息，下一篇文章（将在接下来的几天内发布）将记录我使用 Percona Server 安装它的经验。我希望你喜欢这两篇文章，如果你能花时间在文章末尾添加你的评论和问题，我将不胜感激，这样我们就可以互相学习。
正如大多数人所知，MySQL 的核心在于存储引擎。 InnoDB 彻底改变了 MySQL，不仅带来了事务功能，还为整个系统带来了稳定性和新的成熟度。即使那些并不真正需要事务的人也会对 InnoDB 的抗崩溃能力感到高兴。但你还记得不久前 InnoDB 还是一个第三方专有插件吗？首先你需要用它编译MySQL。后来，他们允许将插件安装并加载到现有服务器中，使这一切变得更加容易。但当 InnoDB 开源时，事情才真正开始蓬勃发展：它的采用率不断增加，并且慢慢地开始获得关注和人们的关注。随着代码可供任何人查看、修复和扩展，公司开始投入自己的资源来改进 InnoDB，直到它成为事实上的MySQL 存储引擎。
确实，与类似的 MyISAM 表相比，如今存储（甚至压缩）到 InnoDB 表中的数据需要更多的磁盘空间，但没有人会想到在开发过程中不会有任何折衷的一项新技术。与此同时，磁盘容量也在增加，这有助于提高字节/美元的比率，并在一定程度上补偿了 InnoDB 的美食需求。
但是磁盘容量的增加也推高了价值的界限存储。对于许多人来说，千兆字节磁盘的无限容量变成了一种限制，然后太字节磁盘发展成为“必备”，一种真正的需求。但与此同时，有这么多有趣的东西可以看、可以冲浪，人们的注意力开始引起争议，以前的商品变成了稀缺商品。如今，如果一个网站加载时间超过几秒钟，它可能会失去一些人的注意力。 SSD 磁盘在这里发挥了作用，它提供数据访问的时间只是普通主轴磁盘的一小部分。然而，它们的扩展性较差：字节/美元成本的增加与其带来的数据访问速度增益成正比，并且 SSD 磁盘的寿命（或耐用性）不太好，这导致了昂贵的投资。需要明智地使用它。因此，混合使用快速且昂贵的 SSD 驱动器来存储“流行”数据，以及使用速度较慢且便宜的主轴磁盘来存储所有其余数据已变得很常见。当然，这是一个短期解决方案，因为维护起来不太实用，并且需要大量的体力劳动来决定哪个存储什么。从长远来看，可以肯定地预测基于 SSD 的解决方案将作为廉价存储而蓬勃发展，但在此之前，有必要在“大数据”和硬件投资之间找到折衷方案。
解决这个问题的另一种方法是改变逻辑部分。如果可以在相同数量的磁盘空间中存储更多数据，并且能够以同样快的速度甚至更快地存储和检索数据，那么我们可能会获得更好的结果（在性能方面）以及更好的投资回报在存储中。这就是 Tokutek 在开发 TokuDB 存储引擎时所采用的方法。其架构的核心基于一种不同的现代索引方法，即分形树索引（FTI）。我说“不同”是因为大多数流行的存储引擎（例如 MyISAM 和 InnoDB）都有B 树索引基础，至少在过去三十年里，它仍然是有点“不受挑战”的标准。之所以“现代”，是因为它的设计考虑到了我们在同期数据系统中看到的越来越多的写入密集型工作负载，以及最新存储设备的“磨损”特征。
这两种数据结构是基于树的，将数据存储在相似的叶节点中，并利用索引键进行排序。但它们跨树管理和存储数据的方式是不同的。与 InnoDB 的 B 树实现相比，TokuDB 及其分形树结构使用更大的块大小（更大的叶子），从而实现更好的压缩（使用更少磁盘空间的关键），同时还提高了范围查询的性能。同样重要的是，TokuDB 声称通过采用消息传播系统和“最佳”缓冲机制来更好地利用 I/O。
而在传统的基于 B 树的系统中，表中所做的更改将反映在索引的更新中以适应它，TokuDB 首先将每个更改视为一条消息。这里有趣的一点是，即使在消息到达相应的叶子并对其进行修改之前，它所携带的更改也已经由数据库计算在内。就像数据库的内容是由节点中找到的数据加上树中循环的消息组成的。这为存储引擎带来了敏捷性，并在提供热模式更改方面发挥着重要作用。
关于优化的I/O缓冲系统，它是部分原因是使用更大的叶子。或者，如果您愿意，也可以反过来：因为缓冲区以更有效的方式使用，所以可以实际使用更大的叶子。这里的效率是根据带宽使用来衡量的。请记住，磁盘 I/O 的成本（时间上）比内存 I/O 的成本高很多倍；这就是使用缓冲区的原因 - 您可以更频繁地将数据填充到缓冲区（成本更低），这样您就可以更频繁地将其内容“刷新”到磁盘（成本更高）。当您将缓冲区刷新到磁盘时，缓冲区越满，您所执行的带宽使用效率就越高。 TokuDB 试图充分利用它，“单个 I/O 可以执行数百或数千个操作”。 B 树的问题在于，根据设计，很难实现高效的缓冲系统，并且您往往会经常刷新稍微填充的缓冲区。因此，最好在 B 树中保留较小的叶子，这会产生压缩效果较差的副作用。 Tokutek 工程主管 Tim Callaghan 在去年 11 月的 Percona Live London 上比我更好地解释了这些差异，他的幻灯片可在此处获取。
受益于这种 I/O 优化使用的一个场景是 write-密集应用。我们最近一直在使用 TokuDB 和 Percona Cloud Tools (PCT) 服务来存储和分析来自 MySQL 服务器的慢查询日志。压缩优势也是选择 TokuDB 作为 PCT 存储引擎的一个驱动原因，如果没有它，我们在该服务的测试阶段可以容纳的组织数量将会受到更多限制。压缩影响有多大？与 MySQL 中的其他所有内容一样，它取决于您的架构。 Shlomi Noach 报告称，他能够将 4 TB 的未压缩 InnoDB 数据（或使用 KEY_BLOCK_SIZE=8 的 2 TB 压缩 InnoDB 数据）转换为 200 GB。可能就是这么令人印象深刻。
压缩本身就是TokuDB一个巨大的吸引人的特性，但存储引擎也非常适合存储空间不是问题的场景。 I/O 优化可以帮助滞后副本，其中写入（插入）是限制因素，而不是网络。如果您需要向大表或二级索引添加列，“热架构更改”功能可能会是一个福音。这对闪存驱动器的耐用性也有同样重要的影响。 Mark Callaghan 在本博客的过去一篇文章中评论了以下内容：“对于纯磁盘服务器，TokuDB 相对于 InnoDB 的优势仅限于少数工作负载。对于纯闪存服务器，TokuDB 的优势是普遍的 — 2 倍更好的压缩（与我的数据上的 InnoDB 压缩相比）和更大（更连续）的写入意味着您将购买更少的闪存，要么它会持续更长时间，要么您可以购买更少的闪存-昂贵的闪光灯，而且使用寿命足够长“。我们不要忘记 TokuDB 中 Vadim 最喜欢的功能：在 SHOW PROCESSLIST 中实时跟踪查询进度。
Tokutek 在 TokuDB 的开发过程中巧妙地打破了传统，从另一个角度看待问题。它受益于 MySQL 的开放性及其存储引擎 API，实现了一种不同的解决方案，该解决方案考虑了当今的现实 - 更快的多核 CPU、现代但更“脆弱”的存储设备以及对“大数据”的渴望。当然，它也受益于观察基于 B 树的存储引擎如何应对过去几十年不断发展的数据系统以及新算法的开发以提出新方法。并在此过程中使一些事情变得更简单。与 InnoDB 相比，调整 TokuDB 更容易：我统计了 40 个“tokudb_”变量，而我们发现至少有 100 个以上“innodb_”变量。但它还没有经受住时间的考验。尽管我们不是在谈论全新的存储引擎（Vadim 报告了他 5 年前的第一次使用体验），但它最近已经开源，社区采用仍处于初始阶段，尽管正在稳步增长，正如我们可以看到的打开的错误数量。
很多人必须担心的一件事是，TokuDB 没有开源的热备份软件。尽管 GitHub 上有一个社区HotBackup API，其中“是可插拔备份实用程序的规范，”，目前唯一可用的热备份工作解决方案捆绑在Enterprise 中TokuDB 版本。由于 TokuDB 的设计不允许采用基于复制数据库文件，然后应用包含备份期间数据库中所做更改的日志的备份方法（这就是 MySQL Enterprise Backup 和 Xtrabackup 的工作原理），因此无法轻松扩展现有的开源软件（例如 Percona XtraBackup）包括 TokuDB。
希望我们能在不久的将来看到一个新的开源备份软件实现可用的 API，但目前社区似乎只剩下文件系统级快照基于 mylvmbackup 和 xfs_freeze 等工具作为专有解决方案的唯一替代方案。
