涅槃：时序数据库的终局与重生

近年来，物联网、车联网、工业互联网和智慧城市快速发展，时序数据库成为数据架构技术栈的标配。据 DB-Engines 数据显示，自2017年以来，每年时序数据库在“过去24个月排名榜”上高居榜首，且远高于其他类型的数据库。这一方面说明业内对时序数据库有着迫切需求，另一方面说明了时序数据库的需求没有被很好地满足。

那么，这个高居榜首的时序数据库到底是什么？与时序数据有何区别？和关系数据库有何渊源？典型的时序数据库有哪些，该如何选择？本文将为你一一解答，同时介绍时序数据库的技术演进与未来方向，带你掌握时序数据库的重点知识与趋势机遇。

01 时序数据和时序数据库有何区别？

时序数据

时序数据是时间序列数据，其本质是带有时间戳的一系列结构化数据，通常是周期固定的数据，譬如数控机床每百毫秒采集的轴坐标、移动量、速度等数据；无人机每秒采集的位置、高度、风力、风向等数据；汽车每分钟采集的位置、车速、转速、温度等数据；智能冰箱每小时采集的温度、湿度、耗电量，用户访问网站的点击事件流等数据。

下面是一个示例：

时序数据具有以下特点：

• 周期性采集设备的时序数据，对插入性能和稳定性要求高，可能发生乱序情况或者丢失数据；更新和删除频次低
• 时序数据量大，对存储压缩比敏感，希望冷热数据分级存储
• 为了节省存储，通常会对高频时序数据降采样
• 设备属性信息重复度高，修改频次低
• 指标数据量大而变化小
• 查询需求多样：单设备最新值、单设备明细、单设备过滤聚集、多设备查询、多维查询、降采样、滑动窗口查询、设备状态演变图、特定模式识别、趋势预测、根因分析、阈值修正等。

时序数据库

时序数据库是为处理时序数据而设计的数据库，目的是实现时序数据的高效采集、存储、计算和应用。时序数据库的基本设计目标是高效插入、存储和查询。

一个企业级时序数据库产品远远不止这些，比如 InfluxDB 的下一代产品 iox 提出了13条设计目标，从中可以一窥一斑。

时序数据库广泛应用于物联网、车联网、工业互联网和智慧城市等场景，用以实现各种各样设备数据的采集、存储、计算和应用。

时序数据建模

从逻辑上讲，可以使用两种方式表示时序数据，一种称为窄表模式，一种是宽表模式。

窄表模式的核心概念是指标（metric），一行描述一个数据点，包括指标名、时间戳、指标值和标签值，如下所示。使用窄表模式的时序数据库有 InfluxDB、OpenTSDB、Graphite、Prometheus 等。

宽表模式的核心概念是设备（devices），每一行都包含时间戳、标签值和多个指标值。每个指标通过列名来标记，如下图所示。采用宽表模式的时序数据库有 Druid、TimescaleDB、MatrixDB 等。（MatrixDB 既支持窄表模式，也支持宽表模式）

宽表模式可以使用如上方式存储时序数据，也可以把标签数据拆成单独的表，使用一张标签表来存储设备的静态数据，流入品牌、产地等，使用一张指标表来存储时间序列数据。

窄表模式的优势是灵活，无需预先定义指标和标签；劣势是存储和查询效率低。宽表模式的优势是存储效率高，查询性能好；劣势是需要预先定义指标名和标签名，不够灵活。

窄表模式和宽表模式各有优劣。为了兼顾宽表模式存储和性能优势，以及窄表模式无需预先建模的灵活性，出现了半建模模式：对已知的标签和指标进行数据建模，而对未知的标签和指标使用类似JSON的方式存储。

02 时序数据库简史

早期的时序数据库与工业应用相关联，它们可以有效地存储来自 PLC、DCS 和 SCADA 的测量值，有时也称实时数据库，典型的产品如 OSISoft 的 PI Server。互联网的兴起催生了一批新的时序数据库，如 InfluxDB，主要用于运维监控和应用埋点分析等领域。随着物联网、车联网、工业互联网和智慧城市的发展，一批新型时序数据库涌现，以应对海量设备、大量指标等新场景，譬如 MatrixDB。

下图列出了常见的时序数据库及其发布时间。

目前，典型的时序数据库有以下几种：

