时序数据库破局开放探讨

近几年IoT、IIoT、AIoT和智慧城市快速发展，时序/时空数据库成为数据架构技术栈的标配。根据国际知名网站DB-Engines数据，时序数据库在过去24个月内排名高居榜首，且远高于其他类型的数据库，可见业内对时序数据库的需求迫切。

相应的时序数据库产品近年来也快速发展，出现了多款新的时序数据库产品，一些老牌时序数据库也推出下一代产品。本文将介绍现有的主流时序数据库技术架构，以及开放探讨时序数据库的终局形态。

▲四维纵横CEO 姚延栋

嘉宾介绍：北京四维纵横数据有限公司（https://ymatrix.cn）创始人、原Greenplum北京研发中心总经理、Greenplum中国开源社区创始人、PostgreSQL中文社区常委、壹零贰肆数字基金会（非营利组织）联合发起人。2005年毕业于中科院软件所, 拥有多项国内外云计算和大数据专利，并著有《Greenplum：从大数据战略到实现》。

以下是姚延栋老师在DTCC2021大会现场的演讲实录：

数据处理平台60年

站在更长远的角度来看，整个数据处理平台发展的历程。我这里做了一个简单的回顾，在数据库出现之前，主要用的是文件系统。当时，主要的数据是放在主文件里面，格式采用flat文件格式，其实就是固定长度的行，固定个数的列。

后面出现了IDS和IMS，这种层状和网状的数据模型。再往后出现了关系型数据库（OLTP），以及XML/对象数据库。到2009年，为了解决互联网大数据挑战，比如：扩展性、高性能、高并发等问题，出现了NoSQL数据库。

在整个过程中，大约在上世纪80年代，有一个叫分析型数据库（OLAP）的分支，也叫MPP数据库，对分析场景复杂查询优化。在2010年以后出现了很多新名词，像NewSQL、HTAP、Lakehouse、多模等。

这些名词我们就不做详细介绍了，但是它们的核心点在于跨界融合。从2010年，我们开始尝试不同的产品之间进行融合，来解决过去需要多个产品解决的问题。到2020年，出现了超融合数据库，也就是多层次、多角度地进行深度融合。

纵观过去60年，我们不难发现，大约每隔10年，就会出现一次技术PK。第一次是文件系统和数据库，第二次是CODSAL和关系数据库，第三次是XML数据库和关系数据库，第四次是NoSQL和分布式关系数据库。

当时，很难去辩证哪一个技术在未来会变成更有优势的技术路线。现如今，基本就明确了关系型数据库、分布式数据库的生命力更旺盛。技术的碰撞最终目的是互相学习，然后衍生出适应技术发展的产品形态。

我们讲到数据处理平台时，不可避免会涉及到三个产品。第一个产品是Hadoop，它的演进逻辑是从存储到计算。它起源于Apache Nutch项目（一个网页爬取工具和搜索引擎系统，后来遇到大数据量的网页存储问题）。

Apache Nutch需要一个存储引擎，所以做了HDFS，然后出现并行计算MapReduce和交互查询Hive，继而又出现了效率较高的Impala。到目前为止，Hadoop有点远离大数据的C位，这和它的底层演进逻辑有一定的关系。

第二个产品是Spark，它的演进逻辑是从计算到存储。Spark RDD是纯粹计算的接口，后面出现了Spark SQL和DataFrames，以及Spark Streaming、Spark Graph、Spark ML等。

所以我们能够看出，Spark的前几年都在做计算，为了适应不同的场景。但后面，Spark面临着数据存储和性能优化的问题，开始做DeltaLake。同时提出了一个词，叫做Lakehouse，它是一种结合了数据湖和数据仓库优势的新范式。

Snowflake的演进逻辑为从雪花到雪球，然后到更大的雪球。它背后的关键设计是存算分离、存算同时演进，开始就是一个完整的数据库，存储层和计算层都不断变化更新。

回顾过去60年，数据处理平台的发展有规律可循，可以分为图示四个阶段。数据库演进过程是一个处理复杂度的游戏，其核心是在需求推动之下，选择解决哪些复杂度问题，留哪些复杂度问题给用户，解决的效果如何。

主流时序数据库架构简析

