大象时序TimescaleDB在专网领域的应用--粉丝服务平台-粉丝头条-fensifuwu.com

大象时序TimescaleDB在专网领域的应用

科技 08-28 来源： DataFunTalk

导读：本文介绍了TimescaleDB时序数据库和PostgreSQL数据库在海能达的落地实践。

今天的介绍会围绕下面4点展开：

时序数据概念
TimescaleDB
测试
专网业务中的时序数据和TimescaleDB的应用

时序数据

时序数据即时间序列数据，是集体表示系统、流程或行为如何随时间变化的数据。时序数据可以来源于金融行业指标数据、日志数据、通讯监控和传感器数据。

时序数据的特征有：

以时间为中心：每条记录都是与时间关联的。
仅附加：数据只有插入和过期操作。
新数据通常与最近的时间间隔有关，很少更新或回填有关旧时间间隔的缺失数据。
与标准关系“业务”数据等其他数据相比，时间序列数据(以及支持它们的数据库)之间的主要区别在于对数据的更改是插入，而不是覆盖或修改。

以下几种场景会产生时序数据：

监控计算机系统：VM、服务器、容器指标金融交易系统:经典证券、较新的加密货币、支付、交易事件。
物联网：来自工业机器和设备、可穿戴设备、车辆、智能家居消费设备等传感器的数据
事件应用程序：用户/客户交互数据，如点击流、页面浏览量、登录、注册等。
商业智能：跟踪关键指标和业务的整体健康状况。
环境监测：温度、湿度、压力、pH、花粉计数、气流。与物联网场景类似。

基于PG的TimescaleDB

1. 需求

TimescaleDB支撑了我们的专网业务，我们的业务需要时序数据库具备如下能力和特性：

（1）压缩能力。时间序列数据会随着时间延续增多，如果数据的过期时间又很长，数据库对数据的压缩能力会直接决定业务成本。因为数据存储会占用硬件资源，特别是硬盘资源。

（2）自动数据过期清理。

（3）支持分片，水平扩展。时序数据在OLAP即分析类业务系统中有大量应用，在此场景下，分片、水平扩展能力非常有必要。

（4）自动扩展分区。可以让用户根据时间点等对数据进行分区。

（5）需要数据库具备较高的插入性能。

（6）分区可删除。

（7）易用性，最好可以支持标准SQL。

（8）支持类型丰富。

（9）有索引接口。

（10）具备高效分析能力。

2. TimescaleDB

TimescaleDB是基于PostgreSQL数据库打造的一款时序数据库，以插件化的形式，随着PostgreSQL的版本升级而升级，不会因为另立分支带来麻烦，方便维护。TimescaleDB可以应用PG的所有特性，扩展了PG的时序数据库特性。

TimescaleDB具备以下九个特点：

（1）TimescaleDB是PG的基于时序的优化。PG是一个关系型数据库，有查询优化器。

（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，并行的聚合操作）。

3. TimescaleDB核心概念——超表和块

超表（Hypertables）可以理解为逻辑概念，块（chunk）是数据存储的实际单元，一个超表可以包含多个块。块可以分布在单个或多个实例中，可以支撑分布式架构。块数据对上层应用不可见，应用直接访问超表，分布式集群对应用透明。

在一个更高的水平，数据库暴露了一个抽象的连续的表格：一个元表格，横跨所有的空间和时间间隔，这样你就可以通过普通的SQL 语句查询它，一个元表格使用标准的带有列名称和类型的模型，在集群部署环境中，一列指定了一个建立在可额外分割的数据集上的分区键。

在内部，TimescaleDB自动将hypertable分割成块，一个块对应着一个根据指定时间间隔和此分区键的区域确定的二维空间。每个块使用表中数据库表实现，这个表自动地被放置在某一个数据库节点中（或者在多个节点间复制）虽然这个细节很大程度上被隐藏。一个单一的TimescaleDB部署可以存储多个hypertable，每个hypertable可以有不同的表结构。

