为什么MongoDB的“一致性”不可用而Cassandra的“可用”不一致？

本文介绍了为什么MongoDB的“一致性”不可用而Cassandra的“可用”不一致？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 Mongo 来自此资源我理解基于以下陈述，为什么mongo不是 A（高可用性） From this resource I understand why mongo is not A(Highly Available) based on below statement出于同样的原因吗据说Mongo是稳定的（因为未发生写入操作，所以返回了系统中的最新数据），但不是可用的（不可写）？ Is it for the same reason Mongo is said to be Consistent(as write did not happen so returning the latest data in system ) but not Available(not available for writes) ? 直到重选发生并且写操作处于挂起状态，从属返回可以执行读操作吗？一旦选择了主服务器，用户还会再次重新启动写入操作吗？Till re-election happens and write operation is in pending, can slave return perform the read operation ? Also does user re-initiate the write operation again once master is selected ? 但是我从另一个角度不理解，为什么Mongo是高度一致 如 mongodb在CAP定理中位于什么位置？，But i do not understand from another angle why Mongo is highly consistentAs said on Where does mongodb stand in the CAP theorem?, 但这不是事实。如果在主/从模式下，所有读取都将变为主模式，那么从设备的用途是什么？进一步说，如果您有选择地启用从辅助读取，则MongoDB最终将在可能读取过期结果的地方保持一致。这意味着mongo可能不是与主/从服务器一致（前提是我未配置在返回之前未写入所有节点）。对于我来说，如果所有的读和写都去了主要对象，那么说mongo是一致的就没有意义。在这种情况下，其他所有DB（例如cassandra）也将保持一致。不是吗？But that is not true. If under Master/slave model , all reads will go to primary what is the use of slaves then ? It further says If you optionally enable reading from the secondaries then MongoDB becomes eventually consistent where it's possible to read out-of-date results. It means mongo may not be be consistent with master/slaves(provided i do not configure write to all nodes before return). It does not makes sense to me to say mongo is consistent if allread and writes go to primary. In that case every other DB also(like cassandra) will be consistent . Is n't it ? 卡桑德拉 来自此资源我理解，基于以下声明，为什么Cassandra是 A（高度可用） CassandraFrom this resource I understand why Cassandra is A(Highly Available ) based on below statement 但是我不明白，为什么cassandra不是一致？是因为节点不可用于写操作（因为协调节点无法连接）可用于读取并返回陈旧数据？But I do not understand why cassandra is not Consistent ? Is it because node not available for write(as coordinated node is not able to connect) is available for read which can return stale data ?推荐答案查看以下内容： CAP中的MongoDB，Cassandra和RDBMS ，以便更好地理解该主题。Go through: MongoDB, Cassandra, and RDBMS in CAP, for better understanding of the topic. 一致性和可用性。 一致性 >只是意味着，当您在系统/分布式系统中写入数据时，从系统的任何节点读取数据时应获得的数据相同。 Consistency simply means, when you write a piece of data in a system/distributed system, the same data you should get when you read it from any node of the system. 可用性意味着系统应该始终可用于读/写操作。Availability means, the system should always be available for read/write operation. 注意：大多数系统不可用，仅可用或仅一致，它们总是同时提供两者的一部分。 使用上述定义，让我们来看一下MongoDB和Cassandra属于CAP的地方。 With the above definition let's see where MongoDB and Cassandra fall in CAP. MongoDB 您所说的MongoDB的高度一致读写时转到同一节点（默认情况）。此外，您可以在MongoDB中选择从其他辅助节点读取，而不是仅从leader / primary读取。 As you said MongoDB is highly consistent when reads and write go to the same node(the default case). Further, you can choose in MongoDB to read from other secondary nodes instead of reading from only leader/primary. 现在，当您尝试从辅助数据库读取数据时，一致性将完全取决于您要如何读取数据：Now, when you try to read data from secondary, your consistency will completely depend on, how you want to read data: 您可以询问最大为5秒的旧数据，或者 您可以说从 select 语句的节点数量为$ c>多数。 You could ask data which is up to maximum, say 5 seconds stale or,You could just say, return data from majority of nodes for your select statement. 从客户端向Mongo Leader写入数据时，可以说是相同的，如果将数据复制到或存储在多数的服务器上。 Same way when you write from your client into Mongo leader, you can say, a write is successful if the data is replicated to or stored on majority of servers. 很明显，从上面我们可以说，MongoDb可以高度一致，或者最终可以根据您读/写数据的方式保持一致。Clearly, from above, we can say MongoDb can be highly consistent or eventually consistent based on how you read/write your data.现在，可用性如何？ MongoDB通常总是可用的，但是，只有当领导者倒台时，MongoDB才能接受写操作，直到找到新的领导者为止。因此，没有高度可用 Now, what about availability? MongoDB is mostly always available, but, the only time when the leader is down, MongoDB can't accept writes, until it figures out the new leader. Hence, not highly available任何基于领导者的系统都可用，但高度不可用。 因此，MongoDB归类为CP。 Any leader based system is available but not highly available.So, MongoDB is categorized under CP. Cassandra怎么样？ 在Cassandra中没有领导者和节点可以接受写入，因此即使某些节点出现故障，Cassandra群集也始终可以进行写入，并且显然可以读取。In Cassandra, there is no leader and nodes can accept write, so Cassandra cluster is always available for writes and obviously reads even if some nodes go down. Cassandra的一致性如何？ 与MongoDB Cassandra相同，根据您读/写数据的方式最终可以保持一致或高度一致。What about consistency in Cassandra?Same as MongoDB Cassandra can be eventually consistent or highly consistent based on how you read/write data.您可以在读/写操作中给出一致性级别。 ，例如：You can give consistency levels in your read/write operations, For example: 从一个节点读取/写入数据 从多数节点读取/写入数据/ quorum节点和更多 假设您在读/写操作中给出的一致性级别为1。因此，一旦将数据写入一个节点/副本，您的写入便会成功。现在，假设您从尚未更新数据的另一个副本/节点读取数据，然后读取旧数据（可能是由于高网络延迟或任何其他原因）。 Let's say you gave a consistency level of one in your read/write operation. So, your write is successful as soon as data is written to one node/replica. Now, let's say you read data from the other replica/node where the data is not updated yet and read the old data(could be due to high network latency or any other reason). 但是最终，即使第二个节点也将获得更新的新数据。因此，当使用一致性级别一个时，不是高度一致性。But eventually, even the second node will get the updated new data. Hence not highly consistent when consistency level one is used.因此，Cassandra的可用性很高，但是具有可配置的一致性级别，因此并不总是一致。So, Cassandra is highly available but has configurable consistency levels and hence not always consistent.最后，在默认行为下，MongoDB属于CP，而Cassandra属于AP 。 In conclusion, in their default behaviour, MongoDB falls under CP and Cassandra in AP. 这篇关于为什么MongoDB的“一致性”不可用而Cassandra的“可用”不一致？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！