1. PI System：这是美国傲视（OSISoft）公司开发的一套工业实时数据运营管理系统，广泛应用于流程性工业领域，如石油、石化、电力等。PS system 包括 Data Archive、Asset Framework 等不同的组件，其中Data Archive实现时序数据的收集、存储和管理，Asset Framework 通过把时序数据和关系数据相结合实现数据资产化，其内部自带了一个 SQL Server 关系数据库以存储和处理关系数据，通过关系数据赋予时序数据以意义。

2. Kdb+是一个 column-based relational 时序数据库，在证券交易系统中被广泛应用。第一版于1998年发布，2003年64位版本发布。

3. RRDTool （Round-Robin database tool）是一个开源的时序数据存储和可视化工具。RRDTool 以固定的时间间隔采集数据，使用 round-robin 方式存储，最新的数据会覆盖最老的数据。

4. Graphite 是一个实时监听、存储和显示时序数据的工具，于2008年以Apache 2.0协议开源。Graphite 中存储时间序列数据的数据库叫 Whisper，Whisper 设计类似 RRD，数据库大小固定，支持降采样。

5. OpenTSDB 基于 HBase，号称是第一款开源分布式时序数据库，第一版发布于2011年。OpenTSDB 基于 HBase 的存储模型对时序数据进行了优化，存储模型为 N-ary 存储，每行的格式为 Metrics、Tags、Timestamp：data1：data2:… 。为了提高存储效率，OpenTSDB 每一行默认存储一个小时的数据，并支持编码、压缩和并行查询执行。本质上 OpenTSDB 把 HBase 当做KV存储。

6. InfluxDB 是 InfluxData 开源的时序数据库，创立于2013年。InfluxDB 核心概念是时间线（Series)，由 measurement+tags 标记。它采用列存储，按照时间分块，支持块数据快速删除。InfluxDB 数据模型由数据点组成，每个数据点有四个部分：measurement，tag集（词典化的KV对)，field集（数据点的值，类型支持float、int、字符串和布尔值）和时间戳。底层存储使用 Time-Structured Merge Tree(TSM)，每个TSM文件含有压缩且排序的时序数据。

7. Druid 是一个开源分布式列存数据库，主要用于 BI、OLAP 应用中分析海量实时和历史数据。Druid 使用宽表，而不使用 join，正因如此，其完全扁平的 schema 能够大幅提升性能，又因为使用字典编码+压缩，磁盘空间开销也不大。Druid数据存储在 datasources 中，类似于关系数据库中的表。每个 datasource 根据时间分区，每个时间段的数据称为 chunk。在 chunk 内部，数据进一步分区成 segments。一个 segment 文件使用列式存储模型，包括三类字段：时间戳字段、维度字段、指标字段。这种结构支持快速聚集和多维查询。

8. Prometheus 是一个开源系统监控和告警工具箱，它使用时序数据库存储实时指标数据，使用 HTTP pull 模型以固定频率从数据源拉取数据、支持灵活的查询和实时告警。Prometheus 中，一个时间线由一个 metric 和一组KV标签定义。标签促成了 Prometheus 的多维数据模型：同一个指标的任意标签的组合标记了特定的维度实例。查询语言支持基于维度的过滤和聚集。

9. TimescaleDB 是一款基于 PostgreSQL 的开源关系型时序数据库，它通过 hack PostgreSQL 的存储引擎，使之能够较好的支持时序数据场景。

10. MatrixDB 是一款基于 PostgreSQL 的超融合时序数据库，它在关系数据库内部实现了全新的存储引擎，并专为时序数据场景中的高速数据插入和多样性查询进行了优化。MatrixDB 创立于2020年，是国内唯一通过工信部《分布式分析型数据库能力评测》和《时序数据库能力评测》的产品。

03 如何选择适合自己的时序数据库？

面对如此多的时序数据库产品，如何选择适合自己业务场景的一款，是架构师和开发者非常关注的问题。在选型时，我们可以考虑以下选型因素：

1. 匹配自身业务场景：根据设备规模、指标数量和采集频率，时序业务可以细分为多种场景。目前大多数时序数据库都能够适用于中小规模场景，而对于大规模场景如千万级设备、单设备数百指标、秒级采集，存在较大挑战。

2. 图形化工具：是否有简单易用的图形化工具，包括图形化访问工具和图形化监控运维管理工具。图形化工具可以大幅降低使用门槛，提高开发运维效率。

