时序数据库

概念

时序数据库全称为时间序列数据库，属于非关系型数据库。时间序列数据库指主要用于处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。

时序数据特点

时间序列数据主要由电力行业、化工行业、气象行业、地理信息等各类型实时监测、检查与分析设备所采集、产生的数据，这些工业数据的典型特点是：

• 产生频率快（每一个监测点一秒钟内可产生多条数据）
• 严重依赖于采集时间（每一条数据均要求对应唯一的时间）
• 测点多信息量大（常规的实时监测系统均有成千上万的监测点，监测点每秒钟都产生数据，每天产生几十GB的数据量）

时序数据库特点

时序数据库产品的发明都是为了解决传统关系型数据库在时序数据存储和分析上的不足和缺陷，这类产品被统一归类为时序数据库。针对时序数据的特点对写入、存储、查询等流程进行了优化，这些优化与时序数据的特点息息相关：

• 存储成本：
  利用时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩比；
  通过预降精度，对历史数据做聚合，节省存储空间。
• 高并发写入：
  批量写入数据，降低网络开销；
  数据先写入内存，再周期性的dump为不可变的文件存储。
• 低查询延时，高查询并发：
  优化常见的查询模式，通过索引等技术降低查询延时；
  通过缓存、routing等技术提高查询并发。

时序数据存储原理

传统数据库存储采用的都是 B tree，这是由于其在查询和顺序插入时有利于减少寻道次数的组织形式。我们知道磁盘寻道时间是非常慢的，一般在 10ms 左右。磁盘的随机读写慢就慢在寻道上面。对于随机写入 B tree 会消耗大量的时间在磁盘寻道上，导致速度很慢。我们知道 SSD 具有更快的寻道时间，但并没有从根本上解决这个问题。

对于 90% 以上场景都是写入的时序数据库，B tree 很明显是不合适的。业界主流都是采用 LSM tree 替换 B tree，比如 Hbase, Cassandra 等 nosql 。

LSM tree 包括内存里的数据结构和磁盘上的文件两部分。分别对应 Hbase 里的 MemStore 和 HLog；对应 Cassandra 里的 MemTable 和 sstable。LSM tree 操作流程如下：

• 数据写入和更新时首先写入位于内存里的数据结构。为了避免数据丢失也会先写到 WAL 文件中。
• 内存里的数据结构会定时或者达到固定大小会刷到磁盘。这些磁盘上的文件不会被修改。
• 随着磁盘上积累的文件越来越多，会定时的进行合并操作，消除冗余数据，减少文件数量。

LSM tree vs B tree

传统关系型数据采用的底层数据结构是B+树，那么同样是面向磁盘存储的数据结构LSM-Tree相比B+树有什么异同之处呢？

LSM-Tree的设计思路是，将数据拆分为几百M大小的Segments，并是顺序写入。

B+Tree则是将数据拆分为固定大小的Block或Page, 一般是4KB大小，和磁盘一个扇区的大小对应，Page是读写的最小单位。

在数据的更新和删除方面，B+Tree可以做到原地更新和删除，这种方式对数据库事务支持更加友好，因为一个key只会出现一个Page页里面，但由于LSM-Tree只能追加写，并且在L0层key的rang会重叠，所以对事务支持较弱，只能在Segment Compaction的时候进行真正地更新和删除。

因此LSM-Tree的优点是支持高吞吐的写（可认为是O（1）），这个特点在分布式系统上更为看重，当然针对读取普通的LSM-Tree结构，读取是O（N）的复杂度，在使用索引或者缓存优化后的也可以达到O（logN）的复杂度。

而B+tree的优点是支持高效的读（稳定的OlogN），但是在大规模的写请求下（复杂度O(LogN)），效率会变得比较低，因为随着insert的操作，为了维护B+树结构，节点会不断的分裂和合并。操作磁盘的随机读写概率会变大，故导致性能降低。

还有一点需要提到的是基于LSM-Tree分层存储能够做到写的高吞吐，带来的副作用是整个系统必须频繁的进行compaction，写入量越大，Compaction的过程越频繁。而compaction是一个compare & merge的过程，非常消耗CPU和存储IO，在高吞吐的写入情形下，大量的compaction操作占用大量系统资源，必然带来整个系统性能断崖式下跌，对应用系统产生巨大影响，当然我们可以禁用自动Major Compaction，在每天系统低峰期定期触发合并，来避免这个问题。

