在Cassandra中处理关系模型

Question

出身背景

我们选择Cassandra作为我们的存储引擎，因为我们有一个应用程序，必须处理网站上许多用户之间的异步消息传递和事件存储（某些类型的分析，现场发生的事情以及何时发生等）。此外，我们有一个投票平台，所以我们每天为每个用户存储投票，Cassandra在这些用例中很好。

最近，我们有了在现有系统之上构建关系模型的新需求（至少我们认为它是关系的）。一些类型的政治候选人有工作、教育、历史投票、支持等名单。

问题

我们有可以在两端编辑的关系（即候选人由公司支持，但在我们的管理面板中，该公司可以在没有候选人的情况下进行编辑）。候选项是我们的卡桑德拉数据库中由 UUID 标识的一行。在前端，我们需要有关候选人的完整信息（政党，学校，工作，投票历史，支持公司）。我们希望将大部分候选信息放在一行中，以便我们可以通过一次读取来读取数据。但是，当我们放置支持公司UDT列表时，我们在编辑它时遇到问题（我们需要在company_by_id中更改它，candidate_by_id表）。

问题

在我们的情况下，如何解决编辑问题和关系模型问题？

我们想出了几个解决方案：

< li >在Cassandra中使用类似索引的附加表格跟踪关系:< code > candidates _ by _ supporting _ company 。更新公司时，我们也会更新拥有该公司的候选人。 < li >类似于1，但是如果关系是低关系，则使用二级索引，并基于二级索引进行更新(我们有10个政党，因此我们可以将索引放在候选人表中的政党上，当政党发生变化时，我们可以根据政党改变候选人，因为我们有索引) < li >对关系类型的数据使用关系数据库，让Cassandra只处理合适的用例，如时间序列数据、消息传递、事件排序(这增加了多一个数据库的维护成本、部署成本和问题，因为我们的系统是分布式的，如何复制数据) < li >使用Spark进行连接(这不是向系统添加Spark的唯一目的，我们正在考虑添加Spark以导入CSV中的大量数据集并进行转换，因此使用Spark将是一个额外的好处，我们可以在需要连接的地方使用Spark SQL)

我们倾向于选择3，因为我们无论如何都会添加Spark，我们将只保留Cassandra数据库（这不会使维护和部署另一个数据库复杂化），并且我们可以在应用程序级别上获得某种JOINS和GROUP BY。

你觉得怎么样？

Answer 1

如果你只想使用cassandra，正确的方法是第一步:反规格化。但是如果你有很多关系，这将会在应用层面带来很多努力。如果在您的环境中添加另一个dbms不成问题，那么为正确的工作使用正确的工具是最好的选择:对我来说是第三个选择