基于influxDB的工业时序数据库引擎设计

徐化岩 初彦龙

1(冶金自动化研究设计院混合流程工业自动化系统及装备技术国家重点实验室 北京 100071)2(辽宁警察学院治安管理系 辽宁 大连 116036)

0 引 言

时序数据即时间序列数据，指按照时间先后顺序变化、带时间标签的数据。时序数据主要由电力、化工、冶金等各类型实时监测、检查与分析设备所采集、产生的数据，这些数据的典型特点是：(1) 采样频率快，每秒甚至几十毫秒采样一次；(2) 测点多信息量大，一个千万吨级钢铁联合企业共有约50万个在线监测点，如果每秒采集后不压缩存储，一天需要800 GB存储空间；(3) 数据按照时间顺序产生，一经产生不再变化；(4) 一次读取的数据量大，绘制一条24小时秒级曲线需要读取86 400条数据；(5) 没有关系数据的并发写入/更改情况，没有读写共享冲突问题；(6) 单点数据价值小，对数据一致性要求没有业务数据严格。

目前，工业领域普遍的做法是使用商业实时数据库软件，如OSIsoft PI、Wonderware Insql、GE IHistorian等，作为时序数据库的存储和读取工具。随着大数据技术的发展，近年来也有一些基于HBase、MongoDB[1]等大数据平台的研究。

2013年，Errplane公司将influxDB[2]开源，经过不断改进现已在开源时序数据库中排名第一[3]。influxDB参考O’Neil P等[4]提出应用于BigTable[5]的日志结构合并树(Log Structured Merge Tree，LSM)，提出了时间结构合并树(Time Structured Merge Tree，TSM)，针对时序数据的读写分别进行了优化设计。在写入时，将数据追加写入到日志文件(Write Ahead Log，WAL)中，并在内存中进行缓存，当内存缓存达到一定大小时创建新的日志文件，并启动压缩线程，将数据按照读取优化的方式压缩成TSM数据文件。根据官方提供的数据[2]，influxDB与其他几个时序数据库的性能比较如表1所示。

表1 开源时序数据库性能对比表

influxDB起源于对服务器运行情况进行监控这一特定领域，设计了较为复杂的元数据模型以便能够保存除测点、时间、取值之外的附加属性信息。数据存储时的键为含有测点名、属性类型、取值类型的字符串，不仅占用空间多，而且索引时需要根据字符串长度计算数据位置，增加了检索计算量，这一复杂设计对于工业时序数据而言是多余的。本文参考influxDB的引擎代码，改进了TSM文件结构，实现了工业时序数据库引擎，并进行了性能测试。

1 时序数据库引擎结构

引擎自顶而下包括数据库实例、存储策略、存储分片几个层次，如图1所示。每个数据库实例包含一个或更多存储策略，用于定义存储时长，存储策略包含多个存储分片，每个存储分片负责一段时间的数据，超过时长的过期数据会以存储分片为单位进行整体删除，以提高删除效率。每个存储分片里包含一个内存缓存区、一个或更多日志文件、多个数据文件，以及用于处理写入、压缩、读取的线程。

图1 时序数据库引擎结构示意图

在写入时，系统根据数据点所属数据库实例名找到数据库实例，由数据库实例找到数据点所属数据存储策略，然后由存储策略根据数据的时间范围找到命中的存储片区，如果片区不存在则创建片区，并将数据分发给片区执行写入。存储片区负责将数据同时写入到内存缓存与日志文件中，日志文件定时压缩为数据文件，数据文件再逐步压缩为更大的数据文件，直到数据文件大小达到上限不再压缩。写入流程如图2所示。

图2 数据写入及文件压缩流程图

在读取时，系统首先找到所有命中的存储片区，由片区判断是从其内存缓存中读取还是从其数据文件中读取。如果是从数据文件中读取，利用文件中的索引快速定位数据位置，读取后由系统将所有命中片区返回的结果按照时间先后顺序合并，返回最终查询结果。读取流程如图3所示。

图3 数据读取流程图

2 TSM文件结构设计

TSM采用内存缓存和WAL日志文件来保证高效写入，内存缓存目的是代替日志文件提供对临近数据的高效读取，日志文件的目的是在数据库重启后能够重建内存缓存，日志文件不用于读取数据。由于磁盘的顺序写入速度快而随机写入速度慢(寻道和旋转延迟)，而时序数据的特点是大量数据实时采集、实时写入，为了提高写入效率将一批数据(一般为5 000到10 000点)按照数据类型、点位编号、点数、时间、值、时间、值、…、数据类型等顺序编码为字节流，如图4所示，再利用snappy算法[6]压缩后写入WAL日志文件。同时，将写入日志文件的数据以点位编号、时间、值的结构存入内存缓存区，内存缓存区与日志文件保持同步。日志文件大小固定，当达到规定大小时自动生成一个新的日志文件。

图4 WAL日志文件结构图

