---

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

---

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

想写本文，是因为看到了知乎上的一篇文章：投资数据库领域：2021年总结（NoSQL、图、时序） - 知乎，里面谈到了时序数据库：

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

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

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

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

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

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

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

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

这样做的好处是：

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

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

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

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

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

这样导致的问题是：

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

总结下来：

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

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

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

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

Writing a Time Series Database from Scratch | Fabian Reinartz

Prometheus项目的核心开发者写的文章，介绍了如何从头实现一个时序数据库的存储引擎，可做为上面文章更深入的补充。

CMU在2017年时组织的时序数据库系列讲座

邀请了一系列业内时序数据库的从业人员来分享，见：Time Series Database Lectures – Fall 2017

阿里云数据库内核月报分类整理

阿里云数据库内核团队的月报提供了很多学习数据库技术的资料、文章，这个github将每个月的月报进行了分类整理，推荐收藏。

How Does a Database Work? | Let’s Build a Simple Database

自己动手打造一个简单的数据库，应该有很多地方参考了SQLite的实现，本博客也深度解析了sqlite的btree实现，见：sqlite3.36版本 btree实现（零）- 起步及概述 - codedump的网络日志。

上面这个项目是使用C语言实现的，类似的打造简易数据库来学习原理的项目还有其他语言的版本：

《河西走廊 》

非常棒的介绍河西走廊的历史纪录片，2017年在甘肃旅游，就是一路沿着河西走廊过来的，一边旅游一边看这部纪录片。

《浮生一日》

B站上纯纯甘的节目《浮生一日》是我每期都会看的节目，主题是每次采访跟踪一个不同行业素人的生活。

最开始知道这个栏目是看了【浮生一日】北京国企外卖小哥的真实一天，背景是这位小哥由于疫情原因失业，所以找了一份国企的工作；媳妇买P2P赔光了积蓄，赶上老人得病要治疗，所以晚上得出来兼职跑跑外卖。

里面有句话让我感动：“结婚时面对自己媳妇儿最漂亮的时候，你说我愿意和你同甘共苦，然后现在又开始责怪她，那当初又何必说这四个字呢？”

这个栏目里还有各色不同职业的人：程序员、投资者、早餐摊位主人…等等。

不同的职业，都有各自不同的生活轨道和选择。

油管上有同名频道。

porter.io

porter.io是基于Github关注项目推荐相关文章发送邮件通知的应用：

“We analyse your Github footprint, filter Hacker News items according to your taste, and deliver them to your mailbox.”

我通过这个应用，还是被推荐才看到了不少有价值的文章的的。

独立开发变现周刊

每周更新推荐一些独立开发变现的产品。