数据库的模型包含关系型、key-value 型、Document 型等很多种，那么为什么新型的时序数据库成为监控数据存储的新宠呢？ 下面就会从
- 为什么需要时序数据库？
- 时序数据库的数据结构
两个方面来介绍一下时序数据库。
1. 为什么需要时序数据库
1.1 时序数据特点
时序数据有如下几个特点：
- 基本上是插入操作较多且无更新的需求
- 数据带有时间属性，且数据量随着时间递增
- 插入数据多，每秒钟插入需要可到达千万甚至是上亿的数据量
- 查询、聚合等操作主要针对近期插入的数据
- 时序数据能够还原数据的变化状态
- 可以通过分析过去时序数据的变化、检测现在的变化，以达到预测未来如何变化的目的
时序数据使用需求：
- 能够按照指标筛选数据
- 能够按照区间、时间范围、统计信息聚合展示数据
1.2 why
为什么不用一个「常规」 的数据库？
-
事实上，你完全可以可以使用非时序序列的数据库，并且也确实有人是这样做的。
**注**： 数据源 Percona，2017 年 2 月. <https://www.percona.com/blog/2017/02/10/percona-blog-poll-database-engine-using-store-time-series-data/>- 1
为什么需要时序数据库？
-
规模
时间数据的特点是累计速度非常快，常规数据库在设计之初，并非是为了处理这种规模的数据，而且关系型数据库在处理大规模的数据集的效果非常差。
-
使用特性
时序数据库能够提供一些通用的对时间序列数据分析的功能和操作，比如数据保留策略、连续查询、灵活的时间聚合，此外时序数据库以时间为维度，也提供更快的大规模查询、更好的数据压缩等。
1.3 场景选择
是否所有的数据都适合用时序数据库来存储？
答案：是否定的，时序数据库提供了针对大量数据的插入操作，但同时数据的读取延迟也相对增加。而且时序数据库不支持 SQL 的数据查询。
主要适用时序数据库的场景：
-
监控软件系统： 虚拟机、容器、服务、应用
-
监控物理系统： 水文监控、工厂的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等
-
资产跟踪应用： 汽车、卡车、物理容器、运货托盘
-
金融交易系统： 传统证券、新兴的加密数字货币
-
事件应用程序： 跟踪用户、客户的交互数据
-
商业智能工具： 跟踪关键指标和业务的总体健康情况
2. 时序数据库的数据结构
传统数据库存储采用的都是 B+ tree，原因是查询和顺序插入时有利于减少寻道次数的。然而对于 90% 以上场景都是写入的时序数据库，使用了 LSM tree 更合适。
2.1 LSM产生背景
LSM (Log Structured Merge Trees) 通过减少随机的本地更新操作来达到更好的写操作的吞吐量。
影响写操作吞吐量的主要原因还是磁盘的随机操作慢，顺序读写快，解决办法是将文件的随机存储改为顺序存储，因为完全是顺序的，提升写操作性能，比如日志文件就是顺序写入。
写数据的问题解决了，那如何快速的读出数据呢？
顺序写入的日志文件，在读取一些数据的时候需要全文扫描，但这一操作耗时取决于需要读取的数据在日志文件中的位置，所以其使用场景有限，适用于数据被整体的访问的情况下，像大部分数据的 WAL。
对于读操作，可以记录更多的内容比如 key、range 来提高性能，比较常用的方法有：
- 二分查找：将文件数据有序保存，使用二分查找来完成特定 key 的查找。
- 哈希：用哈希将数据分为不同的 bucket。
- B+ 树：使用 B+ 树，减少外部文件的存取。
以上的方案都是将数据按照特定的方式存储，对于读操作友好，但写操作的性能必然下降，主要原因是这种存储数据产生的是磁盘的随机读写，不适用于时序数据库 90% 都是写入的场景。
2.2 LSM 算法
LSM 是将之前使用的一个大的查找结构（造成随机读写，影响写性能的结构，比如 B+ 树），变换为将写操作顺序的保存到有序文件中，且每个文件只保存短时间内的改动。文件是有序的，所以读取的时候，查找会非常快 。且文件不可修改，新的更新操作只会写入到新的文件中。读操作检查有序的文件。然后周期性的合并文件来减少文件的个数。
-
写入操作
数据先在内存中缓存（memtable) 中，memtable 使用树的结构来保持 key 是有序的，同时使用 WAL 的方式备份数据到磁盘。当 memtable 中数据达到一定规模后会刷新数据到磁盘生成文件。
-
更新写入操作
文件不允许被编辑，所以新的内容或修改只是简单的生成新的文件。当越多的数据存储到系统中，就会有越多的不可修改、顺序的有序文件被创建。但比较旧的文件不会被更新，重复的激流只会通过创建新的记录来达到覆盖的目的，但这这就产生了冗余的数据。
系统会周期性的执行合并的操作，合并操作用于移除重复的更新或者删除记录，同时还能够减少文件个数的增加，保证读操作的性能。
-
读取操作
查询的时候首先检查内存数据（memtable)，如果没有找到这个 key，就会逆序的一个个的检查磁盘上的文件，但读操作耗时会随着磁盘上文件个数的增加而增加。（O(K log N), K为文件个数， N 为文件平均大小）。可以使用如下策略减少耗时
- 将文件按照 LRU 缓存到内存中
- 周期性的合并文件，减少文件的个数
- 使用布隆过滤器避免大量的读文件操作（如果bloom说一个key不存在，就一定不存在，而当bloom说一个文件存在是，可能是不存在的，只是通过概率来保证）
2.3 时序数据库的存储
-
单机上的存储
核心就是通过内存写和后序磁盘的顺序写入获取更高的写入性能，避免随机写入，但同时也牺牲了读取性能
-
分布式存储
分布式存储需要考虑如何将数据分布到多台机器上面，即分片(sharding)的问题。分片问题包括分片方法的选择和分片的设计问题。
分片方法：
- 哈希分片： 均衡性较好，但集群不易扩展
- 执行哈希：均衡性好，集群扩展易，但实现复杂
- 范围划分：复杂度在于合并和分裂，全局有序
分片设计
分片的会直接影响到写入的性能，结合时序数据库的特点，根据 metric + tags 分片是比较好的方式，查询大都是按照一个时间范围进行的，这样形同的 metric + tags 数据会被分配到一台机器上连续存放，顺序的磁盘读取是很快的。
在时间范围很长的情况下，可以根据时间访问再进行分段，分别存储到不同的机器上，这样大范围的数据就可以支持并发查询，优化查询速度。
如下图，第一行和第三行都是同样的tag（sensor=95D8-7913;city=上海），所以分配到同样的分片，而第五行虽然也是同样的tag，但是根据时间范围再分段，被分到了不同的分片。第二、四、六行属于同样的tag（sensor=F3CC-20F3;city=北京）也是一样的道理。
计划后面写一篇 关于InfluxDB 的文章，上文的大部分内容是 google + 个人理解，如果发现哪里有误，欢迎指出。