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

【CSDN 编者按】当关系型数据库能够很好地支持时序数据时，专用时序数据库的意义何在？是否会像NoSQL一样，失去作为一个数据库类别的意义？《新程序员002》邀请到了北京四维纵横数据有限公司创始人、Greenplum中国开源社区创始人姚延栋为大家解读时序数据库的终局与重生。

作者 | 姚延栋? ? ? ?责编 | 张红月

出品 |《新程序员》编辑部

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

图1 时序数据库“过去24个月排名榜”

那么，这个高居榜首的时序数据库到底是什么？与时序数据有何区别？关系型数据库也支持时间戳类型，为什么还需要时序数据库？面对众多特性各异的时序数据库，又该如何选型？本文将为你一一解答，同时介绍时序数据库的技术演进与未来方向，带你掌握时序数据库的重点知识与趋势机遇。

姚延栋 北京四维纵横数据有限公司创始人、Greenplum中国开源社区创始人、PostgreSQL中文社区常委、壹零贰肆数字基金会（非营利组织）联合发起人，著有《Greenplum：从大数据战略到实现》。

时序数据和时序数据库

时序数据

时序数据是时间序列数据，其本质是带有时间戳的一系列结构化数据，通常是周期固定的数据，譬如无人机每秒采集的位置、高度、风力、风向等数据；汽车每分钟采集的位置、车速、转速、温度等数据；智能冰箱每小时采集的温度、湿度、耗电量等数据（见图2）

图2 智能冰箱每小时采集的数据

因此，时序数据具有以下特点：

• 周期性采集设备的时序数据，对插入性能和稳定性要求高，可能发生乱序或者丢失数据的情况；更新和删除频次低；

• 时序数据量大，对存储压缩比敏感，希望冷热数据分级存储；

• 为了节省存储，通常会对高频时序数据降采样；

• 设备属性信息重复度高，修改频次低；

• 指标数据量大而变化小；

• 查询需求多样，如单设备最新值、单设备明细、单设备过滤聚集、多设备查询、多维查询、降采样、滑动窗口查询、设备状态演变图、特定模式识别、趋势预测、根因分析、阈值修正等。

时序数据库

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

图3 时序数据库的基本设计目标

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

图4 iox的13条设计目标（来源：InfluxDB）

正因时序数据库这些特性，它被广泛应用于物联网、车联网、工业互联网和智慧城市等场景，实现各类设备数据的采集、存储、计算和应用。

时序数据库和关系型数据库

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

这要从关系型数据库的存储引擎说起。传统关系型数据库使用行存储引擎存储数据，通过B+树来提升查询的性能。B+树是一种为读而优化的数据结构，数据写入时会引起B+树分页，而分页会造成“随机磁盘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树为了提升写性能引入了各种各样的索引，在一定程度上增加了写开销。

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

本文节选自《新程序员002》扫描立即订阅

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

正因为关系型数据库在一些业务场景中已经不能满足处理时序数据的需求，这就要求架构师和开发者选择一款适用于自己业务场景的时序数据库。而市面上的时序

数据库特性各异，该如何选择？在选型时，我们可以考虑以下因素：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

时序数据库未来将如何发展？

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

超融合时序数据库

融合是未来几年数据库发展的主旋律之一，数据库的边界正在变得越来越模糊，如同生物界从简单到复杂的进化，数据库将会出现组织更为复杂、功能更为强大但使用更简单的“新物种”：超融合数据库。

如图5所示，数据库和数据处理平台自诞生至今演进了五十年左右，可以分为四个阶段：

• 20世纪八九十年代。关系型数据库是主流，应用通过SQL与关系型数据库交互，业务逻辑在应用中实现，数据处理逻辑由关系型数据库实现。

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

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

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

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

云原生时序数据库

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

智能数据库

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

总结

总而言之，随着物联网、车联网和工业互联网的快速发展，时序数据库将再次走上时代的风口浪尖。但是，值得思考的一点是，当关系型数据库能够很好地支持时序数据时，专用时序数据库的意义何在？时序数据库的终局或许是没有时序数据库，这不是说时序数据库没有必要，而是时序数据库作为数据库细分品类或许没有必要。这既是时序数据库的终结，也是时序数据库的重生。正如多年前很火的“NoSQL”一词现在很少提及，但是某些流行的NoSQL产品，譬如Elasticsearch、MongoDB仍然广受欢迎。只不过由于大多数NoSQL产品开始支持关系型数据库的特性，譬如ACID、SQL等，使得“NoSQL”一词作为一个数据库类别已经意义不大了。

— 推荐阅读?—

?