Tembo 时间序列 API

本扩展的目的是为时间序列表的创建、维护和使用提供一致的用户体验。

安装

使用 Docker 运行

启动一个预装 pg_timeseries 的 Postgres Docker 容器。

docker run -d --name pg-timeseries -p 5432:5432 -e POSTGRES_PASSWORD=postgres quay.io/tembo/timeseries-pg:latest

然后连接到数据库并启用扩展：

psql postgres://postgres:postgres@localhost:5432/postgres

CREATE EXTENSION timeseries CASCADE;

NOTICE:  installing required extension "columnar"
NOTICE:  installing required extension "pg_cron"
NOTICE:  installing required extension "pg_partman"
CREATE EXTENSION

入门

假设您已经创建了一个分区表，只需使用表名调用 enable_ts_table 函数即可。

SELECT enable_ts_table('sensor_readings');

通过这一调用，将发生以下几件事：

• 该表将使用 PostgreSQL 的原生分区功能重构为一系列分区
• 每个分区覆盖特定的时间范围（默认为一周）
• 将为未来一段时间创建新分区（默认为一个月）
• 每小时一次，维护作业将创建任何缺失的分区以及所需的未来分区

使用您的表

那么您已经有了一个表。接下来呢？

索引

您创建的时间序列表最初只是典型的分区 PostgreSQL 表。但这种简单性也意味着 PostgreSQL 的所有现有功能都可以"正常工作"。时间序列表的一个相当重要的部分是沿时间维度的索引。

传统的 B 树索引适用于时间序列数据，但您可能希望对 BRIN 索引进行基准测试，因为它们在特定查询场景中可能表现更好（通常是具有多个结果的查询）。如果您预计每个分区中的记录不超过一百万条（默认情况下，分区为一周长），请从 B 树开始。

分区大小

与上述索引信息相关的是分区大小的问题。由于计算分区表的总大小可能会很繁琐，Tembo 的扩展提供了几个易于使用的视图来呈现这些信息。

要检查每个分区的表（数据）、索引和总大小，只需查询时间序列分区信息视图 ts_part_info。一般经验法则是，每个分区的大小应该能够放入您可用内存的大约四分之一。这假设除了时间序列工作负载之外没有太多其他任务，并且并行工作者等因素可能会使情况变得复杂，但努力将分区总大小控制在内存的四分之一左右是一个良好的开始。

保留策略

另一方面，您可能担心一开始就将大量数据插入存储层。虽然 ts_table_info 视图可能会缓解您的担忧，但在某个时候，您确实会想要删除一些时间序列数据。

幸运的是，按计划删除时间序列分区非常简单。使用 set_ts_retention_policy 函数，并提供您的时间序列表和一个时间间隔（比如 '90 days'）来建立这样的策略。每小时一次，任何完全超出保留窗口的分区都会被删除。使用 clear_ts_retention_policy 可以恢复到默认行为（无限期保留）。调用这些函数时，它们都会返回先前的保留策略。

压缩

有时您知道较旧的数据不经常被查询，但仍然不想直接删除较旧的分区。在这种情况下，压缩可能是您所需要的。

通过对时间序列表调用 set_ts_compression_policy 并提供适当的时间间隔（比如 '1 month'），该扩展将每小时一次处理压缩超过指定间隔的分区（使用列式存储方法）。与保留策略功能一样，还提供了一个用于清除任何现有策略的函数（但现有分区不会被解压缩）。

分析助手

该扩展包括几个旨在使编写正确的时间序列查询更容易的函数。某些概念在标准 SQL 中可能难以表达，辅助函数可以帮助提高可读性和可维护性。

first 和 last

这两个函数有助于简化一种相当常见的模式：查询按一个维度分组，但用户想知道按不同维度排序时组中的第一行或最后一行。

例如，您可能有一个报告指标的云计算平台，希望知道平台中每台机器的最新（按时间）CPU 利用率指标：

SELECT machine_id,
last(cpu_util, recorded_at)
FROM events
GROUP BY machine_id;

date_bin_table

这个函数自动化了将时间序列值对齐到给定宽度或"步长"的繁琐过程，并确保为源表没有数据点的任何时间段包含 NULL 行。

它必须针对时间序列表调用，但除此之外，使用它相当简单：

SELECT * FROM date_bin_table(NULL::target_table, '1 hour', '[2024-02-01 00:00, 2024-02-02 15:00]');

这个查询的输出将与直接查询目标表有三个不同之处：

• 行将按时间升序排序
• 时间列的值将按提供的宽度分箱
• 将为没有数据的时期添加额外的行。它们将包括该箱的时间戳，其他列为 NULL

要求

如 Docker 安装演示所示，pg_timeseries 扩展依赖于三个其他扩展：

• Hydra Columnar
• pg_cron
• pg_partman

我们建议参考这些项目中的文档以了解更高级的用例，或更好地理解此扩展的工作原理。

路线图

虽然 timeseries 仍处于早期阶段，但我们对未来将包含的功能有明确的愿景。关于某个特定功能对客户用例重要性的反馈将帮助我们更好地优先考虑以下列表。

这个列表在某种程度上按照近期交付的可能性或难度排序，但这个属性只是大致的，不保证优先级。再次强调，用户的反馈将优先考虑。

• 与时间序列工作负载经常相关的各种"分析"函数
• 定期 REFRESH MATERIALIZED VIEW — 为物化视图的后台刷新设置计划（对仪表板等有用）
• 转移到 TABLESPACE — 随着数据变旧，将其移动到指定的表空间
• 使用"分层存储"，即将较旧的分区移动到 S3 而不是磁盘上存储
• 非实时分区的自动 CLUSTER BY/重新打包
• 迁移工具 — 为现有时间尺度安装提供适配器，以简化迁移并促进新表配置的最佳实践
• "近似"函数 — 在已知误差范围内维护统计信息，无需重新扫描所有数据
• 更改分区宽度 — 修改现有表的分区宽度（用于未来数据）
• "汇总和转移" — 随着数据变旧，将多行合并为单个汇总行
• 增量视图维护 — 定义随着传入数据保持更新的视图，而不会产生 REFRESH 的性能影响
• 重新分区 — 修改现有表数据的分区宽度