用传统数据库存时序数据？慎重！慎重！慎重！

导读

本文以第一人称的形式转述一位好友的故事（请放心阅读，已取得许可），讲述他使用传统关系型数据库存储时序数据导致的一次故障，最终切换到时序数据库才解决了问题。通过本文，希望大家可以了解时序数据库的特点和优点，善假于物，能够根据自己的场景选择合适的数据库，文末有交流群二维码，大家可以加群交流探讨。

免(gao)责(xiao)申明：希望大家不会因为阅读本文学会甩锅，如果学会了那也不是我的错(哈哈哈哈哈)。

正文

在一个月不黑风不高的夜晚，突然被电话吵醒，一看，是组长的电话，刚接起电话，就听到对面着急的说：马上看群消息，出故障了。我刚赶紧说“好的”，领导就挂掉了电话。

我立马披件衣服打开数据后端工作组的群消息：

这咋回事呢，昨天下班的时候都好好的。

为了确定问题确实存在，我手动连接上数据库进行了数据查询，确实响应很慢，而且最新数据的时间是好几个小时之前的，确实没有最新数据。

这就奇怪了，怎么会这样呢？我想起一位技术达人“四神”曾推荐的一本书《你的灯亮着吗？》，乐呵着终于能派上用场，尝试进行如下推理寻找问题原因：

• 数据库没有最新数据是一个结果，那么原因大概率发生在离它最近的流程环节上：可能是数据库写入数据时发生错误，也可能是写入数据的服务模块有Bug导致压根没有发起写数据库操作。

• 因此，我们可以看数据库有没有错误日志，以及看看写入数据的服务模块有没有写入失败或者写入成功的日志。

正思考的时候，群里面同事更新了反馈：

(写代码的人，就是应该自信……）

大家都说没问题，也没有报错信息……根据刚才的思考，我赶紧问同事有没有成功日志：

（老哥啊，我该给你颁发勤俭节约奖）

完了~流程上没有啥蛛丝马迹可以参考，我也不知道有啥其他方式可以找到相关线索（如果朋友们有好的处理经验，还请在评论区留言告知）

根据以往的经验，如果某个流程上可能有问题，那么可能就会影响跟它交互的模块，因此我们可以看一看那些模块的当前状态。

既然现在已经证实是写入流程出现问题，且根据同事群里的描述，写入与Kafka有关系，那么Kafka的当前状态有没有异常？我顿时兴奋起来，赶紧询问运维同学：

快快快，大脑切换到超频模式，继续沿着那两本书给的思路思考：

• Kafka消息堆积多是结果。那么Kafka消息什么情况下不会堆积多呢？

• 当然是写入数据的模块消费得快，就不会堆积多 。

• 但现在堆积多，是否说明写入数据的模块消费得慢？是的。

• 为什么消费慢？那肯定是这个模块做事情太慢了。

• 它做什么事情？写入数据库。

• 所以……写入数据库太慢了？

我赶紧继续问运维同学：

一时竟不知道该高兴还是不高兴，高兴的是找到了问题原因，但不高兴的是~~~数据库出现问题，而且还是我推荐的某数据库，太尴尬了····

我尝试调整了一些参数进行优化，仍然无济于事……

突然我想到一个问题，数据库怎么会突然压力增大呢？赶紧问一问。(哈哈，万一是他们搞出来的Bug导致的呢？哈哈哈哈~~甩锅）

完了，这可没办法了，需求不能砍，还找不到办法优化……

一时陷入了Jiang局……

---

时间已经来到了早上七点多，想起四神是不是已经起床准备去上班了？赶紧去QQ群问问他：

根据四神的建议，我去网上寻找时序数据库并开始着手迁移和切换，过程非常顺畅，花了一天时间就切换过去了，现在系统的Kafka没有消息堆积，系统不仅能稳定存储设备采集的数据，而且查询速度比以前还快很多！

想必大家在想为什么时序数据库能解决我的问题，现在，我就跟大家分享下时序数据和时序数据库的特点。

时序数据的主要特点是：每一条时序数据都一定带有时间，每一个数据源会源源不断的产生很多条时序数据，且每一条数据都需要存储在数据库里，因此时序数据场景下的数据量通常都是很大的。此外，一条时序数据分为两部分：Tag和Field。Field的数据字段类型通常是数值类型，仅有这些Field数据字段才是变化的，而每个数据源产生的数据的Tag部分则通常是不会变更的。(因此可以专门、特殊优化）

数据查询有如下特征：

• 指定数据源，查询最新数据

• 指定数据源，查询最老数据

• 指定数据源，查询某时间范围的原始数据，并按照时间排序

• 指定数据源，最查询某时间范围的数据进行聚合分析

• 指定数据源，将时间划分为为多个区间，每个区间进行聚合分析

• 通常一次查询所涉及的列不会很多

我们可以看到，通常每一条查询都会跟时间有关系。（即便没有指定具体的时间范围）

数据写入要求支持快速写入，而且需要支持乱序时间写入（因为存在补数据的可能，或者各个微服务写入数据时存在先后顺序不是按照时间递增顺序）。此外，时序数据场景通常不需要修改数据。

这些特征（主要是快速写入和查询）对数据库提出了很高的要求，因此有专门针对时序数据的时序数据库。

时序数据库需要支持以下特性：

• 列式存储物理引擎：每一个列单独顺序存放，提高查询性能

• 高压缩比：由于每个列单独存放，每列的值相似度高，可进行压缩

• 最近数据缓存：除数据分析外，时序场景关注当前状态，此功能可提高最新数据查询性能

• 时间分区：将数据按照时间范围分为多个独立的分片，可以缩小查询的数据集，从而提高查询速度

• 时间索引：进一步提高指定时间的数据查询性能

• 聚合优化：采用预计算结果，避免读取原始数据，从而优化常用聚合查询，

• 多核并行写入和查询

因此具备以上特性的优秀时序数据库可以提供高效快速的写入和查询。

传统关系型数据库为什么就无法很好支持呢？我认为是以下原因：

1. 传统关系型物理存储引擎是基于行存，每一行的数据连续存放，SQL执行时每次读取所需行的所有列数据，但实际SQL计算却只需少量的列，因此造成IO浪费导致过多的IO开销，导致查询性能低。

2. 基于行存的存储引擎无法很好支持列存引擎所具备的并行IO数据读取。

3. 基于行存的存储引擎无法很好的利用压缩，因此存储空间较大，存储空间大会增加IO开销，影响读写性能。

4. 传统关系型数据库的索引技术无法很好支持时间索引（时间持续变化，量级很大），如果构建时间索引，会导致索引数据非常大而且导致写入性能慢。

5. 传统关系型数据库的查询执行引擎基于火山模型，无法利用现代CPU的能力，无法很好支持分析型查询任务。

以上是我的个人理解，希望增加大家对时序数据库的了解，才疏学浅难免有遗漏，欢迎大家评论区指正。

后记

感谢大家的阅读，朋友们若对本文中相关技术和问题处理方式有好的想法和建议，还请评论区留言探讨，也可以直接进群一起探讨交流，谢谢大家。

官方网站：

文档：海东青数据库 | 海东青时序数据库此在线文档主要包括海东青数据库v2版本的产品介绍、特性介绍、SQL手册和开发指南，以及高级特性和运维管理等。https://fctsdb.rockontrol.com/docs/

关注海东青时序数据库公众号：

也可添加「falcontsdb1」微信进群讨论：