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