join - Cassandra 非规范化数据模型

Question

我读到，在 nosql(例如 cassandra)中，数据通常以非规范化方式存储。例如看这个 SO答案或这个website .

例如，如果您有员工和部门的列族并且您想要执行查询:select * from Emps where Birthdate = '25/04/1975' 然后你必须创建一个列 family birthday_Emps 并将每个员工的 ID 存储为一个列。因此，您可以在 birthday_Emps 家族中查询键“25/04/1975”，并立即获取该日期出生的员工的所有 ID。您甚至可以将员工详细信息非规范化为 birthday_Emps，这样您也可以立即获得员工姓名。

真的是这样吗？

1. 每当删除或插入员工时，您也必须从 birthday_Emps 中删除该员工。在另一个例子中，有人甚至说有时你会遇到这样一种情况，即某个表中的一个删除需要其他表中的 100 次删除。这真的很常见吗？

2. 在应用程序代码中进行连接是否很常见？您是否拥有允许您创建预写应用程序以将来自不同查询的数据连接在一起的软件？

3. 是否有处理这些数据模型问题的最佳实践、模式等？

Answer 1

在大多数情况下"is"，采用基于查询的数据建模方法确实是最好的方法。

1. 这仍然是一个好主意，因为查询时间的速度使它值得。是的，还有一些清洁工作要做。我不必从其他列族执行 100 次删除，但偶尔需要进行一些复杂的清理工作。但是，无论如何，您都不应该在 Cassandra 中执行大量删除操作(反模式)。

2. 没有。客户端 JOIN 与分布式 JOIN 一样糟糕。整个想法是创建一个表来为每个特定查询返回数据……非规范化和/或复制……从而完全不需要进行 JOIN。异常(exception)情况是，如果您正在运行 OLAP 查询进行分析，则可以使用 Apache Spark 等工具来执行临时的分布式 JOIN。但这绝对不是您想要在生产系统上执行的操作。

3. 我可以推荐几篇文章:

   • Getting Started with Cassandra Time Series Data Modeling - 它由 DataStax 的首席传播者 Patrick McFadin 撰写，以几种不同的方式涵盖了一种更常见的 Cassandra 用例。
   • Escaping From Disco-Era Data Modeling - 这一篇讨论了 Cassandra 初学者可能面临的一些障碍，以及克服这些障碍的一般方法。 免责声明:我是作者。
   • Cassandra Data Modeling Best Practices, Part 1 - Jay Patel (eBay) 关于 Cassandra 建模实践的经典文章绝对不会出错。这些示例基于 CQL 之前的世界，但这些技术仍然引起共鸣，这有点过时了。