4. 部署模式

TimescaleDB有三种部署模式：

（1）单实例部署

安装了TimescaleDB 的单个 PostgreSQL 实例通常可以支持非常大的数据集和应用程序查询的需求。在没有TimescaleDB 的常规 PostgreSQL 实例中，在单台机器上扩展数据库性能的一个常见问题是内存和磁盘之间的重大成本/性能权衡。

（2）主从副本部署

TimescaleDB 支持使用标准 PostgreSQL 物理复制协议从“主”数据库服务器到单独的“副本”服务器的流式复制。该协议通过将数据库修改记录从主服务器流式传输到一个或多个副本来工作，然后可以将其用作只读节点（以扩展查询）或用作故障转移服务器（以实现高可用性）。

（3）分布式多节点部署

块数据可以分布到不同节点上做分布式，查询计划、执行计划、下推都可以通过TimescaleDB 扩展PG数据库的形式把分布式的查询计划、查询、下推发到具体节点均衡集群负载。在 TimescaleDB 的多节点部署中，数据库可以充当访问节点或数据节点的角色;两者都运行相同的TimescaleDB 软件以简化操作。

TimescaleDB当前版本对分布式的支持存在问题，SQL使用有限制、分片实例的高可用也需要依赖PG的流复制机制实现高可用。官方文档中提及后续版本中会以TimescaleDB原生的特性支持分片高可用。

5. 分布式超表

TimescaleDB 通过利用与上述相同的超表和块，支持跨多个节点（即集群）分布式超表。这允许TimescaleDB扩展插入和查询超出单个TimescaleDB 实例的功能。分布式超表和常规超表看起来非常相似，主要区别在于分布式块不存储在本地，还有一些分布式超表不支持的常规超表特性。

分布式超表存在于分布式数据库中，该数据库由存储在一个或多个 TimescaleDB 实例中的多个数据库组成。作为分布式数据库一部分的数据库可以承担访问节点或数据节点的角色（但不能同时充当两者），即分布式情况下节点内会有一个节点不存储数据，只负责分布式相关的请求调度。TimescaleDB 的分布式高可用需要依赖PG的流复制。

下图是分布式超表的架构，数据的索引、分布式表的实际数据都是按块存储的，检索数据时可以把数据加载到内存中，在内存中处理数据、加快OLAP分析。

6. 压缩

TimescaleDB 支持本地压缩存储在超表中的数据的能力，本机压缩不需要使用任何特定的文件系统或外部软件。压缩时间序列数据可以显着降低数据的存储需求，并且在许多情况下，可以加快对历史压缩数据的查询的响应速度。

压缩由TimescaleDB的内置作业调度程序框架提供支持，不需要额外安装PG的压缩调度插件。我们利用它来将单个块从未压缩的基于行的形式异步转换为跨超表的压缩列形式:一旦块足够老，块就会以事务方式从行转换为列形式。

7. 数据过期与保留

时间序列数据的一个内在部分是新数据不断积累，而旧数据很少更新，如果有的话，数据的相关性会随着时间的推移而减少。因此，通常希望删除旧数据以节省磁盘空间。

PG的Automatic Vacuuming会对 dead tuples 进行清理。下面的语句会对历史行打上删除标记，当达到需要清理数据的阈值时，Automatic Vacuuming会启动进程清理dead tuples。

SELECT drop_chunks('conditions', INTERVAL '24 hours');

这会从超表conditions中删除仅包含早于此持续时间的数据的所有块，并且不会删除块中的任何单个数据行。

过期的数据也可以用业务方式Delete，TimescaleDB 原生地支持了时序数据的DDL删除，是一个方便的功能，可以节省磁盘存储空间。

8. 自动数据保留策略

TimescaleDB 还包括一个后台作业调度框架，用于自动执行数据管理任务，例如启用简单的数据保留策略。借助策略，可以在每个超表上设置数据保留标准，并允许 TimescaleDB 根据需要删除数据。

