前言

全文来自：工业互联网时代，我们为什么需要时序数据库之：适合的就是最好的 (baidu.com)
当年图灵用他深邃的眼睛，看穿了世间万物的计算本质：凡是可以计算的，通过迭代，最终都可以表示为0、1的逻辑判断

图灵机指出了数据的3个核心需求：1、数据写入；2、数据存储；3、数据读取。

时序数据库的特点

• 数据写入

  • 时间是一个主坐标轴，数据通常按照时间顺序抵达
    ?大多数测量是在观察后的几秒或几分钟内写入的，抵达的数据几乎总是作为新条目被记录
    ?95％到99％的操作是写入，有时更高

  • 更新几乎没有

• 数据读取

  • 随机位置的单个测量读取、删除操作几乎没有
  • 读取和删除是批量的，从某时间点开始的一段时间内
  • 时间段内读取的数据有可能非常巨大

• 数据存储

  • 数据结构简单，价值随时间推移迅速降低
  • 通过压缩、移动、删除等手段降低存储成本

关系数据库：
（1）数据写入：大多数操作都是DML操作，插入、更新、删除等；
（2）数据读取：读取逻辑一般都比较复杂；
（3）数据存储：很少压缩，一般也不设置数据生命周期管理

时间序列数据跟关系型数据库有太多不同，但是很多公司并不想放弃关系型数据库。于是就产生了一些特殊的用法，比如：用 MySQL 的 VividCortex, 用 PostgreSQL 的 TimescaleDB；当然，还有人依赖K-V、NoSQL数据库或者列式数据库的，比如：OpenTSDB的HBase，而Druid则是一个不折不扣的列式存储系统；更多人觉得特殊的问题需要特殊的解决方法，于是很多时间序列数据库从头写起，不依赖任何现有的数据库, 比如： Graphite，InfluxDB。

性能

时序数据库，核心问题去解决批量读写，对于 95% 以上场景都是写入的时序数据库，B-Tree 很明显是不合适的，业界主流都是采用 LSM Tree（Log Structured Merge Tree）或者LSM的“升级版”TSM（Time Sort Merge Tree） 替换 B-Tree，比如 Hbase、Cassandra、InfluxDB等。LSM Tree 核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能，避免了随机写入。

LSM Tree 简单操作流程如下：

数据写入和更新时首先写入位于内存里的数据结构。同时，为了避免数据丢失也会先写到磁盘文件中。

内存里的数据结构会定时或者达到固定大小会刷到磁盘。

随着磁盘上积累的文件越来越多，会定时的进行合并操作，减少文件数量。

在内存or文件中，对数据进行压缩、去重等操作。

分区

还有一个提升性能的关键点，即：分布式处理。

通常分布式数据库一般有两种Sharding策略：Range Sharding和Hash Sharding，前者对于基于主键的范围扫描比较高效；后者对于离散大规模写入以及随即读取相对比较友好。

对于时序数据库来说，基于时间的Range Sharding是最合理的考虑，但如果仅仅使用Time Range Sharding，会存在一个很严重的问题，即写入会存在热点，基于TimeRange Sharding的时序数据库写入必然会落到最新的Shard上，其他老Shard不会接收写入请求。对写入性能要求很高的时序数据库来说，热点写入肯定不是最优的方案。解决这个问题最自然的思路就是再使用Hash进行一次分区，**基于Key的Hash分区方案可以通过散列很好地解决热点写入的问题。

TimescaleDB

是基于 PostgreSQL 数据库开发的一款时序数据库，以插件化的形式打包提供，随着 PostgreSQL 的版本升级而升级，不会因为另立分支带来麻烦。

PostgreSQL 是一个免费的对象-关系数据库服务器(ORDBMS)

PostgreSQL 13.1 手册

PostgreSQL 特征:

数据仓库（DW）：能平滑迁移至同属 PostgreSQL 生态的 GreenPlum，DeepGreen，HAWK 等，使用 FDW 进行 ETL（postgres fdw是一种外部访问接口，它可以被用来访问存储在外部的数据，这些数据可以是外部的pg数据库，也可以是oracle、mysql等数据库，甚至可以是文件）

TimescaleDB 具有以下特点

1. 基于时序优化

2. 自动分片（自动按时间、空间分片(chunk)）

3. 全 SQL 接口

4. 支持垂直于横向扩展

5. 支持时间维度、空间维度自动分区。空间维度指属性字段（例如传感器 ID，用户 ID 等）

6. 支持多个 SERVER，多个 CHUNK 的并行查询。分区在 TimescaleDB 中被称为 chunk。

7. 自动调整 CHUNK 的大小

8. 内部写优化（批量提交、内存索引、事务支持、数据倒灌）。

• 内存索引，因为 chunk size 比较适中，所以索引基本上都不会被交换出去，写性能比较好。
• 数据倒灌，因为有些传感器的数据可能写入延迟，导致需要写以前的 chunk，timescaleDB 允许这样的事情发生(可配置)。

9. 复杂查询优化（根据查询条件自动选择 chunk，最近值获取优化(最小化的扫描,类似递归收敛)，limit 子句 pushdown 到不同的 server,chunks，并行的聚合操作）

10. 利用已有的 PostgreSQL 特性（支持 GIS，JOIN 等），方便的管理（流复制、PITR）

11. 支持自动的按时间保留策略（自动删除过旧数据）