2019大数据产业峰会|中国信通院王妙琼：时序数据库性能测试基准解读

为了深入落实国家大数据战略，推动大数据产业交流与合作，展示我国大数据产业最新发展成果，2019年6月4日至5日，由中国信息通信研究院、中国通信标准化协会主办、大数据技术标准推进委员会承办的2019大数据产业峰会在北京国际会议中心隆重举办。

会上，来自工业和信息化部的领导，我国众多优秀大数据领域服务商、行业应用客户、研究机构、地方大数据主管机构的领导和专家，对大数据政策、产业、技术的现状与趋势等内容进行交流探讨。

6月5日，在大数据前沿技术分论坛上，中国信通院云计算与大数据研究所工程师王妙琼带来了《时序数据库性能测试基准解读》。

王妙琼：各位嘉宾大家上午好，我是来自中国信通院云大所的工程师，接下来向大家介绍我们在时序数据库性能基准方面做的工作。

光聊性能测试可能有些枯燥，在这里先介绍一下我们在时序数据库方面的前期铺垫。从2018年年初开始，大数据技术标准推进委员会（CCSA TC601）联合工业互联网产业联盟（AII）工业大数据特设组开始工业数据管理和应用方面的研究。我们抓住了工业数据管理和应用中一个比较关键的点，就是时序数据库。在传统的工业中使用较多的叫实时数据库，是业生产运营环节中的重要支撑，连接着生产各环节的监控数据，实时地对外反馈给监控，监测工业生产运行的情况。

随着工业互联网进一步推进，对于数据库的要求进一步的提升，随着传感器数量的增加，数据类型和规模都在不停的变大，并且数据从简单的写入和实时反馈需求逐渐转移到大量的分析需求，所以传统工业上使用的实时数据库也在做一定的转型，而在互联网和物联网领域诞生出的时序数据库也在逐步向工业互联网的应用场景进行探索。

我们可以发现在工业场景里的监测数据都是时序数据，而这些数据和物联网、互联网的监控数据有些极其相似的内容，包括他们的数据操作非常类似。一个是数据带有时间戳，而且是按顺序生成的。第二数据都是结构化的，很少有更新或者删除的操作。数据一般是按到期日期来管理，主要以写操作为主、读操作为辅。数据都有统计和聚合的计算要求，而且长度一般不会很大，一般传感器的数据都会非常短，但是量会非常大。最后一个相似点是，做分析的时候数据一般会按照指定时间段或者数值范围做聚合计算。

我们在2018年上半年联合了很多家企业一起制定了时序数据库功能相关的标准，看在不同的业务需求场景下，是不是有一套统一的规则可以评判一个时序数据库是否符合需求，是否可以用统一的标准判断它的能力。

时序数据库的功能标准主要是六大块内容：功能、兼容能力、安全性、管理能力、容错能力、扩展性。这些内容综合了互联网、物联网、工业互联网这些场景里通用的需求，也保留了时序数据库各家产品的特质。我们可以看到有些功能是时序数据库特有的，比如说时间序列可扩展以及最新数据查询。最新数据查询主要是用于一些实时监控场景，数据导入到数据库里以后能不能及时反映到监控上。还有一些新的需求，比如物联网方面地理位置的查询需求，从时间的维度的分析增加到了空间的维度。还有互联网生态的对接，比如在兼容对接里有大数据处理的对接，现在很多时序数据库已经不仅仅满足于封闭环境的需求，需要结合一些大数据的分析能力提供更加丰富的使用场景。在安全性方面，有一条是加密通信，这也是一些生产现场所需要的安全性的要求，我们把这一条也加入了功能性标准里。

基于这个标准，在2018年下半年我们开展了一轮测试，有7家公司参加。这7家公司有主流的云服务厂商百度、阿里、华为、腾讯，有创业公司比如涛思数据，有传统工业信息化企业朗坤智慧，他们侧重在不同的领域。从测试情况来看，这些企业都通过了基础的必选测评项，在可选项里也都有各自领域的发挥。

我们在测试结束后总结出来当前时序数据库所具备的一些特点，有如下几点：

1、架构多样化。现在时序数据库架构都是非常多样的，除了传统的关系型架构之外，更多会使用一些NoSQL架构来增加扩展性，还有时序数据库是基于搜索引擎做的，另外一些是纯自研的架构。

2、主流的时序数据库都是分布式架构，传统做信息化的时序数据库也在往分布式架构演进。

3、数据结构方面分单值模型和多值模型两种。

4、生态对接，测试中所有数据库都可以满足与大数据平台对接和交互。

5、不强制 SQL 支持，但现在越来越多的时序数据库增加了这方面的功能以满足用户的使用需求。

6、需求转变，很明显时序数据库功能要求从快速的写入逐步转向大量的分析，传统的时间维度分析也在扩展到时间+空间的分析。

在完成功能方面的测试之后，今年接下来，我们计划做时序数据库性能方面的标准。性能是时序数据库非常重要的一块，但因为时序数据库大多数都是一些NoSQL或者自研的架构，所以现在业界还没有统一的标准来评判具体的性能要求。现做性能测试都是自家根据业务需求设计一些简单的性能测试场景或者根据客户定制化的要求做POC测试，没有统一的能达到工业级稳定性和性能的测试基准覆盖主流的应用场景，无法用一个通用的标准去评判时序数据库的性能。

基于这个原因，我们TC601这边进行了性能测试基准方面的规划，将性能测试方面的要求转化成了6个选项。目的是公平公正地评价产品的性能，一是要贴合实际的需求；二是要有相同可量化的标准。

