时序数据库 Apache IoTDB 单元与多元时间序列写入与查询性能对比——田原

本次分享来自社区贡献者田原 。

在物联网广泛普及的同时，在工业技术领域对海量数据进行高效管理的需求日益普遍

1.时序数据库分类

当前主流的时序数据库存储引擎大多采用单一的时间序列模型（单变量或多变量），我们可以根据Time series database engine是否属于单变量时间序列存储引擎还是多变量时间序列存储引擎来进行分类划分

单元时间序列存储引擎

该存储引擎将每个时间序列独立地进行存储操作，在完成这些操作时会对应生成两列数据分别对应时间戳和值字段这两者之间是一一对应的映射关系这种设计特别适用于各个传感器各自独立采集数据的情形在这种架构下每个传感器获取的数据都会包含各自独有的时间戳信息

以基于已有键值数据库为基础构建的时序数据库大多归属于此类别；此外还有那些具有原生时序功能的数据存储引擎同样归属于此类别

在早期版本中使用Apache IoTDB时，请注意其受限于单序列结构，并且无法高效地存储与查询多维时间序列数据

多元时间序列存储引擎

该存储引擎采用了多对一的数据结构设计，在时间序列共享存储中设置了单一的时间戳列用于统一记录时间节点信息。同时为每个具体的时间序列单独设置了对应的值列用于存储采集数据的具体数值信息。每一组时间戳对应的值列可以支持多个数据点的同步更新以满足多传感器协同采集的需求。这种架构设计特别适用于设备级数据采集场景例如在工业自动化生产环境中能够实现对单个设备下多个传感器实时数据的高效整合与管理

大多数基于现有关系型数据库构建的时序数据库均属于此类别。具体而言，在一个设备下将每个设备下的所有序列统一建模为一个表格结构，并且仅包含单一的时间列字段即可实现对多条时间线的支持效果。其中典型代表如TimescaleDB等产品能够满足这一需求。少数具有自主知识产权的时间序列处理能力的原生时序数据库则采用了多元时间序列模型作为其核心架构，并以此为基础开发出高效的存储引擎技术。例如TDengine等产品便很好地体现了这种设计理念与技术实现方案。

Heracles 是一款以 Prometheus 为核心的多元时间序列数据库系统 currently处于概念阶段,尚未融入Prometheus主代码库.该系统在减少时间戳冗余存储的同时,也面临查询效率的瓶颈.论文中指出,在写入流程的关键路径上,Prometheus会对每个时间序列进行单独加锁操作,这一机制在处理多元时间序列数据量较大的情况下,可能导致显著的性能开销.

2.Apache IoTDB 双存储引擎

Apache IoTDB 自0.13版起首次提出一种时序数据库双存储引擎方案。该方案包含两种高效存储引擎：一种是能够处理非共享的时间戳数据；另一种则是能够处理多变量的时间序列数据。

双存储引擎定义

就整个数据库管理系统而言，在其整体架构中存在一种相互连接的关系：一方面由存储引擎向查询引擎提供标准化的数据访问接口；另一方面则遵循文件格式规范下的数据组织方式，并向下连接到存储介质；基于数据页或其它单位的粒度处理；通过与存储介质交互所使用的特定接口来执行读写操作。

单元与多元时间序列业务场景分别对时序数据库的存储引擎提出了各自的要求。因此，在Apache IoTDB中我们特意支持了两个存储引擎来分别满足这两种不同的业务需求。下图展示了Apache IoTDB双存储引擎的整体架构示意图，在这一架构中双存储引擎的主要区别在于设备下的序列是否共享时间戳这一特性。传统的不共享时间戳存储引擎则更适合于单元时间序列，在这种情况下查询结果集格式、内存表以及排序方式等方面均表现良好。而新增的共享时间戳存储引擎则对多元时间序列进行了相应的优化，在持久化编码方式上也更为高效。尽管如此但由于是否共享时间戳列的不同这两个存储引擎在与查询引擎交互的过程中仍会带来一定的影响但在元数据管理器以及缓存管理器上两者仍实现了良好的共用，并且在底层文件结构上也采用了统一的设计实现了在一个TsFile中能够同时混合并支持单元时间和多元时间序列的数据处理功能

