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