共享记录的 Cassandra 设计模式 (m :n)

Question

我们有两个实体用户和角色。一个用户可以有多个角色，多个用户可以共享一个角色 -典型的 m:n 关系。角色也是动态的，我们预计数量很大(数百万)。

在关系数据库中对此类数据建模非常简单。我想知道在 cassandra 中什么时候有可能。

目前我看到两种解决方案:

A) 使用规范化模型并创建类似于 inner-join 的东西

在单独的 CF 中创建每个单独的角色，并在用户记录中存储引用角色的外键。

亲:角色不会被复制，维护简单

相反:为了获得单个用户的所有角色，需要多次网络调用。用户记录仅包含 FK，存储角色使用随机分区器，在这种情况下，每个角色都可以存储在不同的 cassandra 节点上。

B) 非规范化模型并复制角色以避免往返在这种情况下，cassandra 中的用户记录包含所有用户角色作为副本。

优点:可以在单个查询中读取具有所有角色的用户。这保证了较短的加载时间。

相反:每个共享角色都被复制多次 - 在每个相关用户上。维护角色非常困难，特别是如果我们有 数据量大。例如:一个 Role 由 1000 个用户共享。此角色的更改需要更新 1000 条用户记录。 对于非常大的数据集，此类更新必须作为异步作业执行。

上面的解决方案非常有限，meybie Cassandra 不是 m:n 关系的正确解决方案？您知道针对此类问题的任何 cassandra 设计模式吗？

谢谢，马切伊

Answer 1

在 Cassandra 中设计数据存储的方式是 start with the queries you plan to execute并做到这一点，这样您就可以立即获得所需的所有信息。非规范化是这里的游戏名称；如果您不在每个用户节点中复制该角色信息，您将无法避免磁盘寻道，并且您的读取性能将会受到影响。加入没有意义；如果您想要关系数据库，请使用关系数据库。

据推测，您会问很多关于用户拥有哪些角色以及他们应该用这些角色做什么的问题，因此您肯定希望在每个用户条目中复制角色信息 - 可能是每个角色获取自己的列(role-ROLE_KEY => serialized-capability-info 而不是 roles => [序列化的能力信息数组])。您的应用程序将需要某种方式来迭代所有这些列本身。

您可能想查看某个角色中有哪些用户，因此您可能也应该将该 View 所需的所有用户信息存储在角色列族中(尽管是完整用户记录的一个子集)会做的)。

当您运行更新并从角色中添加/删除用户时，您需要确保同时更新角色的用户列表和用户的角色。因为您为每个关系使用一个列，而不是单个共享的序列化 blob，所以即使您正在编辑同时共享同一用户的两个不同角色，这也应该有效:Cassandra 可以合并更新，包括删除.

如果查询需要异步，则让您的应用程序处理它。请记住，Cassandra 是一个最终一致性数据存储，您不应该期望更新随处可见。