双存储引擎数据模型设计

实现两种存储引擎在同一个数据库中的集成首先要解决的是新旧数据模型之间的兼容性问题。同时需要探索一种机制以便用户能够指定使用何种存储引擎，并且确保多元时间序列的数据结构与原有数据库系统保持一致

可以在存储组级别上设定存储引擎的具体划分，在这种情况下，则会使得该存储组内的所有时序要么全为多元时序、要么全为单元时序。这会限制用户的使用灵活性。由于在同一设备下的多元时序通常具有相同的时戳基线，在这种情况下，则需要考虑该设备下的所有时间序列是否共享同一列的时间戳基准值这一问题。因此，在这种情况下，则可以选择将存储引擎的划分粒度定位于具体设备层面（如图所示），从而能够在同一个存储组中支持同时存在多种类型的时间序列数据。在元数据树结构中，则可以通过设备级别的布尔型开关变量来标识该特定设备下的时间序列是否具有共享的时间戳列属性（即该设备下的所有时间序列是否属于多元时序）。

在处理多元序列时，我们引入了ALIGNED标志词用于标记某个设备下的时间序列属于多元时间序列，并且这些序列共享同一时间段戳列。如图所示，在元数据结构中生成该设备节点时，默认设置了latitude与longitude数据字段组成一个多元数据集。为此设备建立了包含纬度和经度的数据集。这些语法在元数据树上创建出的设备节点都具有共享时间戳属性

3.性能对比

Performance Comparison

写入性能与磁盘占用对比

为了评估共享时间戳存储引擎在处理不同数量分量时的表现效果以及节省空间的能力，在实验中设置了多个场景进行测试。具体来说，在实验中我们考察了包含一个到十个不同数量（即一分为十）的时间序列情况下的性能表现。其中所有的时间序列数据类型都被设定为long类型，并且其取值与对应的时间戳数值相同。实验设置要求相邻的时间戳之间间隔必须达到每毫秒一次的要求，并从统一的时间起点值（即1646134492）开始计时。此外，在整个实验过程中我们采用了均匀采样策略：每个数据项记录了共计一千万个数据点，并且对于每一个时间节点而言所有参与的时间序列都必须存在对应的数值记录没有任何缺失情况出现

如图所示，在分量数量超过一个的情况下，在整体上来看，多元时间序列的平均持久化速度相较于单元时间序列高约60%。

在存储空间使用方面（如图所示），当仅有一个分量时（即单元时间序列），由于多元时间序列会存储更多的统计信息以及空值信息（包括时间和数值两部分），因此在单一分支情况下单元时间序列表现得比多元的时间序列节省约1%的空间资源。然而当分支数目超过一个（具体来说是2个及以上的分支情况）时，则会出现显著的空间浪费现象。例如，在具体实验中我们设置了三个不同分支数目分别为10个、30个以及100个的时间点集（即元数据）。在这种情况下由于实验中所有值和时间字段采用了相同的编码方法因此对于每个元数据而言它们只会记录一次完整的元数据行从而使得总体所需的空间规模仅为原始单一分支情况下的59.7%左右（约相当于减少了48.4%的空间浪费）。

查询性能对比

时序数据库涵盖的查询场景非常广泛，在实际应用中主要包含两大类：第一类是基于原始数据的查询操作，该类型会直接返回原始时间点信息；根据查询条件是否带有过滤值的不同需求，进一步划分为无值过滤条件下的纯时间点信息检索和带值过滤条件下的时间点信息筛选两种子类型；第二类是降采样相关的聚合查询操作，在该类型中系统会对指定时间段内的全部或部分原始数据进行特定算法处理后输出结果。在本研究中我们设定多元时间序列分量数为30，并在上述三种不同类型的查询操作下对比分析多元时间序列与单元时间序列在性能指标上的差异性表现。

不带值过滤的原始数据查询

