Cassandra 许多表与大量辅助键查找

Question

我需要将帖子存储在社区中，每个帖子都有 cmets。

-假设我只不频繁地重新生成包含 cmets 的帖子页面，起初是每天每小时一次，然后是每月或每年一次。这意味着阅读并不频繁，但当我阅读时，我可能会同时执行数千次阅读以重新生成页面。

哪种策略是正确的？ (1) 每个帖子都有一个包含所有 cmets 的表，这意味着如果我获得数百万个帖子，我可能在一个键空间中拥有数百万个表。但是所有的 cmets 都可以轻松查询和排序。

(2) 为所有帖子设置一个表格，为所有 cmets 设置另一个表格。如果我需要查找数千个 cmets 来生成帖子页面，我将不得不使用辅助键来表示评论链接到哪个帖子似乎很慢。这种较慢的性能可能还可以，因为我使用的是定期重新生成的静态页面系统。

我希望 (2) 是正确的“Cassandra”方式，但如果每个表的开销不是太高或者只有在帖子需要时才可以加载到内存中，那么 (1) 似乎很诱人重新生成。

编辑： 在与 Cassandra Slack 中的人聊天后，由于内存开销，似乎我唯一的选择是（2）。所以我现在的问题是：

如果我有 10 亿个 cmets，每个帖子 10,000 个，我需要在 10 亿个 cmets 的大海捞针中找到那 10,000 个，这是否可行？

Answer 1

您应该为所有帖子提供一个表格，并为每个帖子的 cmets 提供另一个表格。

comments_by_posts
   post_id   uuid
   comment_id   uuid
   comment   text
   .....
   primary key ((post_id), comment_id)

post_id 将是您的分区键，comment_id 将是您的集群键。它们一起将成为您表的主键。

由于 post_id 是您的分区键，读取将基于 post_id 并按您的 comment_id 排序。为一个帖子找到 10000 cmets 仍然非常容易和快速。因为它们将在同一个分区中。