3. 生态和社区：数据库主要解决数据的存储和计算问题，要端到端解决业务还需要依赖生态的完善。此外数据库是复杂软件，特别是分布式数据库，开发运维都具有一定门槛，因此社区活跃度是一个重要的考虑因素。活跃的社区可以帮助我们在遇到问题时更快找到解决方法。

4. 写入性能，乱序写入：时序数据库95%以上的操作是数据写入，且要求性能平稳，因而写入性能是一个重要的考虑因素。此外是否支持乱序写入也是一个选型因素，因为时序数据时常发生数据出错而重传的情况。

5. 更新和删除：很多业务场景中，近期的数据时常伴随着乱序和错误数据，这时候需要对这些数据进行更新和删除操作。

6. 降采样：时序数据价值密度随着时间的流逝而衰减，因此需要经常对采集的指标数据进行降采样处理，譬如原始数据采集频率是10秒，同时也会对该数据降采样为1小时一个点，甚至一天一个点。这种业务场景下需要考虑数据库是否自动支持降采样。

7. 压缩比：当设备数据量多、指标个数多或者采集频率高时，时序数据量会变得非常大，对存储空间要求很高，常见的方法是只保留近期的数据而删除历史数据；但业务希望数据量尽量大，对尽可能多的数据进行分析和模型训练，因此压缩比就成了一个重要指标。通常时序数据库支持列式编码压缩和块压缩。

8. 查询性能：时序场景查询非常多样化，既有简单的指标类查询，也有分析型查询；既有单设备/多设备最新值、聚集值类查询，也有多维查询；既有插值，也有阈值计算、模式识别等查询。根据业务场景，对数据库进行实际评测是一个很好的方法。此外使用比较常见的基准测试，譬如tsbs基准测试也可以对数据库的查询能力进行综合验证。

9. 冷热分级存储：时序数据价值密度随着时间推移而衰减，因此对不同时间段的数据采用不同价格的存储介质和存储服务是一个常见的需求。冷热分级存储可以很好地解决这个问题，通常配合分区使用。

10. 分区支持：时序场景通常会按照时间属性进行分区，有时候还要根据其他属性进行二级分区，以更好的支持插入和查询。

11. 持续聚集：时序场景经常使用时间窗口类查询，并且频繁获取该时间窗口内数据点的聚集值，譬如过去10秒钟CPU的最大利用率。传统的方法是每隔10秒钟发送一个查询请求给数据库，数据库收到查询后，计算过去10秒钟CPU指标的最大值，这种方法可行，但是开销比较大，且延迟高。持续聚集可以持续的计算10秒钟窗口的指标聚集值，这样当收到相应查询时可以直接返回结果。搭配订阅机制可以进一步避免轮询查询，直接把结果发送给感兴趣的订阅者。

12. 时序函数：时序场景下有很多特定的函数，譬如 first、last、gapfill、方差、标准差、ARIMA 等，是否原生支持这些常用函数也是选型考虑的一个因素。

13. 云边一体：由于时序数据量大，频次高，因而通常使用边缘计算架构，在边缘侧部署单节点时序数据库或者数据库小集群，同时将边缘侧的数据经过初步处理后发送给云端/数据中心的大数据库集群，此时产品能否支持云边一体就需要重点考虑。

14. 安全机制：安全机制是选型时经常忽略的一个因素，因为一开始主要是跑通业务，所以对安全性关注度较低。然而很多时序场景，譬如能源、电力、工业互联网等对安全非常重视。是否有完善的安全控制，包括认证、访问控制、加密和审计等是判断一个时序数据库是否安全的重要考虑因素。

15. 内嵌脚本能力：除了标准SQL，应用开发人员经常对数据进行更复杂的处理，一种做法是使用 JDBC 把数据读取到内存中，使用编程语言提供的数据处理函数对数据进行处理，这种方法比较适合数据量比较小的场景。如果数据量大，把数据读到内存中进行变形转化处理就会效率低下。因而能否在数据库内使用常见编程语言（Python、R等）对数据进行处理就是一个重要考量因素。

16. 运维管理：这项考量因素包括安装部署、监控、告警、故障恢复、备份恢复、扩容和升级等。

04 时序数据库和关系型数据库的纠葛？

当你对时序数据库有一定了解后，你可能会疑惑，虽然时序数据是非常好的结构化数据，但是关系数据库自上世纪80年代开始就支持时间戳数据类型，那么为什么不使用关系数据库处理时序数据，而要开发专门的时序数据库呢？

