Time Series Management Systems: A Survey

今天分享一篇时序数据库Survey，《Time Series Management Systems: A Survey》，2017 年 TKDE 的。作者 Søren Kejser Jensen, Torben Bach Pedersen, Senior Member, IEEE, Christian Thomsen，丹麦奥尔堡大学。他们在 2018 年有一篇时序数据库的论文： ModelarDB：Modular + Model。

正文 2005 字，预计阅读时间 6 分钟。

时序数据库的背景比较简单：时序数据爆炸式增长，传统的关系型数据库无法处理了。此外，为了更高级的分析，需要将数据向数据仓库导一份，或者交给其他的分析软件，如 R 或 SPSS 进行分析。这种关系型数据库加分析软件的架构增加了复杂度。

Survey 方法

由于是一篇 Survey，所以这篇文章一共调研了 27 个时序数据库，都是近10年有公开发表的文章。

Survey 的方法有这么几步，首先已经有一些相关文章了，其次：

1. 文章中的参考文献
2. 引用这些文章的文章（谷歌学术可以搜到）
3. 相关的会议或期刊（SIGMOD，VLDB，ICDE，USENIX等）。
4. 作者的其他文章（DBLP、个人主页等）

调研这么多系统，就需要比较，和归类，形成自己的理论大厦，为这些系统一个一个找到他们所在的位置。作者把这些系统按架构归为了三类。

内置数据存储

从底层数据存储开始开发，存储和数据处理引擎都是自己实现的，不依赖外部系统。

优点：数据存储和处理模块可以在系统内部深度集成。由于存储模块不为其他应用服务，就可以专门为处理模块优化。两个模块间的通信也可以省略。不依赖外部系统，部署也相对简单。

缺点：工作量较大，大部分现有的这种架构的系统都是单机版的或者理论原型，成熟度不高，大多没有分布式。而且新开发的存储模块的调优需要额外花费时间。

外置存储系统

基于现有的一些存储系统做一个时序数据库，基本都会选择一些分布式存储系统，如 HBase，Cassandra，HDFS 之类的，只需要上边实现一些数据处理引擎就可以了。

优点：工作量相对较少。底层系统调优已经有很多经验了，减少开发工作量。基本都是分布式的，扩展性好。

缺点：数据模型受底层系统限制，系统部署相对复杂。底层存储系统都没有针对时序数据进行优化（这一条到底有多大影响不好说）。

扩展关系数据库

扩展现有的关系型数据库，增加对时序数据的处理和分析功能。调研的三个有两个选了 PostgreSQL，一个选了 Oracle。大部分用多数学模型表达时间序列。有的用来优化存储，有的提供预测功能，有的提供历史查询。都不支持流处理。

优点：可以直接在系统中做数据分析。不需要数据导出和额外的分析软件。现有系统较成熟，有经验参考，现有功能也可重用。

缺点：开发受限于底层系统架构。事务功能可能多余。很难扩展为分布式。

衡量指标

可扩展性：50%-单机版，50%-分布式。

系统目标：30%-监控。10%-IoT。42%-数据分析。

查询引擎：67%-自己实现。33%-现有引擎（Hadoop、RDBMS、ES）

存储引擎：48%-自己实现，52%-现有引擎（RDBMS，DFS、NoSQL）

API：30%-客户端api，30%-SQL。

三种架构：33%-内置存储和查询引擎。56%-外接DBMS。11%-扩展RDBMS。

可以看到，自己实现存储引擎相对麻烦，外接存储引擎容易上手。

未来研究方向

作者还给了一些对未来研究方向的判断，由于作者偏研究数学建模，他们关注的也是如何将模型利用到时序数据库中。

这篇文章提到一个词 AQP（Approximate Query Processing），近似查询处理。基本有以下三种：

1. 普通的聚合功能，count，max，min这些。
2. 基于数学模型的聚合。比如用一个一次函数来表示时间序列，聚合就更好做。
3. 通过对部分数据采样，得到可能有一定偏差的结果。

作者给出的未来的研究方向也列一下：

1. 不同数据源的传感器数据是异构的，元数据注册复杂
2. 专门为几种特定查询模式进行优化
3. 物理网格系统CPS中，如何根据变动预测数据值，比如通过发动机状态的变动预测速度。
4. 数据量太多，对扩展性提出要求
5. 更新和删除可能不需要，但是增加了系统复杂度
6. 不同来源的数据特点不同，系统需要根据不同数据特点选择不同存储模型，来减少磁盘占用。
7. 基于模型的分布式AQP查询。
8. 给定错误率，自动选择合适的模型
9. 为了提供简单的分析，需要在模型上进行数据抽象，DataCube不支持实时更新
10. 缺乏流处理
11. 需要领域专家扩展模型库

可以看到，4-11 基本都是 ModelarDB 面向的场景。

总结

这篇 Survey 对三种架构的分类还是比较清楚的。每种架构也分别对各个系统进行了介绍，本文就不展开了。作者还是建模的背景的，所以在各个架构的总结中，都比较侧重系统有没有利用模型表示数据，或者支不支持AQP。忽然想起和大哥一起做IoTDB的时候，我有一些接口上的需求。大哥会说：你问我支不支持，肯定支持啊！