了解 Cassandra - 它可以取代 RDBMS 吗？ [关闭]

Question

上周我一直在死记硬背 Cassandra，试图了解基础知识，以及它是否符合我们的需求。我想我在这一点上基本了解它，但如果它像我相信我被告知的那样有效......我就是不知道它是否合适。

我们有一个微服务平台，它本质上是我们客户之间的大型数据总线。他们使用一组 API 来推送和拉取共享数据。到目前为止，过滤非常简单......但没有办法知道未来会带来什么。

在这个平台之上是一个分析层，其中包含基于传递的数据的多个可视化（条形图、图表等）。

微服务平台是在 MySQL 之上构建的，我们可以使用集群的想法，老实说，我们没有太多运气。最重要的是，变化是痛苦的，就像 RDBMS 世界的课程一样。此外，我们预计有成千上万的并发用户会产生大量数据 - 看来我们将不可避免地遇到扩展问题。

因此，我们开始将 Cassandra 视为分布式 nosql 的潜在替代品。

我观看了 DataStax 视频，参加了另一个网站上的课程，然后开始深入研究。我发现的是：

• 数据以冗余方式存储在多个表中，每个表都使用不同的主键和集群键，以支持不同类型的查询，因为行分散在集群中的不同节点中
• 与其不支持加入，不如非规范化并创建包含大量列的“宽”表
• 数据最终是一致的，因此新写入可能无法在可预测的合理时间内轻松读取。
• CQL 虽然类似于 SQL，但主要是谎言。您存储和关键数据的方式决定了您可以使用哪些类型的查询。它似乎非常有限且不灵活。

虽然这些概念对我来说很有意义，但我很难看出这将如何满足大多数长期数据库需求。如果数据在几个不同的表中是冗余的......如何在这些表中管理和保持一致？在这种情况下，物化视图是答案吗？

我想要喜欢这个想法并喜欢分布式功能，但坦率地说，在这一点上大部分时间都被吓跑了。在过去的一周里，我感觉自己学到了很多东西，却一无所获，完全不知道该怎么做。

我研究了 JanusGraph、Elassandra 等，看看它是否会在 Cassandra 之上提供一个更简单的接口，将其降级为基本上是一个存储引擎，但我不确定这些东西中的许多是否足够成熟甚至合适，因为我们需要什么。

我想我正在寻找那些使用 Cassandra 构建东西的人的方向和见解，看看它是否适合我们正在做的事情。不幸的是，我没有时间进行研发。谢谢！

Answer 1

了解 Cassandra - 它可以替代 RDBMS 吗？

这里的简短回答是“不”。当您突然需要扩展时，Cassandra 并不是 RDBMS 的简单替代品。

虽然这些概念对我来说很有意义，但我很难看出这将如何满足大多数长期数据库需求。

它适合长期的数据库需求如果您将其应用于正确的用例。

免责声明：我是有点卡桑德拉狂热者。我已经使用了一段时间，为该项目做出了一些贡献，被命名为“Cassandra MVP”，甚至与人合着了一本关于它的书。我认为这是一项伟大的技术，你可以用它做出惊人的事情。

话虽如此，有很多事情它只是不擅长：

• 查询灵活性。您为在多个节点上分布行以满足运营规模所做的权衡是，您必须提前了解您的查询模式，然后严格遵循它们。这个想法是，您希望所有查询都由单个节点提供服务。你必须在你的数据模型中投入一些想法来实现这一点。未绑定的查询（SELECTs 没有 WHERE 子句）成为敌人。

• 就地更新数据。计划通过键存储值，但随后对其进行大量更新（例如：状态）？ Cassandra 不适合这种情况。这是因为 Cassandra 有一个基于日志的存储引擎，它不会覆盖任何内容……它只是废弃它。所以你以前的值仍然存在，并且仍然占用空间和计算资源。

• 删除数据。在分布式数据库世界中删除数据很棘手。毕竟，您如何将 nothing 复制到另一个节点？ Cassandra 对这个问题的回答是使用称为墓碑 的结构。墓碑占用空间，可能会降低性能，并且需要保持足够长的时间才能复制（使得移除它们很棘手）。

• 维护数据一致性。由于具有高可用性和分区容错性，Cassandra 采用了“最终一致性”的概念。所以毫不奇怪，它真的不是为了保持一致而设计的。它有许多帮助保持数据一致的机制，但它们远非完美。另外，确实没有办法确定您的数据是否同步。

如果数据在多个不同的表中是冗余的...如何管理并在这些表中保持一致？在这种情况下，物化视图是答案吗？

在可预见的未来，我将继续远离物化视图。它们是“实验性的”是有原因的。基本上，一旦它们不同步，让它们重新同步的唯一方法就是重建它们。

我指导我的开发团队保持他们的查询表（包含相同数据，只是键不同的表）与BATCH 语句同步。事实上，BATCH 是用词不当，因为它可能应该被命名为“ATOMIC”。由于它的名字，它被严重误用，误用会导致问题。但是，它确实保持以原子方式应用突变，因此确实有帮助。

基本上，仔细检查您的数据库要求。如果 Cassandra 没有削减它，那么试着找到一个能做到的。 CockroachDB（或其他 NewSQL 之一）可能更适合您正在谈论的内容。它试图成为 Postgres 的插件，并且可以通过一些类似 Cassandra 的机制进行扩展，因此可能值得研究。

Answer 2

Cassandra 非常擅长它的工作，但它不是 RDBMS 的直接替代品。如果您发现需要以下任何一项，我不鼓励您迁移到 Cassandra：

• 严格的一致性
• ACID 交易
• 支持即席查询，包括连接、聚合等。

现在关于你使用 MySQL 达到了一些限制（或者认为你将来会达到它们），这里有一些想法：

• 不要认为 MySQL 中的限制通常是 RDBMS 中的限制。只是为了让您不要认为我是 $some_other_DB 狂热者，我已经使用 MySQL 将近 20 年了，但它并不是所有工作的最佳工具。
• 如果您所说的“更改”是指“架构更改”，则可以通过以下任一方法减轻很多痛苦：
  • 使用实现更好的 RDBMS（可能包括更新的 MySQL 版本）
  • 使用社区支持的工具，例如 pt-online-schema-change 或 gh-ost

祝你好运！