压缩设计

时间序列数据可能很独特，因为它需要处理浅层宽泛查询（例如“过去 10 分钟内整个部署发生了什么”）以及深层窄范围查询（例如“过去 24 小时内此服务器的平均 CPU 使用率是多少”）。时间序列数据通常也有非常高的插入速率；每秒数十万次写入对于时间序列数据集来说非常常见。此外，时间序列数据通常非常精细，并且数据收集的分辨率高于许多其他数据集。这可能导致随着时间的推移收集到数 TB 的数据。

所有这些都意味着，如果您需要高压缩率，则可能需要在开始摄取数据之前考虑数据库的设计。本节涵盖了在设计数据库以实现最大压缩效率时需要考虑的一些事项。

TimescaleDB 基于 PostgreSQL 构建，而 PostgreSQL 本质上是一个面向行的数据库。由于时间序列数据是按时间顺序访问的，因此当您启用压缩时，TimescaleDB 会将许多宽行数据转换为单个数据行（称为数组形式）。这意味着新的宽行的每个字段都存储一个包含整个列的有序数据集。

例如，如果您有一个看起来有点像这样的数据表

您可以将其转换为数组形式的单行，如下所示

即使在您压缩任何数据之前，这种格式通过减少每行开销，也能立即节省存储空间。PostgreSQL 通常每行增加少量字节的开销。因此，即使没有任何压缩，此示例中的模式在磁盘上的大小也比以前的格式更小。

这种格式将数据排列成连续存储相似数据，例如时间戳、设备 ID 或温度读数。这意味着您可以使用特定类型的压缩算法进一步压缩数据，并且每个数组都会单独压缩。有关所用压缩方法的更多信息，请参阅压缩方法部分。

当数据以数组形式存储时，您可以非常快速地执行需要部分列的查询。例如，如果您有一个查询，像这样，它要求过去一天的平均温度

SELECT time_bucket(‘1 minute’, timestamp) as minute
 AVG(temperature)
FROM table
WHERE timestamp > now() - interval ‘1 day’
ORDER BY minute DESC
GROUP BY minute;

查询引擎可以只抓取和解压缩时间戳和温度列，以高效地计算并返回这些结果。

最后，TimescaleDB 使用非内联磁盘页来存储压缩数组。这意味着行内数据指向一个存储压缩数组的辅助磁盘页，而主表中的实际行变得非常小，因为它现在只是数据指针。当查询这样存储的数据时，只会从磁盘读取所需列的压缩数组，通过减少磁盘读写进一步提高性能。

在前面的示例中，数据库无法知道哪些行需要被抓取和解压缩以解决查询。例如，数据库无法轻易确定哪些行包含过去一天的数据，因为时间戳本身就在一个压缩列中。您不希望为了确定需要哪些行而解压缩一个块中的所有数据，甚至整个超表中的数据。

TimescaleDB 会自动在行中包含更多信息，并添加额外的分组以提高查询性能。当您手动或通过压缩策略压缩超表时，指定一个 ORDER BY 列会有帮助。

ORDER BY 列指定了压缩批次中行的排序方式。对于大多数时间序列工作负载，这通常是按时间戳排序，因此如果您不指定 ORDER BY 列，TimescaleDB 默认使用时间列。您还可以指定其他维度，例如位置。

对于每个 ORDER BY 列，TimescaleDB 会自动创建额外的列来存储该列的最小值和最大值。这样，查询规划器可以查看压缩列中的时间戳范围，而无需进行任何解压缩，并确定该行是否可能匹配查询。

当您压缩超表时，您还可以选择指定一个 SEGMENT BY 列。这允许您按特定列对压缩行进行分段，以便每行压缩数据对应于单个项目的数据，例如，特定的设备 ID。这进一步允许查询规划器确定该行是否可能匹配查询，而无需先解压缩该列。例如

通过这种方式对数据进行分段，对设备 A 在某个时间间隔内的查询会变得非常快。查询规划器可以使用索引来查找设备 A 中包含至少一些与指定间隔对应的时间戳的行，即使是顺序扫描也相当快，因为评估设备 ID 或时间戳不需要解压缩。这意味着查询执行器只解压缩那些选定行对应的时间戳和温度列。