分布式存储

时序数据库面向的是海量数据的写入存储读取，单机是无法解决问题的。所以需要采用多机存储，也就是分布式存储。分布式存储首先要考虑的是如何将数据分布到多台机器上面，也就是分片（sharding）问题。

时序数据库的分片方法和其他分布式系统是相通的。

• 哈希分片：这种方法实现简单，均衡性较好，但是集群不易扩展。
• 一致性哈希：这种方案均衡性好，集群扩展容易，只是实现复杂。代表有 Amazon 的 DynamoDB 和开源的 Cassandra。
• 范围划分：通常配合全局有序，复杂度在于合并和分裂。代表有 Hbase。

时序数据库压缩原理

压缩对于时序数据库是至关重要的。因为时序数据库面对的物联网场景每天都会产生上亿条数据。众所周知，在大数据时代的今天数据的重要性是不言而喻的，数据就是公司的未来。但如果无法对这些时序数据进行很好的管理和压缩，那将给客户带来非常高的成本压力。

无损压缩

无损压缩是说被压缩的数据和解压后的数据完全一样，不存在精度的损失。对数据的压缩说到底是对数据规律性的总结。时序数据的规律可以总结为两点：1、timestamp 稳定递增、2、数值有规律性，变化稳定。

先看 timestamp 那一列是等差递增数列，可以用 [1467627245000,1000,4] 来表示。1467627245000 代表了第一个时间，1000 代表后一个时间比前一个时间的大 1000，4 代表了这样的规律出现了 4 次。如果一共有 100 个这样规律的 timestamp，那就意味着，我们用 3 个 Long 型就可以表示出来。timestamp 压缩率高达 33。

再进一步观察看 value 那一列，如果取差值，可以得到（6，-5，2，-5），全部都加 5 得到（11，0，7，0），这些数值都可以用 4bit 来表示。也就是用 [23,5,4,0xb0700000] 来表示（23，22，24，25，24）。其中的 4 代表后续一共有 4 个数。如果这样的规律一直维持到 100 个 Int 的 value，就可以用 16 个 Int 来代表，压缩率高达 6.3。

InfluxDB 无损压缩算法在其页面上有完整的阐述，可以配合开源源码进行更加深入的理解。针对于浮点数类型，Facebook 在 Gorilla 论文中提到的非常高效的无损压缩算法，已经有很多文章进行分析。InfluxDB 对于浮点型也采用这个算法。

有损压缩

有损压缩的意思是说解压后的数据和被压缩的数据在精度上有损失，主要针对于浮点数。通常都会设置一个压缩精度，控制精度损失。时序数据的有损压缩的思路是拟合。也就是用一条线尽可能的匹配到这些点，可以是直线，也可以是曲线。

最有名的时序数据有损压缩是 SOIsoft 公司的 SDA 算法，中文称为旋转门压缩算法。

在上图中，红色的点是上一个记录的点，空心的点是被丢掉的点，绿色的点是当前的点，黑色的点是当前要记录的点。

可以看到图左边，当前点和上一个记录点以及压缩精度的偏差值形成的矩形可以包含中间的点，所以这些点都是可以丢掉的。

再看图右边，当前点和上一个记录点形成的矩形无法包含中间的点，所以把上一个点记录下来。如此进行下去，可以看到，大部分的数据点都会被丢掉。查询的时候需要根据记录的点把丢掉的点在插值找回来。

有损压缩除了可以大幅减少存储成本。如果结合设备端的能力，甚至可以减少数据的写入，降低网络带宽。

开源时序数据库

目前行业内比较流行的开源时序数据库产品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其产品特性对比如下图所示：

参考

https://baike.baidu.com/item/时序数据库/922671?fr=aladdin

https://blog.csdn.net/liukuan73/article/details/79950329

https://blog.csdn.net/u010454030/article/details/90414063

https://www.infoq.cn/article/condense-in-sequential-databases