创建数据保留策略以丢弃超过 6 个月的数据块：

SELECT add_retention_policy('conditions', INTERVAL '6 months');

使用基于整数的时间列创建数据保留策略:

SELECT add_retention_policy('conditions', BIGINT '600000');

9. 备份还原

备份TimescaleDB可以利用PostgreSQL已经提供的可靠功能。有几种方法可以做到这一点：使用pg_basebackup或其他工具进行物理备份，或使用pg_dumpand进行逻辑备份pg_restore。物理备份也可以与预写日志 (WAL) 归档一起使用，以实现持续备份。

如果有多节点部署，可以用TimescaleDB创建一个还原点 create_distributed_restore_point。从物理备份还原数据库时使用这个还原点，可以确保所有节点之间的一致性。

测试

海能达业务覆盖了国内80%的警用对讲系统，近一年引入了时序数据库支持监控和时序型分析业务数据。

在评估工作负载所使用的时序数据库时，需考虑了多个因素:

数据模型、查询语言、可靠性、性能、生态系统、运维管理、企业/社区的支持情况。

基于以上选型标准，并结合实际业务系统关键需求,时序型数据库需要支持，关系型数据模型、SQL查询语言、企业级可用性、完善的社区支持、协议商用无法律风险、GIS空间数据支持。分析时序型数据库排行榜前五的产品InfluxDB、Kdb+、prometheus、Graphite、TimescaleDB时序数据库排行榜如图，对比了排名前5的数据库后，我们选择了TimescaleDB。

InfluxDB优点很多，但开源版本只支持单节点、没有集群功能，集群版本需要收费。前后版本兼容性存在问题，存储引擎还在变化，因此不考虑InfluxDB。Kdb+不支持SQL查询、迁移成本高，不做考虑。海能达专网业务在传统关系型数据库上已经运行了一段时间，业务系统很多基于SQL与数据库进行交互，TimescaleDB支持SQL，符合专网业务需求、迁移成本低。

TimescaleDB是PG基于时序的优化，可自动分片（自动按时间、空间分片（chunk）），支持SQL，支持垂直于横向扩展，支持「时间维度」。支持多个 SERVER，多个 CHUNK 的并行查询、自动调整 CHUNK 的大小。

TimescaleDB在内部有写优化：批量提交、内存索引、事务支持、数据倒灌。内存索引，因为比较适中，所以索引基本上都不会被交换出去，写性能比较好。数据倒灌，因为有些传感器的数据可能写入延迟，导致需要写以前的 chunk，用户可配置TimescaleDB 是否允许这种数据更新方式。TimescaleDB有复杂查询优化，可根据查询条件自动选择chunk，最近值获取优化，最小化的扫描，类似递归收敛，limit 子句可 pushdown 到不同的server、chunks，可并行地做聚合操作。TimescaleDB利用已有的 PostgreSQL特性，支持GIS，JOIN等，能够方便地管理，可以做到流复制、PITR，支持自动的按时间保留策略，可自动删除过旧数据。

在数据模型方面，TimescaleDB是一种关系型数据，而其它时序型数据库更多是一种定制的、NoSQL的非关系型数据库。这意味着 TimescaleDB 是基于关系数据库模型的，关系模型在 PostgreSQL、MySQL、SQL Server、Oracle 等数据库中得到了普遍的应用。另一方面，其它时序型数据库提出了自己的数据模型。

可靠性方面，我们的业务场景需要数据库能支持同城容灾、异地容灾的需求，数据也需要是强同步、不能丢失的。TimescaleDB基于PG，因此可以利用PG已有的完善的强同步复制。

开源生态方面，TimescaleDB版本迭代和开源社区足够活跃，生态丰富。

下图是TimescaleDB官网提供的性能对比数据，当写入的时序数据达到一定数量级时，TimescaleDB性能比原生PG数据库性能表现好很多。