TimescaleDB/Postgres 占用的空间比预期的要多得多答案

【问题标题】：TimescaleDB/Postgres taking up far more space than expectedTimescaleDB/Postgres 占用的空间比预期的要多得多
【发布时间】：2023-03-06 16:18:01
【问题描述】：

我一直在 TimescaleDB 中保存一些刻度数据，并且对它占用的空间量感到惊讶。我对此很陌生，但我每天将大约 1000 万行保存到一个包含以下列的表中：

这已经占用了大约 35GB 一天，这似乎过多。我想知道我可以采取哪些步骤来减少这个数量 - 如果我将双打列更改为浮动，这会产生很大的影响吗？有没有其他方法可以减小这个尺寸？

编辑：

运行chunk_relation_size_pretty()的结果是：

和hypertable_relation_size_pretty():

索引占用这么多空间似乎也很奇怪 - 我尝试查询一定范围内的数据，结果花了很长时间才回来（一天的数据大约需要 10 分钟） .该指数目前设置为（仪器、交易所、时间DESC）之间的复合指数。

【问题讨论】：

我们需要更多数据：表定义是什么？ pgstattuple 对这张桌子有什么看法？
能否贴出表结构、索引和实际大小，可以通过hypertable_relation_size_pretty()和chunk_relation_size_pretty()获取
@k_rus 确定 - 我在问题中添加了更多信息。
我觉得数据库中有更多的东西，但我没有想出要寻找什么。你能跑VACUUM ANALYZE吗？你知道它是否已经运行了吗？
奇怪的是价格和数量存储为双。似乎是从 Javascript 直接翻译。我希望数量是整数，价格是小数或数字。

标签： postgresql timescaledb

【解决方案1】：

你应该打开 TimescaleDB 的原生压缩：

https://docs.timescale.com/latest/using-timescaledb/compression

【讨论】：

谢谢 - 我会测试一下。看起来这会有所帮助，但我不确定这是否是我遇到的主要问题。时间尺度数据库是否会正常占用更多空间（假设默认情况下已关闭）。
TimescaleDB 基本表结构（未压缩）与 Postgres 基本相同，因此这是行结构的基本开销。如果您进行数学计算，每行大约占用每列的宽度，加上大约 27 个字节用于附加元数据（例如 MVCC 版本控制）。 create_hypertable 默认情况下也会在时间戳上创建一个索引（btree）；你应该仔细检查你没有默认索引+你的复合。但是，复合索引可能很大并不奇怪——您可能有大量的 instructure/exchange/timestamp。
@MikeFreedman 我正在试验时间序列数据的时间刻度数据库。我盘点了每日数据。总共约 28 M 行。 Postgres 占用了 1.8 GB 的空间。使用 create_hypertable() 的 timescaledb 表占用了 2.2 GB（使用 hypertable_size('table_name')。这比 postgre 高得多。更令人惊讶的是，当我在代码上使用 segment_by 进行压缩时，大小会飙升至 4.0 GB。chunk_compress_stats() 显示每个块的大小大约增加 80%。
@MikeFreedman 详细信息在此处捕获medium.com/p/68405425827
@David - 在 Medium 中留下评论：如果我明白发生了什么：你的块可能太小（或者你的数据太稀疏）。每个块的“默认”时间间隔是一周。如果您每天只获取每只股票 1 个数据点，这意味着每个“segmentby”组是 7 个项目，因此您可能会从我们用作压缩的一部分的各种数组类型中获得更多开销，而不是可压缩性本身。我们通常建议每个块每个不同的分段项至少 100 行。 TimescaleDB 与 Postgres 的额外开销也可能如此。

【解决方案2】：

尝试将数据存储在其他时间序列数据库中，例如 InfluxDB 或VictoriaMetrics（我是 VictoriaMetrics 的核心开发人员）。根据benchmarks，它们可能提供比 TimescaleDB 更好的磁盘压缩。

【讨论】：