TSM数据文件中包含5字节文件头、多个数据块、一个索引块和8字节文件尾，如图5所示。文件头存放数据库引擎的幻数和版本号；数据块区由若干组4字节校验和与N字节数据块组成；校验和是数据块的32位循环冗余校验码；数据块为数据点的一组按时间排序后的数据经过压缩后得到的字节数组；索引块由点位编号、数据类型、数据块数量、数据块索引1、数据块索引2等构成，每个数据块索引包含数据块起始时间、数据块结束时间、数据块在文件中的起始位置、数据块字节数构成；文件尾8字节用于保存索引块在TSM数据文件中的起始字节位置。

图5 TSM数据文件结构图

3 数据的无损压缩方法

时序数据包含点名、时间和数值信息，写入一组时序数据时，如图6所示，压缩器遍历每个点，判断数值的数据类型是整数、浮点数、布尔值还是字符串，分别调用相应的压缩方法进行压缩，时间类型调用时间压缩方法压缩，将两者压缩得到的字节数组合并后写入到数据文件中。整数、浮点数、布尔、字符串、时间五种数据类型的压缩算法如下所述。

图6 数据压缩流程图

整数的压缩方法为：第一个整数不压缩，从第二个整数开始计算与前一个数的差值，并对差值通过ZigZag编码[7]将差值为负数的变为正数，然后分三种情况进行压缩：(1) 如果连续两个以上差值相等，则只存储差值及差值出现的次数；(2) 如果差值超过十六进制数值0x0800000000000000，不压缩；(3) 否则，将差值采用simple8b算法[8]进行压缩。

浮点数的压缩方法[9]为：第一个浮点数不压缩，从第二个浮点数开始与前一个数进行异或计算，得到一个64位无符号整数作为差值，当两个浮点数数值接近时得到的差值很小。当差值为0时仅存1位0；不为零时存1位1，然后用5位存储64位中位于左端的0的数量，用6位存储居右端的0的数量，再将非零位截取出来存储。

布尔值的压缩方法为：直接将布尔值用1位存储到字节末尾(每个字节有8位)，当存满1个字节后分配一个新字节。

字符串的压缩方法为：将字符串顺序添加到字节流后用snappy算法[6]压缩。

时间类型的压缩方法为：第一个时间不压缩，从第二个时间开始与前一个时间进行差值计算。第一个差值不压缩，然后从第二个差值开始计算与前一个差值的差值。如果差值的差值为0(当数据的存储间隔相同时)，仅存储0和0出现的次数；否则采用simple8b算法[8]存储该差值的差值。

4 读写性能测试

influxDB开源代码[10]采用GO语言实现，本文将引擎部分用.net framework 4.5重新实现，通过随机数发生器每秒生成50 000点整型随机数，进行了性能测试。测试硬件设备为一台ThinkPad T550笔记本电脑，CPU：i5 5200U 2.2 G双核，内存：8 GB，硬盘：256 GB固态硬盘。

写入测试是每秒随机发生5万点整型数据，重复3 600次写入，写入平均耗时310毫秒。读取性能测试进行了两组，一组测试从1条/点到200条/点，分200次读取5万点的数据，读取的数据条目数从5万条到1 000万条，如图7所示，读取耗时从2.8秒到9.2秒，随着条数增加耗时呈线性增长趋势；另一组测试分50次固定读取100万条数据，点数从1 000开始以1 000点步长一直增长到5万点，得到的曲线如图8所示，随着点数增加，用时从0.6秒到3.3秒呈线性增长趋势。

根据测试结果，引擎能够实现单实例每秒5万点的数据写入，读取相同记录数的情况下，点数越少速度越快，这主要是在TSM文件中，一段时间内相同点的数据是按时间顺序连续存储的，而不同点的数据是间隔存储的，因此点数越多文件位置的计算越多。考虑到工业时序数据库应用以单点历史曲线读取为主，TSM文件结构有利于提高读性能。

引擎的时间消耗中，用于集合运算和比较约占1/3，五种数据类型的压缩和解压缩约占2/3。由于.net framework相较.net core集合运算性能差距较大，加上浮点数、整数压缩算法性能还有提升空间，引擎通过.net core重新编译并采用性能更高的压缩算法后，读写性能会有较大提升。

图7 5万点数据读取速度曲线

图8 100万条数据读取速度曲线

5 结 语

本文按照工业时序数据的特点，参考influxDB思想设计了工业时序数据库的引擎。引擎自顶而下包括数据库实例、存储策略、存储分片几个层次，每个存储分片里包含一个内存缓存区、一个或更多日志文件、多个数据文件，以及用于处理写入、压缩、读取的线程。本文简化了TSM文件结构，数据点位关键字由influxDB的字符型改为整型，降低了存储占用和索引计算量。最后，进行了引擎的开发和性能测试。

未来，还需要做三个方面的改进：一是利用.net core重新编译提高性能；二是压缩解压缩部分替换为性能更高的算法库；三是增加分布式冗余机制，以便实现更大规模的数据吞吐量，并提高数据容错能力。