最早，在上世纪80年出现的是PI System工业数据库，主要用于监控分析工业数据。1998年，出现了Kdb+，在证券极速交易场景使用较为广泛。此后，相继出现了RRDTool、Graphite，用于服务器和应用监控。

2011年，出现了首款分布式时序数据库——OpenTSDB。2013年，起步于服务器监控现，并发力于IoT的InfluxDB出现。2017年之后，相继出现了Timescale关系时序数据库和Timestream时序数据库。2020年，为时序大数据分析、IoT/IIoT/车联网而设计MatrixDB面世。

关于经典时序数据库架构，具体而言，OSISoft PI System拥有两个组件，PI archiver（自研时序引擎）和微软SQLServer（内部集成了关系数据库，说明关系数据在时序场景的必要性）。RRDTool以固定时间间隔采集数据、round-robin方式存储数据，最新数据覆盖老数据。

Graphite有个数据引擎Whisper，类似RRD，数据库大小固定，支持降采样。OpenTSDB基于HBase，是第一款分布式时序数据库，针对时序KV做了优化，譬如，一小时时间点散列为列族的不同列。

比较有意思的是，InfluxDB不断迭代存储引擎，从最早的LevelDB/RocksDB到TSM+TSI，再到Parquet+Arrow。下一代产品是IOx，主打分析能力和扩展性。TimescaleDB基于PostgreSQL，hack了存储层，使得1000+行数据可以自动转为1行，这样提升压缩比，降低存储空间。

MatrixDB是一款基于Greenplum及PostgreSQL开发的超融合时序数据库，在关系数据库内部实现了全新的存储引擎，并专为时序数据场景中的高速数据插入和多样性查询进行了优化，支持关系数据、时序数据、GIS数据，支持监控类小查询和大 OLAP 分析，支持JOIN及完善SQL标准。

上图为行业流行度排名第一的时序数据库InfluxDB的下一代时序数据库IOx要实现的目标，我们可以关注两点。一个是扩展性，第二个是分析性能。这也表明了行业老大InfluxDB在时序领域摸爬滚打了多年后对未来时序场景的认知和判断。

时序数据库破局探讨

当前时序架构具备“DIY技术栈，慢、复杂”三大特征。其中，慢是指使用专用产品，看似很快，但端到端组合在一起会慢；复杂意味着技术栈复杂，稳定性差，开发运维成本高，软硬件成本高，性能低，人才稀缺，把复杂度留给了用户。

那么，时序数据库应该是怎样的呢？它应该是快且简单的。奥卡姆剃刀原理中指出，“如无必要，勿增实体。”本质上要考虑是谁简单，谁复杂，能否成熟这种复杂？

未来，如何做一个更适合时序数据库场景的产品？既然要判断一个产品，肯定要回归到场景。和其他数据库一样，时序数据库具备读和写两个场景，但是它的读和写都非常有特色，写的场景需要平稳高效，并且大部分数据是实时数据，读的场景有点查/最新值、查询、峰值检测，高级分析模型等。

整个场景是多种多样的，为了匹配这种需求，如何去设计产品？时序场景95-99%为写操作，所以大多数时序数据库使用类LSM树方式，基于B+树的MatrixDB写入性能是基于LSM/TSM的InfluxDB的几十倍，是国内友商的十几倍。

这一点在PG中文社区第三方评测中得到验证：在400列数的场景下，MatrixDB比InfluxDB快48.6倍，仍然非常强悍，是国产数据库的一个新亮点。

值得一提的是，理论上讲B+树为读而优化，LSM树为写而优化。原因是B+树随机io比较高，但是实际工程实现的时候，有很多手段来降低随机io，最大限度地平衡存储和计算，为了提升写的性能，譬如采用WAL、通过Buffer尽量避免随机IO，通过分区避免B+树太大等。而LSM引擎为了提升读的性能，需要内建B+树加速读性能，内建Bloomfilter加速读，创建倒排索引加速查询，使用WAL避免丢数据。所以最终效果如何还要看实际工程优化的情况。当然我们对比B+树和LSM的主要目的是说明企业产品优化有很多需要关注的点，而不是说MatrixDB只支持B+树。实际上MatrixDB支持多种存储引擎，包括基于B+树的Heap引擎，也有基于LSM变种的mars存储引擎。

