一、背景

随着物联网的发展，时序数据库的需求越来越多，比如水文监控、工厂的设备监控、国家安全相关的数据监控、通讯监控、金融行业指标数据、传感器数据等。
在互联网行业中，也有着非常多的时序数据，例如用户访问网站的行为轨迹，应用程序产生的日志数据等等。

时序数据有几个特点：

• 基本上都是插入，没有更新的需求。
• 数据基本上都有时间属性，随着时间的推移不断产生新的数据，旧的数据不需要保存太久。

业务方对时序数据通常有几个查询需求。

• 获取最新状态，查询最近的数据（例如传感器最新的状态）。
• 展示区间统计，指定时间范围，查询统计信息，例如平均值，最大值，最小值，计数等。
• 获取异常数据，根据指定条件，筛选异常数据。

二、时序数据库应该具备的特点

• 压缩能力
  通常用得上时序数据库的业务，传感器产生的数据量都是非常庞大的，数据压缩可以降低存储成本。

• 自动rotate
  时序数据通常对历史数据的保留时间间隔是有规定的，例如一个线上时序数据业务，可能只需要保留最近1周的数据。为了方便使用，时序数据库必须有数据自动rotate的能力。

• 支持分片，水平扩展
  因为涉及的传感器可能很多，单个节点可能比较容易成为瓶颈，所以时序数据库应该具备水平扩展的能力，例如分表应该支持水平分区。

• 自动扩展分区，
  业务对时序数据的查询，往往都会带上对时间区间进行过滤，因此时序数据通常在分区时，一定会有一个时间分区的概念。时序数据库务必能够支持自动扩展分区，减少用户的管理量，不需要人为的干预自动扩展分区。例如1月份月末，自动创建2月份的分区。

• 插入性能
  时序数据，插入是一个强需求。对于插入性能要求较高。

• 分区可删除
  分区可以被删除，例如保留1个月的数据，1个月以前的分区都可以删除掉。

• 易用性(SQL接口)
  SQL是目前最通用的数据库访问语言，如果时序数据库能支持SQL是最好的。

• 类型丰富
  物联网的终端各异，会有越来越多的非标准类型的支持需求。例如采集图像的传感器，数据库中至少要能够存取图像的特征值。而对于其他垂直行业也是如此，为了最大程度的诠释业务，必须要有精准的数据类型来支撑。

• 索引接口
  支持索引，毫无疑问是为了加速查询而引入的。

• 高效分析能力
  时序数据，除了单条的查询，更多的是报表分析或者其他的分析类需求。这对时序数据库的统计能力也是一个挑战。

• 其他特色
  （1）支持丰富的数据类型，数组、范围类型、JSON类型、K-V类型、GIS类型、图类型等。满足更多的工业化需求，例如传感器的位置信息、传感器上传的数据值的范围，批量以数组或JSON的形式上传，传感器甚至可能上传图片特征值，便于图片的分析。（例如国家安全相关），轨迹数据的上层则带有GIS属性。
  这个世界需要的是支持类型丰富的时序数据库，而不是仅仅支持简单类型的时序数据库。
  （2）支持丰富的索引接口，因为类型丰富了，普通的B-TREE索引可能无法满足快速的检索需求，需要更多的索引来支持 数组、JSON、GIS、图特征值、K-V、范围类型等。 (例如PostgreSQL的gin, gist, sp-gist, brin, rum, bloom, hash索引接口)。
  这两点可以继承PostgreSQL数据库的已有功能，已完全满足。

三、TimescaleDB介绍

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

图 1 timescaleDB结构

数据自动按时间和空间分片（chunk）

• partition key（分区键）
  是由一个表上的一个列或者多个列组成，用于确定某一行特定数据分布在哪个分区上，用create table 语句来定义。
• chunks
  分区在TimescaleDB中被称为chunk。
• query across time
  跨时间查询
• query across space
  跨空间查询

透明自动分区特性
在时序数据的应用场景下，其记录数往往是非常庞大的，很容易就达到 数以亿计 。而对于PG来说，由于大量的还是使用B+tree索引，所以当数据量到达一定量级后其写入性能就会出现明显的下降（这通常是由于索引本身变得非常庞大且复杂）。这样的性能下降对于时序数据的应用场景而言是不能忍受的，而TimescaleDB最核心的自动分区特性解决的就是这个问题。这个特性希望达到的目标如下：

• 随着数据写入的不断增加，将时序数据表的数据分区存放，保证每一个分区的索引维持在一个较小规模，从而维持住写入性能。
• 基于时序数据的查询场景，自动分区时以时序数据的时间戳为分区键，从而确保查询时可以快速定位到所需的数据分区，保证查询性能。
• 分区过程对用户透明，从而达到自动扩展的效果。

图 2 PG库分区

上图是PG10声明式分区示例，我们创建了一个表树，以主表为根，接下来是下一个子级别的四个设备表，然后是任意数量的时间表第三个子层次。上图显示了PG库多维表分区的概念视图。

PostgresSQL分区的意思是把逻辑上的一个大表分割成物理上的几块儿。在PG里表分区是通过表继承来实现的，一般都是建立一个主表，里面是空，然后每个分区都去继承它。无论何时，都应保证主表里面是空的。

PostgreSQL 10.x 之前的版本提供了一种“手动”方式使用分区表的方式，需要使用继承 + 触发器的来实现分区表，步骤较为繁琐，需要定义附表、子表、子表的约束、创建子表索引，创建分区删除、修改，触发器等。PostgreSQL分区表（Table Partitioning）应用

PostgreSQL 10.x 开始提供了内置分区表（内置是相对于 10.x 之前的手动方式）。内置分区简化了操作，将部分操作内置，最终简单三步就能够创建分区表。但是只支持范围分区（RANGE）和列表分区（LIST），11.x 版本添加了对 HASH 分区。PostgreSQL 10分区表性能测试

从上图可以看出来，需要每个时间间隔创建四个新表，每个设备一个。额外的设备将使分区策略进一步复杂化，所有这些额外的表都可能对性能和可伸缩性产生负面影响，因为需要为插入和查询处理更多的表。

TimescaleDB也依赖于表继承，但避免了深度嵌套的多级继承树。相反，它直接在根创建一个浅层叶块树，而不管分区维度的数量，如下所示。

图 3 TimescaleDB分区

彩色框代表不同的”空间”键（例如，我们示例中的设备）。这样子的设计减少了树中表的数量并避免了嵌套。通过这样做，TimescaleDB 提高了插入和查询性能，简化了重新分区，并使表管理（和保留）更容易。