Timescaledb 压缩、segmentby 和分块答案

【问题标题】：Timescaledb compression, segmentby and chunkingTimescaledb 压缩、segmentby 和分块
【发布时间】：2023-03-06 10:07:01
【问题描述】：

timescaledb 中的segementby col 设置是否确保它将为 col 的每个不同值创建一个新块？这在文档中有所暗示，但没有在任何地方明确说明。

例如，使用文档中的示例将遵循以下segmentby deviceid

time    device_id   cpu disk_io energy_consumption
[12:00:02, 12:00:01]    1   [88.2, 88.6]    [20, 25]    [0.8, 0.85]
[12:00:02, 12:00:01]    2   [300.5, 299.1]  [30, 40]    [0.9, 0.95]

这是否会在给定的时间范围内创建 2 个单独的块？这很重要，因为无法写入/更新压缩块，因此如果在同一时间范围内稍后出现新的设备 ID 数据点以供摄取，这会是一个问题吗？

【问题讨论】：

标签： timescaledb

【解决方案1】：

压缩的超表以与原始超表相同的方式分块。压缩应用于每个块，并为每个原始块创建一个压缩块。

segmentby 指定如何组合或分组行以进行压缩。 segmentby 列的每个唯一值都会在压缩块中生成一条记录，其中所有其他列的值都被压缩在一起。

在问题示例中，segmentby 列 device_id 中有两个唯一值：1 和 2。然后将其他列中的对应值组合在一起并压缩。因此，在示例中，device_id = 1 有两行，device_id = 2 有两行。如果所有四个原始记录都存储在原始超表的同一个块中，则两个对应的压缩记录将存储在一个压缩块中。

这很重要，因为无法写入/更新压缩块，因此如果在同一时间范围内稍后出现新的设备 ID 数据点以供摄取，这会是一个问题吗？

不支持对压缩的原始块进行任何更改。所以插入带有新的segmentby 值的数据会失败并报错。

更新：要更新压缩块中的数据，例如回填数据，需要手动解压缩块，更新数据，然后再将数据压缩回来，如decompression chunk documentation所述。

【讨论】：

如果说device_id = 3在块压缩后创建了具有相同时间范围的，是否会存储在一个新的块中？
@nehz 压缩块无法修改。在这种情况下，您将收到错误消息。（我显然错过了这部分问题，并将添加到答案中）
谢谢。当有未完成的旧数据（例如来自异地）要摄取时，这似乎确实使 TSDB 更具限制性
如果我 create_hypertable 和 partitioning_column 在 device_id 上，这不会为每个唯一的 device_id 创建一个块吗？
@nehz 你的意思是device_id 上的额外空间维度吗？还是您想将其用作时间维度？如果它是时间维度，那么它将混淆 TimescaleDB，因为值不会在“时间”中向前移动。如果是额外的空间维度，那么就需要指定固定的分区数。请注意，块是表并带来开销，因此需要权衡块的数量及其大小。