1956亿行时序数据如何高效存储？从压缩算法、批量写入到超表优化

前言

在工业互联网、智能制造和能源监测等场景中，时序数据已经成为最常见的数据类型之一。

比如，一套智能电表系统需要持续采集电压、电流、功率等指标；工业设备监控平台需要记录设备状态、温度、振动频率；生产管理系统则需要长期保存各类运行参数。

这些数据有一个共同特点：采集频率稳定、数据量持续增长，并且历史数据通常需要保存较长时间。

当监测点从几万个增加到数百万个，数据规模达到百亿甚至千亿行时，数据库面临的问题也会逐渐发生变化：

• 海量历史数据占用大量磁盘空间，存储成本持续增加。
• 系统迁移或数据回灌时，批量写入效率容易成为瓶颈。
• 数据量持续增长后，分区管理和历史曲线查询的开销不断增加。

针对这些问题，可以从存储压缩、历史数据写入和数据组织结构三个方面进行优化。

一、时序数据为什么需要专门的压缩策略？

1. 时序数据具有较强的规律性

普通业务数据库的数据通常包含大量不同类型的信息，而时序数据库中的记录往往具有相似的数据结构。

以设备温度监测为例：

从这个简单示例可以发现：

采集时间通常按照固定间隔递增，相邻采样点的数值变化幅度往往较小，同一设备的标识、状态或标签信息可能重复出现。
如果直接使用常规方式保存每一条记录，就可能产生大量重复数据。

因此，时序数据库通常会针对时间戳、数值字段和重复属性采用不同的压缩方式。

2. 常见的时序压缩技术

金仓时序数据库在存储优化中应用了多种压缩技术，包括 Delta-of-Delta、Gorilla XOR、字典编码及列式存储优化。

（1）Delta-of-Delta：针对时间戳的差值压缩

工业采集系统通常具有固定采样周期，例如每秒生成一条数据。

假设时间戳依次为：

1000, 2000, 3000, 4000, 5000

相邻时间戳的差值均为1000。

如果进一步计算差值之间的差值，就会得到：

0, 0, 0

这正是 Delta-of-Delta 的核心思路。

通过存储时间间隔的变化，而非完整时间戳，可以减少规律性时间序列需要占用的存储空间。

（2）Gorilla XOR：针对浮点数的压缩

工业监测数据中经常包含温度、电压、压力等浮点数。

这些指标在相邻采样时刻通常不会发生剧烈变化，因此连续数值在二进制表示上可能具有较多相同位。

Gorilla XOR 压缩利用相邻浮点数之间的异或结果，结合前导零和尾随零等信息进行编码，以减少需要保存的有效位数。

当采样数值变化较小时，这类压缩方式通常能获得较好的效果。

（3）字典编码与列式存储

除了时间戳和浮点数，设备类型、状态标识、区域编号等字段也可能出现大量重复值。

字典编码可以将重复字符串映射成更紧凑的编码值，减少重复内容的存储开销。

列式存储则将相同类型的数据集中组织，为同类字段的压缩提供了更有利的条件。

需要注意的是，具体压缩效果取决于数据类型、采样规律、字段基数和实际数据分布，并非所有场景都能获得相同的压缩率。

3. 1956亿行数据的压缩测试

在某省智能电表场景的测试中，金仓时序数据库使用了以下数据规模：

从测试结果来看，45:1 的压缩比意味着，在对应的统计口径下，压缩后的数据体积约为压缩前的 1/45。
对于需要保存多年历史数据的工业系统，这种压缩能力具有较大的实际意义。

因为存储空间的减少，不仅影响磁盘采购成本，也可能进一步降低数据备份、归档和迁移过程中的资源开销。

二、面对百亿行历史数据，如何提高批量写入效率？

1. 历史数据导入与实时写入有所不同

在工业系统中，除了实时采集之外，还经常存在大规模历史数据导入需求。

例如：

• 将原有监控系统中的多年数据迁移到新平台。
• 将分散在多个数据库中的历史数据统一汇总。
• 为设备故障分析、预测性维护等应用建立历史数据集。
• 在系统升级后，对已有采集数据进行批量回灌。

这类任务通常涉及大量连续历史记录，写入数据规模可能达到数十亿甚至上百亿行。

如果仍然采用效率较低的逐条写入方式，就容易因为频繁的交互、事务提交及存储维护产生额外开销。
因此，历史数据导入更适合采用批量加载策略。

2. 批量写入优化主要解决哪些问题？

在大规模历史数据导入过程中，通常需要关注三个方面。

第一，降低单条数据写入的固定开销。

通过批量组织数据，减少频繁提交和交互带来的成本，提高单位时间内处理的数据量。

第二，减少数据组织过程中的额外开销。

时序数据具有明显的时间属性，合理组织写入批次及数据分布，有助于降低数据处理和存储管理负担。

第三，充分利用分布式部署能力。

