时间序列数据库才是未来

首先，我们先理清一个概念：

关系型数据库是非关系数据库的真子集，非关系数据库是时间序列数据库的真子集。

关系型数据库

关系型数据库是这样定义的：

采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。

关系型数据库的集大成者是 MySQL 。关系型数据库的问题在于强调“关系”。但实际上，对象之间的关系是弱关系。强关系只是一种特例。

举个例子。我们定义三个对象：小明，小红和小王。小明和小红是同居的情侣，小王住在他们隔壁。有一天，小明回到家看到小红和小王呆在同一个房间里。这时小明会有什么想法呢？

他到底应该说小王和小红在过家家呢，还是认同他们的解释，认为小王是在给房间里换电灯泡呢？

这个关系的问题，其实就是关系型数据库的最大问题——乱搞关系。在现在很多开发设计规范里面，已经把关系型数据库当做一个数据存储的仓库（堆表），禁止存储过程，也禁止了外键。可以说，这是历史发展的必然结果。

非关系型数据库

那么，非关系型数据库，自然就是 NoSQL 。

NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在处理web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，出现了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。

其中有以 Redis 为代表的 key-value 数据库，也有以 MongoDB 为代表的文档型数据库。

Redis 是基于内存的（虽然也可以持久化到硬盘），内存是相当珍贵的资源。资源的有限限制了资源的广泛使用。

MongoDB 其实有点像 Excel ，在 Excel 文件里面，每一行可以有任意个单元格。

比如，新亘结衣在 MongoDB 中的“爱好”和“配偶”不是空（Null），而是压根就没有这个字段。

如果说 Redis 的问题在于内存过于珍贵，那么我觉得非关系型数据库的问题在于描述的对象“不够自然”。

时间序列数据库

“不够自然”的意思，就是缺少“时间”这个属性。实际上，时间才是数据的第一属性。任何数据如果没有时间这个属性，那么都变得毫无意义。所以很多表在设计的时候，从规范层面就是这样说的：要有创建时间这个属性。

除此以外，时间序列数据库应该满足这样一个特征：不可变性（Immutable） 。不可变性是指数据录入之后不可变更。数据库的业务靠实时数据流引擎去处理。

时间序列数据库，才是最切合现实世界的模型。举个最简单的例子：我要用小拳拳捶你胸口。我们先简化一下这个动作，然后再录入到时序数据库里面吧 ~

“小拳拳捶你胸口”，最简化的模型就是，描述一个点在三维空间里面“线段”（因为移动的距离有限，所以叫线段）运动到另外一个点。

在三维空间里面，求两点之间的距离，其实跟在一维空间求两点的距离，没啥差别，泛化勾股定理就行了。我会这样说，勾股定理，是升高维度的“梯子”。

有这样的认识，在时序数据库里面，定义数据非常之自然而简单。还是以这个问题为例，解决这个问题，只需要隔一段采集数据，并录入即可。

监控分析

杭州迪火科技监控平台负责人董兵林是这样说的：“（阿里云）TSDB 帮助我们解决了指标数据存储的问题，其表现出的极佳性能，零运维成本，数据永久存储，专门的技术支持，都是我们一直使用的原因。目前我们可以很方便的查看实时指标信息和回溯历史的指标信息，及时发现问题，为进一步的决策提供依据，TSDB 是我们不可缺少的一部分。”

趋势分析

趋势分析，是用来预测未来的一种概率。比如，在上面的数据中，用三维直角坐标系建模，就会得到一条线性趋势线。我们可以预测2020-04-01 09:35:04，我的小拳拳大概率会落于（4，4，4）这个坐标点。

溯源分析

溯源分析跟趋势分析是相反的，是时间倒序的另外一种数据结构。

在这个问题中，我们建立一条线性趋势线之后，可以用溯源推理分析出2020-04-01 09:34:59我的拳头大概率位于 (0,0,0) 。

也就是说，这是用来预测“过去”的一种概率。溯源分析可以用于刑侦破案，历史遗留问题溯因等场景。

现在的时间序列化数据库，每一行的记录还是比较结构化的。而且，被大量应用于监控领域，这其实是一种误解。
广义的时间序列数据库，每一行数据支持任意属性。

结论

我相信在未来，时序数据库将超越关系型数据库和非关系型数据库，成为应用开发的首选方案。

参考链接

1. 关系型数据库
2. NoSQL
3. 散点图是什么？有什么用？
4. 时间序列数据库 TSDB