Mongo and Cassandra in context of CAP?

Question

After reading couple of articles on google, I See NoSql DB like Mongo is designed for CP(in CAP) while cassandra is designed for AP(in CAP)

Here is my question:-

Can't Mongo be configured to provide AP instead of CP or Is it rigidly designed for the CP ? Same is true for Cassandra ?

Answer 1

MongoDB can never be AP as it's a leader based system. There could be 2 scenarios:

1. When the leader disconnects from the cluster, it takes 10-12 seconds to elect a new leader, for that duration MongoDB will not be available for writes.
2. Client driver disconnects from leader due to network partition between client and leader. Unless MongoDB client also takes part in leader election and keeps the heartbeat of leader, I am not sure if mongo has this feature.

In the case of Cassandra, as Alex said we can make Cassandra more consistent by compromising availability.

Read this article, for a detailed explanation.

Answer 2

Our understanding of CAP theorem has changed considerebly since its first appearance in 2000. There were a lot of confusion about the "chose-2-out-of-3" concept but Eric Brewer's article in 2012 nicely eliminated these confusions (I guess).

So, CAP theorem is not about being CA or AP or something else. It is simply this: Network partitions may happen all the time. It is unavoidable. And when a network partition happens, the architecture of a distributed database should allow its clients to tune consistency and availability as they wish.

What does this mean? Assume that you replicate a piece of data between 3 nodes (N1, N2, and N3 - so replication factor = 3) in a cluster. And let's say that a network partition happens which seperates N3 from N1 and N2:

So, all of the 3 nodes are operational, but the network between them is problematic right now. In this situation a client might make a read request or a write request to N1, N2 or N3. Based on the consistency choices of this client, the reaction of the cluster may differ:

• If the client makes a read request to N1, N1 can answer the query right away with its own data. Or N1 can forward the same query to N2 and compares its data with N2's data and returns the most up-to-date one. Here, the reaction of the cluster depends on the consistency choice of the client. Client tunes consistency according to its choices.
• Client can make a different choice too: It can force N1 to read data from all 3 nodes (i.e. read consistency of ALL in Cassandra terms). In this situation, cluster returns an error and we say that the cluster is not available accodring to the client's choice.
• Another possibility might be this one: Client might have asked the data to N3. In this situation, N3 only returns its data (read consistency = ONE) or the query fails (read consistency > 1).

I don't know about Mongo but this is how Cassandra works considering the CAP theorem.

Answer 3

You can achieve "AP" in MongoDB by allowing split brain.

You can make Cassandra "CP" by setting read/writes to "ALL" setting (there are edge cases where QUORUM is not enough).

But, there's a very good article about why calling databases AP/CP is a wrong terminology. There are very strong and solid definition of what is availability and consistency in the context of CAP theorem , and most of the time people do not dive deep enough to understand it, and, by the way most of the databases do not fit in a strict CAP theorem neither as AP or CP.

The link: https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

Answer 4

Cassandra uses tunable consistency, that you can control it when writing and/or reading data by using different consistency levels. For example, if you use QUORUM for both writes & reads, then you get strong consistency, although availability may suffer.

P.S. I can't say about Mongo though...