我在 cassandra 数据库中有一个数据集，其中每个记录必须每月处理一次（基本上是每月订阅）。进程每天运行，因此数据分为 31 个块，每天处理。我正在尝试设计一个分区键以避免过滤所有数据集。
第一个解决方案是分配一个基于一个月中某天的分区键。这意味着我每天可以处理固定数量的分区 (31)。但问题是数据大小会随着时间的推移而增加，但分区数将保持不变，我可能会因为行太宽而遇到性能问题。
其他解决方案是根本不处理这个问题，每天使用 apache spark 处理所有表（基本上使用 spark 过滤选择 1/31 的数据）。随着时间的推移，数据会增加，但集群中的节点也会增加，我可能会有一个恒定的性能。但所有建议都反对 cassandara 中的数据过滤。
在这种情况下理论上可能拥有的最大行数约为 10 亿。
会有什么建议？
正如您所怀疑的那样，计划只有 31 个分区对于性能来说是一个非常糟糕的主意。主要问题是数据库无法扩展：当 RF=3 时，最多（在不太可能的最佳条件下）93 个节点有任何数据，因此您无法扩展到更大的集群。使用 Scylla（按核心进一步划分数据），您将无法将集群扩展到超过 93 个核心。第二个问题是 Cassandra 没有非常有效的索引来读取巨大的分区，当单个分区变得很大时，读取变得更慢。
折衷方案可能是不仅使用 31 个分区，而是使用 31*K 对于某些 KEg，可能每小时有一个分区，而不是每天。或每天 100 个分区。您需要找到一种方法来始终如一地确定哪些记录属于这些分区中的哪个，但我想您已经有了一个（目前它将记录分配给 31 个分区 - 您需要更改的只是将其分配给 31*K 分区）。这只是意味着您每天都需要扫描一个分区，而不是 K 个单独的分区 - 但这很简单。
最后，由于数字“31”相对较小，您可以选择使用 31 个单独的表。这将允许您分别扫描每个表。我不知道您需要执行哪些其他查询，但如果这些查询不需要跨越表边界，则拆分为 31 个表是一种合理的方法。