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

TimescaleDB: performance of a hypertable with append vs. midpoint inserts and indexing

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

我已经创建了一个索引：

CREATE INDEX ON time_series (item_id, timestamp DESC);

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

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

我不认为它的反应不同，

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

  • 你有多少个索引table？真的需要它们吗？
  • 这些索引是否有最低要求的列数？
  • 使用并行insert/copy。有关详细信息，请参阅 here。
  • 批量插入行
  • 正确配置您的 shared_buffers（文档推荐的可用 RAM 的 25%）

但这条提示将对您提供最好的帮助

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

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

尤其是，当您第一次加载数据时，请尝试按时间戳递增的顺序加载数据。

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

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

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

来源：TimeScale blog