从存储模型聊一聊时序数据库的应用场景

Question

引言：本期介绍时序数据库的存储模型，只有理解了时序数据的存储模型，才能更好的了解时序数据库的优缺点以及其适用场景。

时序数据库：

但缺陷是实际的市场空间较小。跟通用型数据库，尤其是 OLAP 数据库相比，时序数据库最大的差异点在于对于时间维度建立了独特的索引与优化，而其他所谓 schemaless 等特性在 OLAP 数据库上都能做到，不存在技术障碍。这也就是为什么其实在公司做时序场景的数据库选型的时候会直接将时序数据库与一些 OLAP 数据库（比如 ClickHouse）做比较。如果要把时序数据库往更宽的场景发展，那就是想好如何与那么多的通用型数据库做竞争了。

由于之前有过短暂一段时间的时序数据库从业经历，所以想从我的理解聊聊时序数据库的应用场景。

要了解应用场景，需要首先对时序数据库的存储模型有个大概的了解，在下文中我尽量不涉及到太艰深的技术术语来描述我的理解。由于我从业时序数据库的时间并不长，所以有可能理解会有偏差。

何谓时序数据（time-series data）？就我个人粗浅的理解，就是任何一定会带上时间戳（timestamp）维度的数据。日常生活里，在微博、微信等社交媒体的发现就可以理解时序数据，因为它们肯定都有一个发言时间，所以有时候会把个人看到的微博等称为时间线（timeline）。对应到工业领域，比如一个电表每小时上报的用电量也是时序数据，比如服务器监控时每隔 15 分钟采集的性能数据也是时序数据。

由于时序数据天然有“时间“这个维度，为了更好的优化其写入性能，通常专门存储时序数据的存储引擎会按照时间分块、按列来存储数据，如下图：

上图中，演示用的数据格式有三列：

• 时间戳。
• A 指标。
• B 指标。

通常，时序数据库存储时，会按照时间来划分块（block）：

• 块的大小固定。
• 在同一个块时间区的数据，会存储到同一个块中。
• 而块内部，将除了时间维度之外的其他的列，将其中相同列的数据存储在一起。

这样做的好处是：

• 由于时序数据的特点，写入的数据也是在时间上连续的，因此通常写入的时候按照上面的设计就能落在同一个块中。
• 不同行但是同一列的数据，都是相同类型的，将相同类型的数据紧邻放在一起，更容易进行压缩。

换言之，这样做换来的好处是：

• 在时序数据的写入场景下，写入速度很快。
• 由于同类型数据放在一起，压缩性能也很好。

这些都是相对于传统 BTree 类存储引擎而言的，因为这类型的数据写入更像 append 操作，这是必然会更快的。

但是注意到没有，这样存储数据之后，最大的问题是：查询时只有时间这个维度做了索引，而除去时间维度之外的其他列都没有做索引。

这样导致的问题是：

• 任何查询都要带上时间参数才能管用。比如：“请查询过去一个小时里哪五分钟的 CPU 最高”这样的查询是可以的，但是更多其他的查询是不知道时间维度，或者说查询者就是不知道具体时间才想来查询的，比如“我是什么时候达成了累计跑步 100 公里成就的？”这类探索型、且没有时间维度的查询。
• 即便是带上了时间维度的查询可行，由于没有对其他维度做索引，所以查询时的处理，更多的是按照时间维度查询出数据、再进行聚合计算，比如上面的“请查询过去一个小时里哪五分钟的 CPU 最高”这个查询，只能先把过去一小时的 CPU 数据全部查出来，然后逐个计算才能算出哪 5 分钟的 CPU 最高了。

总结下来：

• 时序数据库根据时序数据的特点设计和优化了时序数据库的存储模型，对比传统的关系数据库存储模型来说，优势是写入速度快、压缩比高。
• 但这样的存储只有时间这个维度，换言之由于没有其他维度的索引数据，导致对不带有时间维度或者时间跨度大的查询支持的不够友好。

回到最开始引用的文章，了解了时序数据库的存储特点，也就能解释为何作者认为纯粹的时序数据库场景不大了。

好像大部分时候，事情也是这样的：

• 在一个维度优化到极致，可能其他维度就做的不够好，不存在各个维度都能做得很好的产品，因为不同维度之间也会彼此有制约，更多时候要看使用者自己的场景取舍，并不存在适用于一切场景的产品。
• 所谓优势，在换了上下文和场景之后，也可能会变成劣势。