时间序列的 Cassandra 表压缩答案

【问题标题】：Cassandra Table Compaction for timeseries时间序列的 Cassandra 表压缩
【发布时间】：2021-11-27 13:57:05
【问题描述】：

我的程序生成大量时间序列数据到下表中：

CREATE TABLE AccountData
(
    PartitionKey text,
    RowKey text,
    AccountId uuid,
    UnitId uuid,
    ContractId uuid,
    Id uuid,
    LocationId uuid,
    ValuesJson text,
    PRIMARY KEY (PartitionKey, RowKey)
)
WITH CLUSTERING ORDER BY (RowKey ASC)

PartitionKey 是一个字典值（10 之一），RowKey 是 DateTime 转换为 long。

现在由于程序正在生成大量数据，每个ContractId 在代码中都有不同的保留策略。代码会根据特定 ContractId 的保留时间删除旧数据。

我现在遇到的问题是，在 SELECT 语句期间它拾取了太多的 Tombstones 并且我收到了一个错误。

我应该使用什么 Table Compaction 策略来解决这个 Tombstone 问题？

【问题讨论】：

标签： database cassandra

【解决方案1】：

PartitionKey 是一个字典值（10 个之一）

我认为这可能是您的问题。基本上，集群中的所有数据都以 10 个分区结束。随着时间的推移，这些将变得非常大。通常，您希望将分区大小保持在 1MB-10MB 之间。越低越好。

我建议拆分分区。如果它与时间相关，请采用对您的查询模式最有意义的时间单位。例如，如果大多数查询是基于月份的，也许这样的事情可能会起作用：

PRIMARY KEY ((month,PartitionKey),RowKey)

这将为month 和当前PartitionKey 的每个组合创建一个分区。

同样，大多数时间序列用例倾向于更频繁地查询最新数据。为此，通常按时间以descending 的顺序对分区中的数据进行排序是有意义的。当然，如果RowKey 确实是一个数据/时间值。

WITH CLUSTERING ORDER BY (RowKey DESC)

此外，这个模型的一个很好的小副作用是，任何被墓碑化的旧数据现在都位于分区的“底部”。因此，根据删除模式，墓碑仍然存在。但是，如果数据按降序排列...墓碑永远不会/很少查询。

我应该使用什么 Table Compaction 策略来解决这个 Tombstone 问题？

所以我不相信简单地改变压缩策略会是解决这个问题的灵丹妙药。话虽如此，我建议查看TimeWindowCompactionStrategy。该压缩策略按指定的时间段（窗口）存储其 SSTable 文件。这可以防止查询充满旧数据、过时数据或墓碑数据的文件。

【讨论】：