TimescaleDB和压缩的复杂场景

Question

我们有一个具有相当大数据集(> 1.5TB，>1B行)的timescaleDB。

这个项目一直在一个又一个的延迟中运行，因为我们无法使所需的查询执行得足够快(对许多行进行大规模扫描以找到特定的条件，等等)。

最近，我们开始对压缩进行实验，并发现它对性能有相当大的影响，但我们一直在碰壁。

我们记录的金融交易，在核心，交易有一个时间戳，符号正在交易和各种其他信息。

大约有140个不同的符号，每个符号彼此独立运行。他们彼此不了解。

所有事务都在一个表中结束。我们不能有多个表，因为有些查询要求同时访问不同的符号。

这些块有一天长，我们一下子就写了整整一天。

由于我们分别处理符号，有时符号A可能是第2天，而符号B则是第5天。

在启用压缩之前，此操作非常好：

每个块表示所有符号中的一天，因此如果一个块在尚未写入的情况下被压缩，则写入操作将失败。

我们不能手动“关闭”一天/块，因为某些符号的数据可能会在几天后到达，或者有些天可能是空的，因此无法确定一天是否关闭。

所以我的问题是:我们如何才能将事物分割，知道：

• 我们想要使用压缩。
• 我们需要访问单个查询中的所有符号，所以我们不能有很多表。
• 我们无法确定符号的每日数据何时到达；符号之间有3-4天的差异并不少见。

如果我们可以在每个时间戳和每个符号中创建一个块，它就能工作，但是我还没有发现任何迹象表明这是可能的。

编辑：

我已经尝试过对超级表进行分区，但这并没有提供预期的结果。

让我们用一条线：

• 它得到实时数据，当它出现时，这些数据就会被写入。
• 它以24小时为单位获得权威数据。它是连续的(按顺序到达)，可能有点旧(有时需要几天才能得到更新)，但是它必须替换表中的任何内容，因为它优先于其他数据。在将这一天插入数据库之前，它将删除有关的一整天，这一天可以从实时数据中填充。
• 我已经设置了压缩集，这样它就不会压缩最后3天的数据，但是所有的数据都会变老。

因此，从理论上讲，我正在编写实时数据，信任数据在24小时内到达，有时几天后就会覆盖所有的数据。这些块可以被压缩。

现在，大约有140个这样的线程，每个线程代表一个符号，而符号A可能在第5天，符号B可以在第3天，因为这些代码块代表一天，所以我只能压缩天0、1和2。

我希望和：

SELECT create_hypertable(
    'exchange.{tableName}',
    'ts',
    partitioning_column => 'ticker',
    number_partitions => 150,
    create_default_indexes => false,
    chunk_time_interval => INTERVAL '1 day',
    if_not_exists => TRUE);

每天创建一个符号('ticker')。所以符号A可以有自己的压缩，符号B可以有自己的压缩，因为每个符号都有自己的块/天，我不需要看最滞后的符号来决定压缩停止的地方。

但情况似乎并非如此。

有什么解决办法吗？

Answer 1

时间尺度压缩文档包含信息、如何手动解压缩块和“未来工作”部分(在底部)表明未来版本可能能够自动插入旧数据。

同时，您可能希望选择有意义的压缩持续时间:例如，当您期望大多数数据在4天内到达时，压缩大于5天的数据)。

当一些晚到的数据到达时，将其写入一个单独的表(具有相同的结构)。由于这是例外情况，该表将只包含很少的数据，因此您甚至不需要超表。

当查询数据时，现在必须将两个表的数据组合起来，以获得所需的结果。