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的作者是同一人。

你可能感兴趣的:(MySQL)