你需要知道的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.

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友