5

In terms of CAP theorem, MongoDB is usually defined as CP by default. In a replica set scenario, is the following correct? The option w is the write concern:

  • { w: 1 }: wait for a confirm only from the primary. If we read from secondary members, the system is eventually consistent and then AP.
  • { w: 3 }: wait for a confirm from three members. If the replica is made of three members, the system is consistent (strong?) and thus CP.
Community
  • 1
  • 1
gremo
  • 47,186
  • 75
  • 257
  • 421
  • @Sammaye ok, but in terms of CAP? – gremo Jul 09 '13 at 16:15
  • @Sammaye if my thoughts about AP/CP are correct... – gremo Jul 09 '13 at 16:38
  • @Sammaye whether a system is CP or AP has nothing to do with whether you're reading from primary or secondaries. – Asya Kamsky Jul 10 '13 at 02:29
  • @AsyaKamsky Ok got wrong end of the stick with the question then, I would then say that `{w:1}` is A not P since partition tolerance of the write would not exist in a failover situation in that case and `{w:3}` is CAP since it has availability, is fully consistent, and is partition tolerant – Sammaye Jul 10 '13 at 17:23
  • @AsyaKamsky Interesting, I related CAP in this question read prefernces with write perferences and you said I was wrong but it appears brody had the same idea too: http://stackoverflow.com/a/11297667/383478 – Sammaye Jul 11 '13 at 14:12
  • Someone is missing the point here: based on the CAP theorem, you cannot achieve C, A and P at the same time ("pick two"). In my opinion with `{w: 3}` you get strong consistency but loose availability. If one member of the replica set does not agree about the write operation, the write would fail (hence you loose availability). Thoughts? – gremo Jul 11 '13 at 16:32
  • why do you lose availability? It is instantly available on all servers? I had not considered if the write would fail, I am not sure if the CAP theory takes that into consideration, I think it is based upon always succeeding writes – Sammaye Jul 11 '13 at 16:47
  • This was a link on wikipedia: http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed you might find it interesting, also I didn't take instant failover into account in my last part, which would cause P to be lost – Sammaye Jul 11 '13 at 17:10
  • Dwight Merriman wrote and discussed this here: http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1 please note the important point he makes - write availability not just read availability needs to be considered for A. – Asya Kamsky Jul 12 '13 at 03:14

2 Answers2

2

Looking at Mongodb replication guide it look like, by default all query goes to the primary server. It you want the 'A' you also need to read on secondaries server, this is requiere to be AP. And then you loose the C because the results may be different from one server to another.

The question also look like this one, the answer could be helpful.

Community
  • 1
  • 1
Galigator
  • 8,957
  • 2
  • 25
  • 39
2

I am going to put this as answer due to pieces of evidence (like Mr K posted: Where does mongodb stand in the CAP theorem? ) to support my original concern on the subject before I deleted my comments due to Asya.

MongoDBs CAP compliancy seems to be based around what write concern is placed with what read concern.

Let's take an example. With the default configuration of reading from a primary {w:1} will be:

  • C since the write can be read immediately (maybe not because it doesn't go to all members, hmm this one is a thinker)
  • A since it is available immediately
  • but not P since on a single server it is not partition tolerant if there was immediately failover

MongoDB itself will be partition tolerant perfectly fine (as long as you don't have even number of servers on each side) irrespective of the write (even if that write is lost due to paritioning).

However reading from secondaries with this write concern will actually cause A since MongoDB will now be eventually consistent and you will return stale data back from members.

With your second example of 3 members with {w:3} it could be CAP entirely:

  • C because it goes to all members
  • A because it is available on all members
  • P because the replica set should not have a even number of members on either side. The contradiction to this is in the event of an immediate failover and two servers sit on oposite sides in which case P is lost because MongoDB is unsure as to which side to read from/write to and requires your intervention but you can just add abitriers to the forumla. This part of CAP is described well in a link put on Wikipedia: http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed under the heading "Why "2 of 3" is missleading". The exception is that MongoDB chooses to not loose C or A and instead requires your intervention.

Edit: Actually in this case CAP is lost entirely since MongoDB will just halt.

Edit again: As Asya pointed out MongoDB does still accept reads it just won't take writes which means it stays C but loses A, which fits in well with the standard then.

With all read concerns.

So I go back to what I said originally about the read concern and write concern having an involvement here (I honestly think they both do) and this is my answer.

Community
  • 1
  • 1
Sammaye
  • 43,242
  • 7
  • 104
  • 146
  • you are wrong - mongodb will not "halt" in partition - it will be unavailable for writes. it will be available for reads from primary on the majority side of the partition, and available for inconsistent reads on the minority side (i.e. secondary reads). Coincidentally since no more writes can be accepted during P the system stays C, just not A for writes. – Asya Kamsky Jul 12 '13 at 03:12
  • 1
    It is impossible to be CAP entirely. As soon as partitions are separated, you can no longer guarantee C. – Luke Jul 15 '13 at 18:11
  • @Luke In the event of a failover yes, as I mention, in fact the exact scenario is when two servers sit on either sidde of the partition, it isn't because the servers are partitioned, of course this is remedied by an odd number of one side, which you should always mantain – Sammaye Jul 15 '13 at 20:11
  • 2
    @Sammaye CAP must be applied in a failure scenario. If a letter does not apply in failure, that letter does not apply at all. It is incorrect to say "it could be CAP entirely". In a distributed system you either can read/write data at all times with no consistency, or you can read data at all times with write consistency. With partition tolerance either side of the partition could read stale data. – Luke Jul 15 '13 at 20:28
  • @Luke "CAP must be applied in a failure scenario" I thought that was what I just stated `:\`...I stated that in the event of a none failover it would be CAP but then straight after I talked about what happens in a failover in the next sentence. – Sammaye Jul 15 '13 at 20:41
  • @Sammaye I think you misunderstand what I'm telling you. CAP encompasses failure scenarios. The quoted text "it could be CAP entirely" is an incorrect statement. CAP is not about no-failure scenarios. – Luke Jul 15 '13 at 20:45
  • @Luke I am saying that was just one side. As I state straight after when I describe what happens in a failover – Sammaye Jul 15 '13 at 20:49