这要从关系数据库的存储引擎说起，传统关系数据库使用行存储引擎存储数据，通过B+树来提升查询的性能。B+树是一种为读而优化的数据结构，数据写入时会引起B+树分页，而分页会造成随机磁盘IO，随机磁盘IO会大幅降低数据写入的性能。此外B+树的压缩比也较低。

正因为关系数据库的这些特性，使得它不适合做时序数据库。时序数据库中绝大多数操作是写入操作，所以希望为数据写入而优化；时序数据量比较大，所以需要达到较好的压缩比，这都是传统关系数据库所不具备的条件。

时序数据库大多不使用B+树，而是使用 LSM（Log Structured Merge）树或其变种。LSM树是为写而优化的数据结构，写性能出色，故而很多时序数据库选择 LSM 或者 LSM 的变种作为其核心存储引擎，比如 InfluxDB、OpenTSDB（OpenTSDB 基于 HBase，而 HBase 基于 LSM树）等。

那么LSM树就能满足时序数据库所有的特性需求吗？也不尽然。LSM树虽然写性能优异，但是不能很好地支持读操作。为此时序数据库引入不同的机制来提升查询性能，譬如 InfluxDB 使用B树索引、倒排索引和 Bloomfilter 等技术提升查询性能，这样一方面提升了读操作的查询性能，另一方面写数据时需要维护这些不同类型的索引，也增加了写操作的开销。可见时序数据库需要取得读操作和写操作之间的平衡，而不是单纯的追求其中之一。

最近几年有些产品开始挑战关系数据库不适合处理时序数据的假设，并基于行存和B+树开发出性能出色的关系型时序数据库，具有代表性的产品是 TimescaleDB。TimescaleDB 基于时序数据天然具有时间戳属性的特点，把时序数据表按照时间分区，当前分区使用行存和B+树，老分区使用基于行存的类列式存储引擎（把1000行合并成一行，达到类似列存的效果）。那么 TimescaleDB 的写性能如何呢？网上一些评测发现其写性能优于专用时序数据库 InfluxDB，这是为什么呢？B+树不是为读而优化，写性能不如LSM树吗？B+树理论上确实会造成磁盘随机IO，但是数据库工程实现时都会使用WAL日志+缓冲区的方式来尽可能避免随机IO：WAL总是顺序读写，B+树的页面发生修改时不会直接写入磁盘，而是先写WAL日志，然后更新内存缓冲区，只有内存缓冲区满了之后才会刷新入磁盘，这样就很大程度上把随机磁盘IO优化为顺序磁盘IO了。而LSM树为了提升写性能引入了各种各样的索引，一定程度上增加了写开销。

时序数据多为指标数据，通常是一些列数字串。为了让这些数字串变成有价值的信息，通常需要引入时序数据的上下文信息，这些信息大多是关系数据。所以时序场景通常需要关系数据库和时序数据库配合以赋予数据意义，发挥数据的价值。关系型时序数据库在关系数据库内实现对时序数据的支持，一个数据库代替关系数据库+时序数据库联合才能解决的问题。可以大幅简化技术栈，提升开发运维效率。

TimescaleDB 采用一种 hack 的方式在关系数据库内实现了时序数据库，并且性能优秀。沿着这一思路，开始出现一种新的数据库品类：超融合时序数据库。超融合时序数据库在关系数据库内部实现多种存储引擎，以支撑不同的数据类型和业务场景，譬如关系存储引擎存储结构化数据，时序存储引擎存储时序数据，GIS存储引擎存储地理信息数据，并通过与优化器和执行器的配合实现 HTAP 以及流数据处理。这方面的代表性产品是 MatrixDB，MatrixDB 是一款关系型数据库，内建了关系存储引擎、列式存储引擎和时序存储引擎，可以同时处理结构化数据和 IoT/IIoT 时序数据，且性能优异。

当关系数据库能够很好地支持时序数据时，专用时序数据库的意义何在？这是一个值得思考的问题。时序数据库的终局或许是没有时序数据库，这不是说时序数据库没有必要，而是时序数据库作为一个数据库细分品类或许没有必要。这既是时序数据库的终结，也是时序数据库的重生。