6个选项为：

1、测试环境。测试环境一定要相同，大家在同样的测试环境当中评判各自产品的能力。

2、测试场景。数据库的应用场景很多，我们如何从不同的应用场景当中提炼出一些相同的技术需求去设计我们的用例。

3、数据准备。数据准备是非常重要的一块，我们如何设计数据集以贯穿整个测试，使数据的组合有效、可操作且能反映出产品的能力，让大家都可以基于这个数据集做相同标准的评判。

4、考察指标。如何设计考察指标来评判时序数据库在各方面的性能

5、数据操作。数据操作需要可解释、易操作、可复制，需要保证每个产品测试时，对数据的操作是相同的，不会影响的性能的评判。

6、考察维度。最后达到效果是什么样子的，以及一些其他维度的考虑，是不是考察集群的性能、单机性能以及不同并发情况下的性能，如何通过其他小的细节保证这个测试的公正性。

为此我们收集了时序数据库的一些实际应用需求。例如在在电厂监控场景中，一般会涉及到的标签数量就可以达到5-10万，每天数据量100G，压缩后数据量3G左右。要求长期存储、高效查询、快速分析，这也是我们性能考察的同时需要考虑的应该符合的一些功能方面的需求。

智能网联汽车，现在新能源汽车数据上云需求非常大。这个例子中，汽车GPS位置数据、发动机状态、停车时长等数据都会按一定时间传输到云上。按每隔10秒传一次，两万辆汽车同时往上传，每天会有100亿个数据点的数据量，75G/天。会统计车辆一段时间的运行轨迹、停车时长、运行时长等等。

我们从这两个典型案例中提炼出5大性能考察项，覆盖了时序数据库的主要应用特征：写入能力、查询能力、数据聚合能力、数据批量导入能力、压缩效率。

在设计数据集的时候，其实我们争论了很久，开了两次会议，大概80%的时间都在讨论数据集应该怎么设计，这里提3个数据集应该考虑的特点：

时间线。时序数据中有一个重要的概念：测点，可以通俗的理解为一个不断产生数据的传感器，一个测点在一段时间内产生的数据为一条时间线，测点数量、时间长度和密度可以决定数据量的大小。这里有个小的例子，每个配电柜有三个传感器也就是三个指标，每时每刻都在不停的产生数据，横向是一个时间轴，在这个时间轴里面会产生时间线，时间线包含着每个传感器在这段时间里面产生的所有数据。数据集的设计其实需要设计到测点数量的概念，测点数量和时间长度会影响时序数据的写入性能和最后分析的性能。

数据类型。在刚刚提到的两个场景中，对数据类型的要求是不一样的。智能网联汽车场景里面主要会涉及到大比例的Double和Long类型的数据，比如GPS数据、CAN总线数据，此外还包含Bytes数据和String数据。电厂监控不涉及string数据，更多是float数据和Bool数据。我们需要考虑这几个数据类型的配比问题。

实时/历史数据源。为什么区别这两种数据源？传统的数据库测试一般都会使用历史数据源，相当于摆一大桌子菜在桌子上，大家能吃多少就吃多少，能吃多快吃多快，也能测出性能。但是时序数据库的场景不一样，好比旋转寿司店，小碟子在不停的传过来，如果不吃掉就转走了，数据也一样，传过来如果不能及时处理掉，可能造成数据积压或丢失。在典型的时序数据库场景里面数据是源源不断生成的，比如有十万个传感器，每秒产生一个数据点，每秒就有十万条数据。如何及时处理数据是需要考虑的关键性问题，所以在时序数据性能测试场景当中不能仅仅考虑历史数据源导入问题，还需要设计实时数据源。

除了刚刚提到的这些数据集的注意点，为了让测试基准更贴近现场需求，我们也设计了读写混合的场景及其他一些细节。比如在工厂现场，不会把所有实时数据写入的进程都停掉再做数据的分析，所有数据读取和分析都是在数据写入的同时进行的。我们在用例设计上也会设计这类测试，在保证实时数据源进入的同时，考核它的读取和聚合的性能。会考察单机性能和集群性能，看能力的扩展，这些也是用户关注的内容。另外对是结果进行可信的比较，比如所有数据操作要选取相同时间段，选取多个不同长度时间段，还有选取多个相同时间段的操作求平均，以此来保证结果的公平性。

最后列举一下设计的测试用例的情况，我们这一版本设计了6个用例：

1、实时写入。在固定测点，固定时间间隔，固定持续写入时间的情况下，保证写入数据集相同，考察它的平均时延和最大、最小时延。

2、历史数据导入。这里设计两个数据集，一个是较少测点，另外一个是大量测点的数据集，两个数据集持续时长有些区别，这样能在写入时和分析当中都能体现出一些具体性能上的差别。

3、实时写入+实时读取。实时写入情况下考察实时读取的性能，这主要是为了一些监控类型的场景，实时数据收集过来后能不能及时反馈出当前最新的数据。

4、在实时写入的情况下对历史数据进行数据聚合的操作，看具体聚合的时延。

5、历史数据读取。纯粹的没有数据写入的时候做历史查询是什么样的情况。

6、数据压缩比。时序数据库特有的一个考察项就是压缩性能，在数据存入数据库之后所占用空间和原先数据集大小比例是多少，能有多大的压缩性能。

本次演讲最后，再次感谢一下时序数据库性能项目组的付出，我们的参与单位：百度云、麦杰科技、腾讯云、朗坤智慧、涛思数据、天数智芯、庚顿数据、网易。时序数据库下半年会开启性能测试项目，希望大家继续关注我们的工作。