提供此查询的 cassandra 模式可能是什么？答案

【问题标题】：What could be cassandra schema to serve this query?提供此查询的 cassandra 模式可能是什么？
【发布时间】：2011-06-03 14:42:43
【问题描述】：

假设一个社交应用程序拥有数百万用户并且有大约 200-300 个主题，用户可以发布最多可以标记 5 个主题的帖子。我对此数据有两种查询：

查找某个用户的帖子
查找标记为特定主题的所有最新帖子。

对于第一个查询，我可以使用 User Columnfamily 中的 superColumns 轻松创建架构（在这个超级列中，我可以将用户所有帖子的 postIds 存储为列）。

我的问题是我应该如何设计架构以在 Cassandra 中提供第二个查询？

【问题讨论】：

标签： database database-design schema nosql cassandra

【解决方案1】：

虽然Justice 的回答可行，但我不喜欢它，因为它需要OrderPreservingPartitioner 来执行范围扫描。 OPP有很多与之相关的问题。详情见我linking to constantly的文章。

相反，我会推荐这个：

topic|YYMMDDHH: {TimeUUID: postID, TimeUUID: postID, etc... }

其中 "topic|YYMMDDHH" 是行键，每列名称是 TimeUUID，列值是 postID。

要获取任何主题的最新帖子，您可以从该主题的最新行末尾获取一个切片。如果该行没有足够的列，则及时转到上一列，等等。

这有一些不错的属性。首先，如果您不关心某个主题的真正旧帖子，只关心相对较新的帖子，您可以定期清除旧行并为自己节省一些空间；这甚至可以通过列 TTL 来完成，这样您就不必做任何额外的工作。其次，您的行的大小将受到限制，因为它们每小时都会被拆分。第三，你不需要 OPP :)

这样做的一个缺点是，如果有一个非常热门的话题，一个节点可能会在一个小时内收到比其他节点更高的流量。

【讨论】：

是的，缺点是一个问题，因此我在采用这种方法时犹豫不决。拥有几百个热点行真的很糟糕吗？遵循这种方法除了未分布的负载（如果更多）之外还有什么其他缺点。（我认为这很好，因为这些有限的行可以很容易地缓存在内存中，并且单个查询很容易获取整个数据所需的数据）。由于我不希望每小时发布太多帖子，因此我更愿意将其按天存储，从而更容易获取帖子。
不，几百个热行还不错：在这种情况下，您的所有节点都会很忙。例如，如果您只有 2 个非常热的行，那么一两个节点的工作负载将高于平均水平。您对缓存是正确的；这实际上是我错过的一个很好的优势。一个小的行缓存非常适合这种情况，尽管如果使用行缓存，我更愿意按小时而不是天来分割，以降低潜在的大小。（实际上，我认为按小时划分更好。）
谢谢 Tyler.... 但关于拆分..如果每小时添加的列数非常少，那么无论如何都需要几行，这意味着更多的行搜索（我认为更多的行搜索意味着比在同一行内查看更贵！？？如果我错了，请纠正我..）因此，您不认为拆分频率的正确答案取决于每小时/每天添加的列数吗？
如果您希望每个主题每小时只有 0 到 10 个帖子，我想这是真的；尽量减少搜索次数总是一个好主意。另外，如果需要，您可以随时从按天拆分切换到按小时拆分。

【解决方案2】：

对于第二个查询，构建一个二级索引列族，其键为#{topic}:#{unix_timestamp}。行将有一个带有帖子 ID 的列。然后您可以进行范围扫描。

【讨论】：