正如多年前很火的“NoSQL”一词现在很少提及，但是某些流行的 NoSQL 产品，譬如 Elasticsearch、MongoDB 仍然广受欢迎。只不过由于大多数 NoSQL 产品开始支持关系数据库的特性，譬如 ACID、SQL 等，使得“NoSQL”一词作为一个数据库类别已经意义不大了。

05 时序数据库未来的方向

不管专用时序数据库的未来如何，支持时序的数据库（姑且继续称为时序数据库）仍将继续发展，且随着物联网、车联网、工业互联网和智慧城市的发展还会变得越来越重要。其中有几个方向值得我们关注。

1、超融合时序数据库

融合是未来几年数据库发展的主旋律之一，数据库的边界正在变得越来越模糊，如生物界从简单到复杂的进化一样，数据库将会出现组织更为复杂、功能更为强大但使用更简单的“新物种”：超融合数据库。如下图所示，数据库和数据处理平台自诞生到现在大概演进了50年左右，可以分为四个阶段：

• 上世纪八、九十年代：关系数据库是主流，应用通过SQL和关系数据库交互，业务逻辑在应用中实现，数据处理逻辑由关系数据库实现；

• 2000年到2010年左右：随着互联网的快速发展，数据量每年以超快速度增长，而数据库技术迭代的速度没有赶上数据的增速。为了解决应用处理海量数据的性能问题，各种专用的数据库应用而生。这些专用时序数据库以出色的性能和扩展性解决了当时业务的痛点问题，但是也带来了数据孤岛问题，以及数据处理逻辑和业务逻辑耦合的问题。

• 2010年到2020年左右：为了解决数据孤岛问题和数据处理逻辑/业务处理逻辑紧耦合的问题，类似 Presto 这样的查询引擎出现，进而出现了数据中台。然而由于 Presto 这样的查询引擎自身不管理数据，所以查询性能比较差，且不支持诸如 ACID 等特性。此外技术栈复杂，开发运维效率低。

• 2020年到现在：上一个阶段的方案很难成功，因为若要成功，基本需要把橘黄色的部分发展成一个功能强大数据库。故而与其在多个独立数据库之上封装一个查询引擎，倒不如把存储引擎实现到关系数据库内部，通过可插拔存储引擎，在一个关系数据库中支持多种存储引擎，再结合计算引擎，可以实现在一个数据库中支持各种数据类型和各种业务场景，这就是超融合数据库。

在超融合数据库趋势之下，超融合时序数据库是时序数据库的一个重要发展方向。由于超融合时序数据库实现难度比通用的超融合数据库低，所以超融合时序数据库首先出现并实现了产品化。

2、云原生时序数据库

云原生数据库是商业模式的一个重要创新，对数据库技术正在产生深远影响。国外云原生数据库如 Snowflake 取得了巨大的商业成功，对数据库技术的推动也起到了重要作用。

在这样的大形势下，如何实现云原生的时序数据库是一个重要的研究方向。云原生时序数据库和目前诸如 Snowflake 这样的云原生数据仓库有诸多不同，譬如数据仓库主要是批量加载数据和 OLAP 类查询，而时序数据库需要支持频繁高吞吐数据写入、乱序数据写入、更新和删除、高并发时序查询、持续聚集查询等。设计和实现云原生时序数据库时需要考虑这些时序场景的特定问题。

3、智能数据库

数据库运维管理是一个非常具有挑战性的工作，随着数据库集群变大，软硬件故障将成为常态，这会进一步加大分布式数据库运维的难度。在这种情况下，智能运维正在成为热点。通过收集数据库运行过程中的各种指标数据，可以使用时序数据库对时序数据库本身进行分析，提高数据库的智能化程度，降低运维的复杂度。

06 总结

随着物联网、车联网和工业互联网的快速发展，时序数据库再次走上时代的风头浪尖，受到业内极大的关注。专用时序数据库和超融合（关系型）时序数据库两种技术路线孰优孰劣也成为当下业内人士关注的一个话题，时序数据库未来发展方向是什么更是架构选型的一个重要考虑因素。

本文介绍了时序数据、时序数据库和时序数据建模，回顾了时序数据库的发展简史，详细阐述了时序数据库选型考虑因素，然后在分析时序数据库两种技术路线的基础上，指出时序数据库的终局或许是没有时序数据库。当然这不是说时序数据库没有必要，而是说专用时序数据库或许没有必要，未来超融合时序数据库将成为一个重要发展趋势。这既是时序数据库的终结，也是时序数据库的重生。