共享记录的Cassandra设计模式（m:n）

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

在关系数据库中对此类数据建模非常简单。我想在卡桑德拉尽可能找到答案

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

A）使用规范化模型并创建类似于内部联接的内容

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

优点：角色不可复制，维护简单

相反：为了获得单用户的所有角色，需要多个网络呼叫。用户记录仅包含FK，存储角色 使用random partitioner，在这种情况下，每个角色都可以存储在不同的cassandra节点上

B）取消模型规范化并复制角色以避免往返 在这个场景中，cassandra中的用户记录包含所有作为副本的用户角色

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

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

上述解决方案非常有限，meybie Cassandra不是m:n关系的正确解决方案？你知道卡桑德拉的设计模式吗

谢谢，

---

Maciej

在Cassandra中设计数据存储的方法是：设计并制作数据存储，以便一次获得所需的所有信息。非规范化是这里的游戏名称；如果您不在每个用户节点中复制该角色信息，您将无法避免磁盘搜索，并且您的读取性能将受到影响。连接没有意义；如果需要关系数据库，请使用关系数据库

猜测一下，你会问很多关于用户有哪些角色以及他们应该做什么的问题，因此你肯定希望在每个用户条目中复制角色信息-可能每个角色都有自己的列（

role-role\u KEY=>serialized capability info

而不是

roles=>[功能信息的序列化数组]

）。您的应用程序需要某种方法来迭代所有这些列本身

您可能希望查看角色中的用户，因此您可能还应该将该视图所需的所有用户信息存储在角色列族中（尽管完整用户记录的子集也可以）

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

---

如果查询需要异步，那么让应用程序处理它。记住Cassandra是一个最终的一致性数据存储，您不应该期望任何地方都能立即看到更新。

现在的另一个选择是使用playORM，它可以为您进行连接；）。您只需决定如何对数据进行分区。它使用Scalabla JQL，这是对JQL的一个简单添加，如下所示

@NoSqlQuery（name=“findjoinnullpartition”，query=“PARTITIONS t（'account'，：partId）从Trade中选择t作为t内部连接t.security作为s，其中s.securityType=：type和t.numShares=：shares”）

因此，我们最终可以在noSQL系统上对数据进行规范化，并同时进行扩展。我们不需要放弃有一定好处的规范化

---

Dean

Cassandra最终可能是一致的，但不一定是一致的。更好的描述是，它具有基于复制因子和读写一致性级别的可调一致性（）谢谢你的回答！-我期待着。在我的情况下，维护这样的角色将是痛苦的-特别是当我需要更新这样的角色时，它正被数百万用户共享…但我看不到其他选择