0

背景

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

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

问题

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

问题

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

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

  1. 使用额外的类似索引的表跟踪 Cassandra 中的关系：candidates_by_supporting_company. 更新公司时，我们也会更新拥有该公司的候选人。
  2. 与 1 类似，但如果关系低肉质并基于二级索引进行更新，则使用二级索引（我们有 10 个政党，因此我们可以将索引放在候选人表中的政党上，当政党发生变化时，我们可以按政党更改候选人，因为我们有索引）
  3. 对关系类型的数据使用关系数据库，让 Cassandra 只处理合适的用例，如时间序列数据、消息传递、事件排序（这会增加一个数据库的维护成本、部署成本和问题，因为我们的系统是分布式的有数据复制）
  4. 使用 Spark 进行连接（这将不是将 Spark 添加到系统的唯一目的，我们正在考虑添加它以导入 CSV 中的大量数据集并进行转换，因此拥有 Spark 将是一个额外的好处，我们可以使用 SparkSQL我们需要加入的地方）

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

你怎么看？

4

1 回答 1

1

如果您只想使用 cassandra，正确的方法是数字 1：非规范化。但是如果你有很多关系，它会在应用程序层面带来很多努力。如果在您的环境中添加其他 dbms 不是问题，那么使用正确的工具来完成正确的工作是最佳选择：对我来说是 3

于 2015-09-13T22:34:00.780 回答