[DOCS-14335] [SERVER] CAP and PACELC theorem explanation Created: 05/Apr/21  Updated: 22/Jan/24

Status: Backlog
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Minor - P4
Reporter: Albert Wong (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: backlog, proactive, query, replication
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 2 years, 44 weeks, 2 days ago
Epic Link: DOCSP-11702

 Description   

Description

Do we have any official documentation on  CAP or PACELC_theorem?   The only stuff I can find is what our SA have written but there is nothing posted on mongodb.com.   Our own SA written material says we are P+C (https://docs.google.com/presentation/d/1m52XODzQIHGAcgGaAod4e1NoTkcEQT4MIvVqSJCN0jQ/edit#slide=id.g90ae0d2d30_0_0 however wikipedia says we are P+A https://en.wikipedia.org/wiki/PACELC_theorem) and we don’t address PACELC (of which wiki says we are E+C). 

From JM: see my comment below. We do have such docs.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Nicholas Larew [ 05/Apr/21 ]

They don’t frame the behaviour in academic contexts of things like CAP, BASE, or PACELC

 
I think that generally makes sense and aligns with our docs approach. "Consistent" and "Available" are somewhat broad terms (consistent reads? writes?) and MongoDB is too customizable to neatly fit into any subcategory. It's probably better to focus on the actual goals/requirements in terms of "strong consistency, transactional guarantees, and replica set elections" and then work backwards towards a read/write concern strategy.

Comment by Albert Wong (Inactive) [ 05/Apr/21 ]

mat.keep says...

 

Whitepapers like Why Documents and the Architecture Guide discuss our behaviour around strong consistency, transactional guarantees, and replica set elections. They don’t frame the behaviour in academic contexts of things like CAP, BASE, or PACELC

Comment by Albert Wong (Inactive) [ 05/Apr/21 ]

https://mongodb.slack.com/archives/C0V2X5QDP/p1617635513288000

Comment by Nicholas Larew [ 05/Apr/21 ]

We probably could address CAP a bit more directly (i.e. by name) given that it's a fairly ubiquitous term in distributed systems. Could be a relatively easy SEO win!

 

albert.wong you won't find a definitive answer because MongoDB isn't definitively CP or AP. Instead, database clients specify a read and write concern for every query - depending on the exact read/write concern settings you will get different levels of tradeoff between consistency and availability. The cool part is that each client gets to decide for themselves what that tradeoff is and MongoDB handles it all under the hood.

For example:

  • In a banking app that requires high consistency (CP), I could set up my client to have causally consistent sessions. This is among the highest levels of consistency MongoDB provides when confronted with partitions (CAP) and generally incurs higher latency to support the consistency (PACELC).
  • In a social media app that requires high availability (AP), I could set up my client to use a "local" read concern. This means I may not get a few "likes" or comments on a post if there's a network partition, but it's okay if those don't show up immediately - AP means our preference is that we get any data back even if it's not totally up to date.

^ There's a bunch of different read/write concern combinations so you can really customize your CAP restrictions for each query.

Comment by Albert Wong (Inactive) [ 05/Apr/21 ]

It doesn't specifically address CAP.   Am I missing something?

Comment by Julia Malkin [ 05/Apr/21 ]

https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/ - albert.wong we do. Please consider closing the ticket.

Generated at Thu Feb 08 08:10:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.