MySQL时间序列存储引擎的设计与实现-mysql默认存储引擎

作者简介

姜宇翔，携程技术保障中心高级研究员。具有十多年数据库领域开发经验，曾参与国产自主品牌达梦数据库版本4到版本7开发的全过程，具有丰富的数据库知识和开发经验。

加入携程后，主攻MySQL的源码研究和改造，在MySQL的存储引擎/主从复制/审计等领域皆有贡献，并对各种特性需求，进行针对性的功能开发。

当我们使用MySQL的时候，经常感慨多引擎下数据管理的灵活。不论是innobase这样带有ACID特性的数据引擎后端，还是black hole这样吃掉数据什么也不做的数据引擎后端，都在不同场合发挥着自己的作用。

享受着各种存储引擎带来的便利时，我们也注意到MySQL的存储引擎开发在国内还是一片蓝海。毕竟这种以插件方式加载到MySQL的数据后端，是一个较深涉及到底层的领域，数据库底层开发在国内也只有一少部分开发者走在这条路上。这不能不说是一个遗憾的事情。

携程技术保障中心的MySQL时间序列存储引擎缘起于一次讨论，讨论的议题是关于哪个时间序列数据库更适合携程环境。在这次日常的自由讨论中，有人突发奇想的提出，我们是否可以开发一个MySQL的时间序列存储引擎?没有已有的时间序列数据部署的繁琐，没有那些各具特色的接口调用，不需要熟悉新的系统，还是以SQL的方式来进行数据的访问。

首先，让我们看看OpenTSDB是什么样的情况。下图便是OpenTSDB的部署与运行图示。OpenTSDB的后端存储是HBASE，需要在各个server上部署信息收集的前端，通过dashboard展示信息。对于现有的时间序列数据库，每一个都有自己的部署与运行方案。而这些方案并不具备架构上的通用性。

我们所期望的架构是除了底层的存储组件不同，对于MySQL的用户来说没有什么不同。已有的大部分运维经验(HA、复制、备份等等)和已有的开发经验(插入、删除和更新的操作)都可以继承自之前的积累，这是任何一个使用MySQL的公司所希望的情况。就如下图所展示的架构，对于上层用户来说，感觉不到太多的变化。用户可以通过标准的SQL编写自己的应用客户端来完成数据的采集和展示，提高灵活性。

经过以上的考量，产生了我们的试验产品，存储引擎CFL(ctrip fast log)，该引擎能够以快速的日志方式进行数据的记录。其完成后就如下图所示，满足之前所设想的种种情况。

技术介绍

从层次结构来看，MySQL的存储引擎分为两个部分。一是实现存储功能相关的组件，该层提供存储引擎的具体功能(增删改查)，我们称之为功能层;一是和MySQL插件接口对接的组件，该层将MySQL的功能调用转换为存储引擎的功能调用，我们称之为接口层。如下图所示，数据库的操作(诸如增删改查等操作)将通过引擎管理层达到存储引擎的接口层，再由接口层到达功能层。

功能层

功能层是存储引擎的核心，由于设计目标的不同，存储引擎的功能层所提供的功能也是不同的。比如innobase引擎的功能层，提供了事务ACID/数据存储/元信息管理/MVCC等一系列功能，提供完整的数据库功能;再如CSV存储引擎，仅提供字符类型的行存储。这些不同功能的存储引擎组件，在MySQL的框架下，提供多种多样的服务。

介绍携程时间序列存储引擎的功能层将从两个主要方面介绍。一是功能层的架构，也就是运行时涉及到的对象和这些对象的作用;一是进行持久化的存储，该部分将说明在文件层面，数据是如何存储的。

架构

CFL的架构设计目标是尽可能的提高数据的插入效率，因此并行处理的想法需要贯穿始终。其机制为，不同会话并行的将数据向表对象中插入;表对象通过缓冲区保存插入的数据，当缓冲区写满之后，缓冲区加入磁盘写入队列，通过专门的写盘线程并发的写入磁盘。

下图为携程时间序列存储引擎的架构：

存储

在设计存储的时候，根据时序数据库的特点，首先考虑的是插入的效率，然后是快速的故障恢复。针对插入效率，在设计数据结构时，采用严格的顺序写入策略，以此来保证连续插入的效率。这样不论在传统硬盘还是在SSD硬盘上，都可以高效的写入。针对快速故障恢复，通过控制写入顺序(依次写入数据、索引和控制信息)，实现快速的恢复。***考虑实现上的简易性，采用索引和数据分别存储的方式，降低在同一文件中进行存储管理的控制。