MySQL架构三：存储引擎之第三方存储引擎

MySQL从2007年开始提供了插件式的存储引擎API，从此涌出了一系列为不同目的而设计的存储引擎。其中一些已经合并到MySQL服务器，但大多数还是第三方产品或者开源项目。

1 OLTP类引擎

Percona的XtraDB存储引擎是基于InnoDB引擎的一个改进版本，已经包含在Percona Server和MariaDB中，它的改进点主要集中在性能、可测量性和操作灵活性方面。XtraDB可以作为InnoDB的一个完全的替代产品，甚至可以兼容的读写InnoDB的数据文件，并支持InnoDB的所有查询。

另外还有一些和InnoDB非常类似的OLTP类存储引擎，比如都支持ACID事物和MVCC。其中一个就是PBXT，由PaulMcCullagh和Primebase GMBH开发。它支持引擎级别的赋值、外键约束，并且一一种比较复杂的架构对固态存储（SSD）提供了适当的支持，还对较大的值类型如BLOB也做了优化。PBXT是一款社区支持的存储引擎，MariaDB包含了该引擎。

TokuDB引擎使用了一种新的叫做分型树（Fractal Trees）的索引数据结构。该结构是缓存无关的，因此即使其大小超过内存，性能也不会下降，也就没有内存生命周期和碎片的问题。TokuDB是一种大数据（Big Data）存储引擎，因为其拥有很高的压缩比，可以在很大的数据量上创建大量索引。

RethinkDB最初是为固态存储（SSD）而设计的，然而随着时间的推移，目前看起来和最初的目标有一定的差距。该引擎比较特别的地方在于采用了一种智能追加的写时复制B树（append-only copyon-write B-Tree）作为索引的数据结构。

在Sun收购了MySQL AB以后，Falcon存储引擎曾经作为下一代存储引擎被寄予期望，但现在该项目已经在很久以前就被取消了。

2 面向列的存储引擎

MySQL默认是面向行的，每一行的数据时一起存储的，服务器的传也是以行为单位处理的。而在大数据量处理时，可能面向列的方式效率更高。如果不需要整行的数据，面向列的方式可以传输更少的数据。如果每一列都单独村吃醋，那么压缩的效率也会更高。I

Infobright是最有名的面向列的存储引擎。在非常大的数据量时（数十TB），该引擎工作良好。Infobright是为数据分析和数据仓库应用设计的。数据高度压缩，按照块进行排序，每个块都对应有一组员数据。在处理查询时，访问元数据可以决定跳过该块进行排序，每个块都对应有一组元数据。在处理查询时，访问元数据可决定跳过该块，甚至可能只需要元数据就可以满足查询的需求。但该引擎不支持索引，不过在这么大的数据量级，即使有索引页很难发挥作用，而且块结构也会一种准索引（quasi-index）。Infobright需要对MySQL服务器做定制，因为一些地方需要修改以适应面向列的存储需要。如果查询无法在存储层使用面向列的模式执行，则需要在服务器层转换成按行处理，这个过程会很慢。Infobright有社区版和商业版两种。

另外一个面向列的存储引擎是Calpont公司的InfiniDB，也有社区版和商业版。InfiniDB可以在一组机器集群间做分布式查询，但目前还没有哦生产环境的应用案例。

3 社区存储引擎

如果要列举所有社区提供的引擎可能会有三位数。但是很大部分影响力有限，只有极少数人在使用。在这里举例一些，但都没有在生产环境中应用过，慎用。

① Aria：之前的名字是Maria，是MySQL创建者计划用来替代MyISAM的一款引擎。MariaDB包含了该引擎，之前计划开发的很多特性因为在MariaDB服务层实现，所以引擎层就取消了。在2013~2014年Aria就是解决了MyISAM的崩溃安全回复问题，当然还有一些特性是MyISAM不具备的，例如 数据的缓存（MyISAM只能缓存索引）。

② Groonga：这是一款全文索引引擎，号称可以提供准确而高效的全文索引。

③ OQGraph：该引擎由uOpen Query研发，支持图操作（例如查找两点之间最短的路径），用SQL很难实现该类操作。

④ Q4M：该引擎在MySQL内部实现了队列操作，这也是SQL很难实现的操作。

⑤ SphinxSE：该引擎为Sphinx全文索引搜索服务提供了SQL接口。

⑥ Spider：该引擎可以将数据切分成不同的分区，比较高效透明的实现了分片（shard），并且可以针对分片执行并行查询（可以是分布式的分片）。

⑦ VPForMySQL：改引擎支持垂直分区，通过一系列的代理存储引擎是新。垂直分区指的是可以将表分成不同列的这，并且单独存储。但对于查询来说，看到的还是一张表。改引擎和Spider的作者是同一人。