基于试飞数据的时序数据库性能测试
2021-06-11韩超
韩超
上海航空工业（集团）有限公司 上海 200120
引言
随着民机研发进程的加快，试飞愈加频繁，试飞数据飞速增长，传统的关系型数据库已不能满足试飞时序数据存储全时全量、高效写入、紧凑存储的需求，hadoop大数据系统也不能提供实时高效查询的功能。而时序数据库是专门存储时序数据的，并对其查询做了专门的优化，可以满足试飞时序数据的需求，本文将对其进行介绍，并根据试飞业务需求对其测试在试飞时序数据上的性能。
1 介绍
1.1 时序数据
时序数据，即时间序列数据，把用一系列按顺序排列的时间戳标识的数据称为时间序列数据。近年来，各行各业产生的数据越来越多，时序数据的应用更为广泛，比如风机、物联网、智能制造、环境监测领域等各方面，往过去看可以做成多维度报表，揭示其趋势性、规律性、异常性；往未来看可以做大数据分析，机器学习，实现预测和预警，所以越来越多的公司开始关注时序数据。所有有时序数据产生，并且需要展现其历史规律、周期规律、异常性等，进一步对未来做出预测分析的，都是时序数据库适合的场景。
时序数据具有以下特点，①数据产生快，每秒高频采集工况数据频率高；②数据总量大，如果机器长期处于24小时不间断采集数据的运行状态，这就对海量时序数据存储提出了要求；③数据种类多，数据的来源与格式多种多样，有布尔值、浮点数，有的传感器一个时间戳对应多个值[1]。
时序数据与关系型数据存在较大差异，①时序数据以时间戳作为唯一标识，按其大小排序区分，而关系型数据库以其他字段为标识；②时序数据不关心实体属性关系；③时序数据的数据量持续呈线性增长，机器运行期间，时时刻刻产生新数据。而关系性数据增长通常不随时间持续增长，在一段时间内相对稳定；④时序数据很少有更新操作，历史值将不会发生改变。而关系型数据对于存量数据经常需要更新[2]。
1.2 时序数据库
由于时序数据的飞速增长，及其与关系型数据的区别，一种新的数据库——时序数据库应运而生，并且应用越来越广泛。时序数据库一般具有以下特点：
1.2.1 高压缩率。海量的时序数据需要大量的存储空间，并且可能会存储很长时间，这就要求时序数据库根据数据特征进行压缩。
1.2.2 高吞吐量。由于时序数据会持续产生，并且写入的并发量大，这就要求时序数据库系统实现高吞吐的高速写入功能。
1.2.3 高效的时间窗口查询能力。时序数据的业务分两类，一是实时数据查询；二是查询某个时间段的历史数据；
1.2.4 高效聚合能力。时序业务通常会关注数据的count、avg、first_value等聚合值，来反应某时间段内的数据特征，这就需要时序数据库提供高效的聚合函数。
1.2.5 批量删除能力。时序业务对于部分历史数据有批量删除的需求。
1.2.6 通常不具备事物的能力。近年来时序数据库的产品相继出现，早在2016年7月，百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB，成为支持其发展制造、交通、能源、智慧城市等产业领域的核心产品，同时也成为百度战略发展产业物联网的标志性事件。2017年2月Facebook开源了beringe时序数据库，4月PostgreSQL开源了TimeScalaDB开源数据库；相继又出现了许多优秀的时序数据库，包括DolphinDB，InfluxDB，HiTSDB，Druid，OpenTSDB，IoTDB等。
2 基于试飞数据的性能测试
根据试飞业务需求，试飞数据在压缩率、数据写入方面要求较高，实时查询次之，故先横向对比，根据压缩率、数据写入性能选出适用于试飞数据的时序数据库，再纵向测试实时查询性能，并对其多次写入、查询性能稳定性进行测试。
本测试选取了InfluxDB、TimescalaDB、Druid、TDengine、IoTDB几种主流的时序数据库，在相同的环境下，测试相同的试飞时序数据（只测试单机版，未考虑分布式）。采用的评测环境为：
CPU型号： Intel(R) Xeon(R) CPU E5-4850 v4@ 2.10GHz(16核32线程*4）。
内存：256G(DDR4,2400MHz)。
硬盘：1T (非SSD)。
操作系统：Windows Server2012R2 Standard。
2.1 数据压缩能力
对IoTDB、InfluxDB、TimescalaDB、Druid、TDengine几种时序数据库依次写入试飞数据，对比试飞数据文件与数据库文件的空间占用情况，得出图1压缩率对比图，压缩率IoTDB＞Druid＞TDengine＞influxDB＞Timescala， DB、IoTDB的空间占用率明显优于其他几种数据库。TimescaleDB 中数据库占用的存储空间甚至大于原始数据文件的大小，由于Timescale 只对比较大的字段进行自动压缩（TOAST），对数据表没有自动压缩的功能，即如果字段较小、每行较短而行数较多，则数据表不会进行自动压缩，若使用 ZFS 等压缩文件系统，则会显著影响查询性能。
将10架次的试飞数据依次写入IOTDB中，后9架次试飞数据作为增量数据写入，数据文件tsfile空间占比如图2，可见IOTDB压缩率保持在4.5%左右，性能比较稳定，并没有随着数据库数据的增加而大幅波动，可以大大节省空间。
图1 压缩率对比
图2 压缩率
2.2 数据写入能力
将试飞数据文件写入到数据库，数据具有多频率、多时间段、多参数的特征，测试包含了乱序写入的情况。第一架次写入时数据库为无存量数据写入，后九架次试飞数据作为增量数据写入，得到文件写入速率如图3所示，IoTDB＞ TDengine ＞InfluxDB ＞ TimescalaDB ＞ Druid,显然单机状态下IoTDB写入性能明显优于其他数据库。
10个架次试飞数据依次写入IOTDB时，写入速率折线图如图3所示，显然随着试飞数据的写入，写入速率并没有明显降低，稳定在31.25M/s，写入性能比较稳定。
图3 写入速率对比图
图4 写入速率
2.3 数据查询能力
对于试飞数据来说，压缩率与写入速率是最重要的两个指标，通过测试可以看出单机情况下IOTDB压缩、写入性能明显优于其他几种数据库，并且性能稳定，下面针对IOTDB的查询性能及查询稳定性进行测试。对于数据查询，主要关注的五种常见的查询场景下，吞吐量和请求响应时间这两个指标。
2.3.1 一般查询。一般查询指的是对数据库内已有数据的一些字段进行查看。在查询的变量数不同的情况下，考察各个时序数据库的吞吐量和请求响应延时的变化。
2.3.2 时间段查询。时间段查询是时序数据库独有的场景，针对某一段时间内的某些字段进行查看。这一部分要评测的是时序数据库对于同一个时间段的请求的响应延时情况，这主要取决于数据库对时间戳的存放方式。
根据1、2查询场景，设计了所有时间范围内单参数查询和确定时间单参数查询，结果如图5所示，随着数据库试飞数据的增加，可见两种情况都在各自均值范围波动，波动很小为毫秒级；时间范围查询比确定时间的查询耗时稍多，可见随着时间范围的增加，会增加毫秒级耗时，时间上差别并不大。
图5 单参数查询
2.3.3 多参数查询。试飞数据在应用过程中，经常需要进行分包，供业务部门分析使用，针对此场景，设计了随着试飞数据的写入，时间范围内参数个数为1、50、100、150、200、250、300、350、400的查询，测评数据库的请求响应延时的变化情况。
由图6可见，随着时序数据库数据量的增加，从其中依次查询1、50、100、150...400个参数，查询相同参数的时间在相同数量级上，并没有明显的耗时增加，始终在毫秒级耗时波动，比较稳定；从另一个维度看，初始查询状态，IOTDB索引的缓存机制还没有建立，故查询耗时较大，此后查询时间急剧下降并稳定，如图7所示。
图6 多参数查询1
图7 多参数查询2
2.3.4 聚合查询。聚合查询指的是对数据库内已有数据进行例如求和、取平均值、取不同值等复杂的查询操作。我们会对各个数据库，进行不同的查询变量数、不同的查询数据量以及不同的聚合查询语句的聚合查询性能评测，考察各个时序数据库的吞吐量和请求响应延时情况。
2.3.5 降频查询。试飞数据有的数据频率较高，业务部门分析时有时需要低频率数据，分包时就需要降频率。在这一部分，我们评测的是IoTDB在查询过程中将原本的高频字段进行低频查询后，数据库吞吐量和请求响应延时的变化情况。
根据4、5查询场景，设计了1、2个参数的计数聚合查询和时间范围内的一个参数最大值、最小值、最大时间、最小时间、平均值、和、降频查询、count计数查询，结果如图8、图9所示。
由图8可得，计数聚合查询主要与IOTDB数据库的数据量有关，随着数据量的增加，耗时逐渐稍微增加，由于索引及缓存机制，可减少查询时间；由图9可得，最大值、最小值、最大时间、最小时间、平均值、和、count查询都在500ms内响应，降频统计在1500ms内响应，波动都很小，受数据库数据量的影响较小，性能稳定。
图8 计数聚合查询
图9 聚合查询
3 基于时序数据库的查询应用
基于时序数据库IOTDB，应用清华数为系统集成框架（DataWay Framework DWF）连接数据库，开发了试飞数据的参数查询平台，可以查询选定时间范围内的多个参数，并设置与预警线、均值等，如图10所示。
图10 试飞参数查询
4 结束语
本文根据试飞业务数据需求的侧重点，测试了试飞数据在几种时序数据库上的写入性能、压缩性能，并对选出的IOTDB测试了几种查询场景的性能，综合分析得出，IOTDB是比较适合应用在试飞业务中，最后使用DWF建立了试飞参数查询平台。 对于试飞业务数据来说，时序数据库的效率远远优于传统数据库，在今后会得到更加广泛的应用。