未进行值过滤的原始数据查询时长与其查询的数据维度呈相关性变化。当数据维度增加时，则需要从磁盘读取的数据总量也随之提升。对于单一时间序列而言，则需要对多个时间序列执行时间戳对齐操作以确保同步性。在每次处理包含30个分量的所有维度时，默认SQL语句类似于"select * from root.**"这样的模式。随着参与查询的数据维度不断增加，在不带值过滤的情况下实现全分量原始数据查询时序性能的优势将得到显著提升：因为在这种情况下可减少磁盘读取的时间列数量，并减少基于时间戳的时间列对齐操作次数。如图所示，在不带值过滤的情况下进行全分量原始数据查询场景下，多元时间序列比单一时间序列平均快出62.2%

带值过滤的原始数据查询

带值过滤的情况下进行的数据查询效率与其选择率相关。其中的选择率指标表示满足特定查询过滤条件的结果数量占总数据量的比例。针对90%、50%和10%这三种不同的选择率设置，在包含30个分量的数据集中，并根据空值比例分别为0%、10%以及50%的不同情况进行实验研究。

当每次查询涉及30个分量时（如图所示），在90%的选择率下，“多元时间序列”的查询速度较“单元时间序列”加快出17.4倍；在50%的选择率下，“多元时间序列”的速度较后者加快15.1倍；而在10%的选择率下，“多元时间序列”的速度较后者加快2倍（约）。当每次查询的分量数量增加至30个时，在不同选择率及空值比例组合条件下，“多元时间序列”的平均查询性能较“单元时间序列”的提升幅度约为\frac{3}{4}倍左右。与仅包含15个分量的查询相比，在90%和50%选择率及对应的空值比例为\frac{1}{1}和\frac{2}{5}的情况下，“多元时间序列”的全分量查询性能提升幅度约为\frac{9}{8}倍。

降采样查询

降采样是一种基于低于原始数据采集频率的时间间隔执行特定操作的技术手段，在整体查询模式中具有独特地位。举个例子，在IoTDB系统中若希望将每秒的数据按每分钟展示，则需要应用降采样技术。该系统通过GROUP BY语句实现时间段内的数据汇总，并支持根据设定的时间间隔以及可自定义的滑动步长（默认值与时间间隔一致）划分结果区间，默认按时间升序排列结果集。本次实验中我们设定窗口大小为5秒，并采用计数函数作为聚合算子，在SQL语句中体现为类似以下结构："select count(*) from root.** group by([1646134492000, 1646144492001), 5秒)”。

根据下图所示，在查询中涉及全部30个分量时，元数据时间序列相比单数据时间序列提升了幅度达15%；当在查询中涉及15个分量时，则提升幅度达10.9%；而仅当查询单一维度数据时，则元数据时间序列的表现会落后约6%。

4.总结

改写说明

在单一维度的场景下，将序列表示为单元时间序列。采用非共享时间戳存储引擎相比共享时间戳存储引擎，在读取持久化速度上具有显著优势，并且能够使得相应的磁盘占用量有所减少。同时，在查询性能方面也略胜一筹。

在数据维度超过一个且缺失值占比较小时，在采用多元时间序列建模方法时，在读取性能上能提升约1.6倍，并在存储空间消耗方面也将减少约一半

采用多元时间序列模型对序列进行建模，在共享时间戳的数据存储引擎中完成数据记录。针对不同类型的查询需求，在多分量参与的情况下（即参与查询的分量数量超过一个），其在多分量查询中的性能优势明显；即便仅进行单分量查询时，在性能上也仅略逊于单元时间序列，在执行速度上大概率慢出10%左右。

关于我们

Apache IoTDB——海量时序数据管理的核心产品。它是一款经过深度优化的开源时序数据库，在性能和资源利用率方面表现卓越。该系统通过自研的实时存储架构结合创新的数据建模技术与高效的流量传输机制，在提升吞吐量的同时实现了毫秒级响应时间。其核心技术团队依托清华大学的支持实现了自主可控的发展战略，并已在多个领域取得显著成效：包括但不限于国家电网等多家大型企业和科研机构的应用场景中得到了广泛应用

作为全球范围内开展的一个开源项目，在经历了长时间的发展后