TimescaleDB：具有追加与中点插入和索引的超表的性能

Posted 2023-03-25

【中文标题】TimescaleDB：具有追加与中点插入和索引的超表的性能

【英文标题】：TimescaleDB: performance of a hypertable with append vs. midpoint inserts and indexing

【发布时间】：2021-08-31 02:08:44

【问题描述】：

我有一些时间序列数据要导入 TimescaleDB，作为超表中的 (time, item_id, value) 元组。

我已经创建了一个索引：

CREATE INDEX ON time_series (item_id, timestamp DESC);

在时间序列中间插入行与在time 末尾追加行时，TimescaleDB 是否具有不同的性能特征？我知道这是一些原生 PostgreSQL 数据结构（如 BRIN 索引）的问题。

我问是因为对于一些item_ids，我可能有不完整的数据，我需要在其他item_ids 填充时间序列的尖端之后插入这些值。基本上，有些项目可能是严重落后于其余项目的旧数据。

【问题讨论】：

基于文档 -docs.timescale.com/timescaledb/latest/overview/core-concepts/… - 听起来更新/插入旧块与常规 postgres 表大致相当，因为这就是一个块，即常规 postgres 表。跨度>

【参考方案1】：

我不认为它的反应不同，

在您的情况下，插入性能将取决于

您在该表上有多少索引？它们真的都需要吗？ 这些索引是否具有最少的必需列？ 使用并行插入/复制。请参阅here 了解更多信息。 批量插入行 正确配置您的 shared_buffers（文档建议使用 25% 的可用 RAM）

但是这个技巧会帮助你最好的

以松散的时间顺序写入数据 当块的大小适当时，最新的块及其相关索引自然会保存在内存中。使用最近时间戳插入的新行将写入内存中的这些块和索引。

如果插入具有足够旧时间戳的行——即，它是乱序或回填写入——则需要从磁盘读取与旧块（及其索引）对应的磁盘页面。这将显着增加写入延迟并降低插入吞吐量。

特别是，当您第一次加载数据时，请尝试按已排序的、时间戳递增的顺序加载数据。

如果您要批量加载有关许多不同服务器、设备等的数据，请小心：

不要按服务器顺序批量插入数据（即，服务器 A、服务器 B、C 的所有数据，依此类推）。这将导致磁盘抖动，因为加载每个服务器会在重新开始之前遍历所有块。

相反，请安排您的批量加载，以便以松散的时间戳顺序插入来自所有服务器的数据（例如，所有服务器并行的第 1 天，然后并行所有服务器的第 2 天，等等）

来源：TimeScale blog

【讨论】：

感谢您的努力@esihirvana。虽然这并没有给出我问题的确切答案，但真正的 TimeScale 知识很少。