我们认为最好的时序架构是超融合架构，这种架构把极简、极速留给客户。超融合架构的核心是在数据库中，通过极致的可插拔，实现不同的存储引擎，可以是行存引擎、列存引擎、内存引擎、LSM引擎等。它们之间是互相隔离，互相不会影响。

在未来的数据库里面，比较有生命力的是关系模型。关系模型不再是上世纪70年代纯粹的只支持简单数据类型的关系模型，现在的关系数据模型的字段可以支持复杂数据类型。做一个数据库极具挑战，不单单是做引擎，还要做周边大量的组件。而超融合数据库基于关系数据模型，通过可插拔存储实现一个数据库同时支持关系数据、时序数据、GIS数据、半结构化数据和非结构化数据的All-in-One。

什么叫超融合数据库，从开发运维角度来看，它就相当于是关系库+时序库+分析库。以MatrixDB为例，不同的表可以使用不同的存储引擎，譬如总共200张表，180张表使用heap存储，用以处理关系数据的读写，20张表为时序表，用以存储时序数据的读写，他们之间还可以直接JOIN。

行列混存是在Partition内分数据块，在块内按照设备id、时间戳、温度和湿度维度以列式方式存储数据。

MatrixDB具有以下特性：

• 关于时序数据的写入，支持顺序上报、乱序上报、延迟上报、异频上报、上报信号/指标动态增减、更新或删除、自动降采样、持续聚集等多种方式。
• 写入的场景具备高性能、平稳持续、实时写入、数据正确性等特色。其中，95%以上操作是插入，且对性能敏感。平稳持续方面，没有明显的高低峰。实时写入方面，要求秒级写入。数据正确性方面，保证不错、不重、不丢，让开发人员聚焦业务，而不是数据处理。
• 时序数据存储方面，存储效率/压缩比十分重要，好的时序数据库可以做到10：1左右，针对某些范式数据压缩比高达几十倍。支持针对数据类型进行优化，支持多种编码压缩算法，包括delta-delta、gorilla、RLE、lz4、zstd等，以达到压缩比和压缩速度的平衡。
• 支持冷热数据分级存储，热数据、温数据、冷数据分层，最小化存储开销，具备自动分区管理功能，到了时间自动会执行相应的操作，无需人工干预。
• 支持多样性数据类型，比如，字符串、数字、日期/时间、布尔类型等基本数据类型，以及数组、IP地址等复合数据类型，兼顾效率和schemaless的灵活性的KV数据类型，点、线、多边形等空间数据类型（和函数），XML/JSON 等半结构化类型，文本等非结构化数据类型。
• 支持多样化的查询，包括单表的点查、明细、聚集、多维查询，多表的JOIN，支持10+表关联，以及子查询、窗口函数、Cube、CTE等高级分析。
• 支持数据库内机器学习能力，在数据库内部，实现了60多种机器学习的算法，包括监督学习、无监督学习、统计分析、图计算等。
• 支持数据库内建分析，比Spark快10倍以上。通过在数据库内执行Python/R/Java代码，避免移动海量数据，实现高效率灵活的数据分析。
• 一个产品本身有很长的路要走，不仅是技术层面，还需要具备完善的开发工具和生态，实现开箱即用。MatrixDB支持各种流行IDE，包括IntelliJ、DataGrip、Dbeaver、Navicat等，可以和BI和可视化的产品进行对接，支持ETL/CDC，支持MQTT、OPC-UA、OPC-DA、MODBUS等IoT协议。
• 作为一款企业级产品，MatrixDB具备稳定性、完备性，具备图形化部署，线性扩展，可以单机部署，也可以集群化部署，监控、报警以及可视化，在线扩容，不停机，不停业务，分布式备份恢复，资源管理，分钟级升级等功能。

总的来看，时序形态不是数据库，而是一种看待数据的视角，可以认为是一种时间维度的数据类型，终局是超融合时序数据库。

第一代是influxDB这样的仅支持时序的数据库。

第二代，TimescaleDB同时支持时序和关系数据。

第三代，MatrixDB超融合时序数据库，支持多模态数据，支持全场景查询，服务物联网海量数据监控、分析及存储的超融合时序数据库，解决过去关系型、时序型、分析型等不同类型数据库孤岛化问题。帮助企业解决当前技术栈复杂，开发运维及软硬件成本高，性能低等痛点。