为什么MongoDB一致性不可用而且Cassandra可用性不一致？

Question

蒙戈

从此resource我理解为什么mongo不是A(Highly Available)基于以下声明

  

MongoDB支持“单一主”模型。这意味着你有一个主人   节点和许多从节点。如果主人失败，其中一个   奴隶当选为主人。此过程自动发生   但这需要时间，通常是10-40秒。在这个新的时间   领导者选举，你的副本集已关闭，无法写入

是否出于同样的原因，Mongo被称为Consistent（因为写入没有发生，所以返回系统中的最新数据）但不是Available（不可用于写入）？

直到重新选举发生并且写入操作处于挂起状态，可以从属返回执行读取操作吗？一旦选择了master，用户是否也会重新启动写操作？

但我从另一个角度不明白为什么Mongo是highly consistent 正如Where does mongodb stand in the CAP theorem?所述，

  

当默认情况下所有读取都转到主数据库时，Mongo为consistent。

但事实并非如此。如果在主/从模型下，所有读取将转到主要的奴隶的使用是什么呢？它进一步说If you optionally enable reading from the secondaries then MongoDB becomes eventually consistent where it's possible to read out-of-date results.这意味着mongo可能不是 与master / slaves一致（假设我在返回之前没有配置写入所有节点）。如果所有人都认为mongo是一致的，那对我来说没有意义 读取和写入转到主要。在那种情况下，每个其他DB也（如cassandra）将是一致的。不是吗？

卡桑德拉 从resource我理解为什么Cassandra是A(Highly Available )基于以下陈述

  

Cassandra支持“多主”模型。失去一个单一的   node不会影响集群写入的能力 - 所以   你可以实现100％的写入正常运行时间

但我不明白为什么cassandra不是Consistent？是因为节点不可用于写入（因为协调节点无法连接）可用于读取，这可以返回过时数据吗？

Answer 1

CAP范式的一致性还包括＆＃34;最终的一致性＆＃34;哪个MongoDB支持。与ACID系统相比，CAP系统中的读取不保证安全返回。

简单来说，这意味着您的主人可以拥有更新的值，但如果您从Slave读取，则不一定会返回更新的值，并且没有更新的值可以通过设计。

最终一致性的概念在一个很好的答案中解释here。

通过建筑，Cassandra应该是一致的;它提供了最终一致性的特殊实现，称为“可调谐一致性”。这意味着客户端应用程序可以选择处理此方法 - 它甚至提供低级别的多数据中心一致性支持！ Cassandra中逐行不一致的大多数问题来自于Cassandra使用客户端时间戳来确定哪个值是最新值，而不是服务器端值，这一点可能有点令人困惑。

我希望这有帮助！

Answer 2

Consistency和availability的简要定义。

一致性仅表示在系统/分布式系统中写入数据时，从系统的任何节点读取数据时应获得的数据相同。

可用性意味着系统应该始终可用于读/写操作。

注意：大多数系统不可用，仅可用或仅一致，它们总是提供两者的一部分

使用上面的定义，让我们看看MongoDB和Cassandra属于CAP的位置。

MongoDB

正如您所说的，当读写到同一节点时，MongoDB为highly consistent（默认情况）。此外，您可以在MongoDB中选择从其他辅助节点读取，而不是仅从leader / primary读取。

现在，当您尝试从辅助数据库读取数据时，一致性将完全取决于您要如何读取数据：

• 您可以查询最多5秒钟的数据，或者，
• 您可以说，从majority的节点返回数据以用于select语句。

从客户端向Mongo Leader写入数据时，可以说，如果将数据复制到或存储在服务器majority上，则写入成功。

很明显，从上面我们可以说，MongoDb可以是高度一致的，或者最终取决于您读取/写入数据的方式。

现在，可用性如何？ MongoDB通常总是可用的，但是，只有当领导者倒下时，MongoDB才能接受写操作，直到找出新的领导者为止。因此，不是highly available

任何基于领导者的系统都可用，但highly available不可用。
因此，MongoDB归类为CP。

那卡桑德拉怎么样？

在Cassandra中，没有领导者并且节点可以接受写操作，因此，即使某些节点出现故障，Cassandra群集也始终可以进行写操作，并且显然可以读取。

Cassandra中的一致性如何？ 与MongoDB相同，Cassandra最终可以根据您读/写数据的方式保持一致或高度一致。

您可以在读/写操作中提供一致性级别，例如：

• 从一个节点读取/写入数据
• 从多数/法定节点等中读取/写入数据

比方说，您在读/写操作中给出的一致性级别为1。因此，一旦将数据写入一个节点/副本，您的写入便会成功。现在，假设您从尚未更新数据的另一个副本/节点读取数据并读取旧数据（可能是由于高网络延迟或任何其他原因）。

但是最终，即使第二个节点也将获得更新的新数据。因此，在使用一致性级别highly consistent时不会使用one。

因此，Cassandra的可用性很高，但是具有可配置的一致性级别，因此并不总是一致的。

Answer 3

您只需要了解“时间点”：由于您仅写入mongodb master，所以即使未更新slave，它也是一致的，因为它具有通过同步力矩生成的所有数据。

对于卡桑德拉来说，事实并非如此。由于cassandra使用的是无主控模型，因此毫无疑问其他节点拥有所有数据。在某个时间，节点可以具有某些最新数据，并且没有来自尚未同步的节点的较旧数据。仅当您停止写入所有节点并将其置于联机状态时，Cassandra才会保持一致。同步完成后，您将获得一致的数据。