MySQL中怎么设计时间序列存储引擎

MySQL中怎么设计时间序列存储引擎，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

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

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

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

技术介绍

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

功能层

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

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

架构

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

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

存储

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

接口层

程序片段

如下代码片段为接口层部分。

MySQL提供的基类handler，存储引擎需要提供继承自该类，并实现基类中如ha_open/ha_close等功能函数的类。

继承handler类的携程时间序列数据库的类。

接口层架构

该部分将以ha_cfl为例，说明MySQL存储引擎管理层和引擎接口之间的关系。

操作发送给会话后，会话从引擎管理层获取到ha_cfl的对象，将操作转化为对ha_cfl接口的调用，该步骤完成了SQL到存储引擎接口的对接。

ha_cfl接口接到调用后，将调用转化为对表对象的操作，完成handler接口功能到表对象的实现的对接。

效果

通过对时间序列数据进行针对性的开发，CFL存储引擎的插入性能相对于InnoDB和MyISAM引擎有很大的提高。

ips：insert per second

总结

由于本次开发为探索性质的开发，时间上或者人力上的限制使产品还不够完善，不论是设计还是实现上都存在需要改进的地方。如，创建表时对时间戳类型使用和索引列的指定存在限制，导致无法创建多列索引，仅能够创建时间索引。存储结构的限制导致删除和更新无法快速灵活的进行。

但在资源有限的情况下，完成一个概念完整和实现完整的产品。而且正是通过这次探索性开发，打开了MySQL存储引擎的一扇大门，不论从整体架构到实现细节都有深入研究，积累了很多经验。携程技术保障中心DBA团队希望这些经验在将来能够为国内的MySQL社区提供帮助。

关于MySQL中怎么设计时间序列存储引擎问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。