当数据库采用分布式架构时，可以根据具体的数据分布策略和系统能力，提高并行处理效率。

金仓时序数据库针对历史数据加载场景进行了写入路径优化，以支持更大规模的批量插入任务。

3. 1956亿行数据写入性能测试

在分布式部署环境下，金仓时序数据库完成了一组大规模历史数据加载测试。

根据数据规模与总耗时，可以计算平均写入速度：

平均写入速度 = 总写入行数 / 总耗时 = 195600000000 / (701 × 60) ≈ 465万行/秒

对于需要完成大规模历史数据迁移的业务而言，写入吞吐量直接影响数据准备时间。

例如，在其他条件一致的情况下，更高的批量导入效率有助于缩短历史数据迁移窗口，让后续的数据分析、查询和业务验证更早开始。

不过，批量写入性能还与硬件资源、集群节点数量、数据字段、索引配置和写入方式有关。
因此，在实际技术选型时，除了参考测试吞吐量，还需要结合自身业务环境进行验证。

三、为什么时序超表比普通分区表更适合某些时序场景？

1. 普通分区表面临的问题

当数据库中的记录规模持续扩大时，通常需要通过分区来管理数据。
例如，可以按照月份划分数据：

设备监测数据表 ├── 2026_01 ├── 2026_02 ├── 2026_03 ├── 2026_04 └── ...

这种方式能够在一定程度上改善大表管理问题。

但在设备数量多、采样频率高、持续写入时间长的场景中，仍然需要考虑分区规划、数据定位和历史数据管理等问题。

特别是当业务经常根据设备编号和时间范围查询历史曲线时，数据库的数据组织方式会直接影响查询执行效率。

2. 时序超表的优化思路

时序超表是一种面向时间序列场景设计的数据组织机制。

它将时序数据管理中的时间维度、数据划分和查询定位等需求结合起来，使数据库能够按照时序特征组织大量记录。

对于开发人员而言，可以通过逻辑上的时序表管理数据，而底层的数据划分与存储组织则由数据库相应机制处理。

这种方式适合持续写入并频繁查询特定时间范围的监测数据。

当然，时序超表的实际性能收益仍然取决于具体数据库实现、数据分布和查询负载。

3. 时序超表与普通分区表的测试对比

在相同数据规模和表结构的测试条件下，金仓时序数据库对时序超表和普通分区表进行了性能对比。

从结果来看，时序超表在实时插入和曲线查询中均取得了更短的执行时间。

其中，曲线查询的差异尤其明显。

按照测试数据计算：

查询性能倍数 = 普通分区表耗时 / 时序超表耗时 = 4834 / 253 ≈ 19.1

也就是说，在该测试环境和查询条件下，时序超表完成曲线查询所需的时间约为普通分区表的 1/19.1。

这一结果说明，在特定时序查询负载下，采用更贴合时间序列特征的数据组织方式，可能比单纯扩大硬件资源更有效。

不过，19.1倍属于该测试场景的结果，不能直接推广到所有查询类型。

四、工业时序数据库选型，需要重点关注哪些指标？

结合前面的技术分析，可以将工业时序数据库的选型重点归纳为以下几个方面。

需要特别注意的是，压缩比高并不代表所有查询都会更快，批量写入性能优秀也不意味着实时写入一定具有相同优势。

不同业务应当根据实际负载进行验证。

例如，智能电表系统可能更加关注海量数据的存储成本，而设备实时监控系统则可能更关注持续写入能力和最近时间窗口的查询延迟。

对于需要长期保存历史数据并开展趋势分析的系统，存储效率和历史曲线查询性能往往需要同时考虑。

因此，数据库选型最好使用真实业务数据开展测试，尽量保持硬件配置、数据模型、写入并发度与查询条件一致。

五、总结

随着工业系统中监测设备数量持续增加，时序数据库需要处理的数据规模也在不断扩大。

当数据量达到百亿甚至千亿行时，数据库的性能优化已经不能只关注单一的写入吞吐量。

从金仓时序数据库的相关测试结果来看，可以得到三个值得关注的方向：

一是通过针对性的压缩编码，减少规律性时序数据占用的存储空间。Delta-of-Delta、Gorilla XOR 和字典编码等技术能够利用时间戳、浮点数及重复字段的特征，提高数据压缩效率。

二是优化大规模历史数据加载能力。对于系统迁移、数据回灌等任务，批量写入吞吐量会直接影响数据准备周期。

三是针对时序数据特点设计更合适的数据组织方式。在典型的设备历史曲线查询场景中，时序超表能够发挥面向时间序列的数据组织优势。

从工程实践角度看，时序数据库的价值最终仍然取决于实际业务负载、硬件环境和长期运行成本。

对于工业互联网、能源采集和智能制造等系统，压缩效率、批量写入性能与时序查询能力值得放在同一个测试体系中综合评估。