时序数据库的4个误区，你踩了几个？

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

然而业内对时序技术的认知还停留在数年前，本文阐述时序数据库的4大误区，希望帮助读者理清来龙去脉和背后原因，以便在业务场景中选择合适的数据平台和技术栈。

误区1

关系数据库不适合时序数据的采存算用

时序数据是时间序列数据，其本质是带有时间戳的一系列结构化数据，通常是周期固定的数据，譬如数控机床每百毫秒采集的轴坐标、移动量、速度等数据，无人机每秒采集的位置、高度、风力、风向等数据，汽车每分钟采集的位置、车速、转速、温度等数据，智能冰箱每小时采集的温度、湿度、耗电量，用户访问网站的点击事件流等数据。下面是时序数据的一个例子：metrics为指标名字，tags标识时序数据的来源，data为时间戳和该时刻的metrics指标值。

为了解决以上时序数据特点带来的挑战，受限于当时的技术能力，数年前业内走了开发专为时序数据而设计的时序数据库路线，我们称之为专用时序数据库。专用时序数据库的核心设计是存储引擎，以解决高效存储数据源属性信息、数据源指标信息、数据源层级关系信息等问题，并提供与之相匹配的简单的执行引擎和API，有的还提供某种形式的查询语言（譬如InfluxDB提供了Flux查询语言）。典型的代表是InfluxDB、OpenTSDB。

专用时序数据库一定程度满足了业务对时序数据处理的子集需求，然而也有诸多问题：

近几年，由于专用时序数据库的种种不足，工业界出现了一种新型的时序数据库方案：把时序（时间戳序列）当作关系数据库的一个数据类型，在关系数据库内设计相应的存储器，并增强优化器和执行器以发挥该存储器的优势，我们称之为超融合时序数据库（或关系时序数据库）。

把时序当做一种数据类型并不新颖，关系数据库从上世纪七八十年代就支持时间戳数据类型，然而过去关系数据库并没有专门为时序场景而优化，所以不能很好的满足时序场景的需求。原因是关系数据库普遍采用行存+Btree索引的方式：行存不利于压缩，而Btree是一种为读而优化的数据结构，会牺牲一定的写性能，所以传统认为行存+Btree不适合作为时序数据的存储方式。时序数据更适合使用列存+排序+预聚集等技术以提高写入速度、压缩比和查询性能。目前常见的时序数据库都使用了基于LSM 树的某种变种技术。

1. LSM树比B+树更适合写入，但是查询处理不如B+树友好。基于LSM变种的时序数据库为了解决各种场景的高性能查询需求，需要引入额外的开销，这些开销会降低数据写入性能，譬如InfluxDB为了支持多维查询引入了TSI，数据写入时需要创建并维护TSI数据。此外B+树虽然会造成随机IO，但是通过WAL+Buffer可以大幅降低随机IO频次。这样综合下来，基于LSM树的产品写入性能不一定比B+树产品更好。下图测试10万设备，采集指标10个、50个、100个、400个不等，实测了MatrixDB、TDEngine、TimescaleDB、InfluxDB四种时序数据库：

这个数字不是说B+树更适合时序场景，而是表达最终产品会综合考量非常多因素。

2. 现在很多关系数据库支持可插拔存储引擎、执行引擎和优化引擎技术架构，这使得关系数据库可以实现多种存储引擎，分别用来处理不同的数据类型或场景，譬如行存引擎存储关系数据、列存引擎存储历史数据、LSM引擎存储时序数据。这样可以在一款数据库中实现对不同数据类型和场景的处理，这种产品称为超融合数据库。超融合时序数据库基于模块化可插拔技术架构，在数据库内部提供专为时序数据优化的存储引擎（譬如基于LSM tree的存储引擎），并配以与之适应的执行器和优化器，借助关系数据库几十年的技术沉淀和最新工业技术成果，使得关系数据库除了支持原来的关系数据处理场景，还可以高效而灵活的处理时序数据全场景（包括点查、分析查询和流数据处理）而不再需要额外的产品配合，实现时序全场景all-in-one。

这种新思路新架构具备很大的优势：

故而，时序数据是一种结构化非常好的数据，非常适合使用专为时序优化过的关系数据库进行存储和处理，而不必使用专用时序数据库。

诸如MatrixDB这样的超融合时序数据库产品，在关系数据库中实现了对时序数据的支持，并且性能卓越，远超专用的时序数据库，测评指标参见https://ymatrix.cn。

误区2

时序数据库不需要正确性（ACID）

传统时序数据库，诸如InfluxDB、OpenTSDB、TDEngine等都不支持事务。然而这并不意味着时序场景不需要事务。毋庸置疑，有一些时序场景，譬如服务器监控，可以容忍丢失数据或者重复数据，但是也有大量的场景不希望错数据、重数据或者丢失数据，譬如：

时序数据库之所以放弃ACID主要是考虑到支持ACID的额外开销，希望通过放弃ACID以提高性能。实际上时序数据主要操作是INSERT和SELECT，从事务的角度来看，对总体性能影响微乎其微。

误区3

时序数据库不需要分析能力

主流时序数据库如InfluxDB、OpenTSDB，以及一些新时序数据库例如TDEngine，都只支持简单的查询，支撑简单的场景，譬如单数据源单/多指标过滤查询、单数据源单/多指标过滤聚集，多数据源过滤聚集等。核心是点查和聚集查询。

然而随着大数据分析、IoT、IIoT等快速发展，越来越多的应用需要更强大的分析能力，以实现模式识别、趋势预测等高级功能。因而时序数据需要强大的分析能力，包括和关系数据的关联聚集分析和高级分析（如ARIMA、趋势预测、特定模式识别、根因分析、阈值修正）等。

此外用户希望能用自己熟悉的语言譬如Python、R等对时序数据进行更复杂的处理，并充分发挥Python、R在数据分析方面的强大生态。

误区4

时序场景不需要关系型数据库

很多人认为时序场景只需要时序数据库，实际上很少有场景只需要时序数据库。绝大多数情况下，时序数据库需要关系数据库配合，以解决实际业务问题，因为时序数据库本质只能表达时间序列数据以及和时间序列数据紧密相关的元信息，譬如数据源id，位置，供应商等额外信息。而实际场景中，需要更多信息才能发挥时序数据的价值，譬如工业设备监控、智能制造、柔性制造、个性化定义等等。传统的时序数据库如InfluxDB、OpenTSDB无法解决这种场景，而必须配之以关系型数据库，以获得时序数据更多的上下文信息。