[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 |
DescriptionDo 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 changesImpact to Other DocsMVP (Work and Date)Resources (Scope or Design Docs, Invision, etc.) |
| Comments |
| Comment by Nicholas Larew [ 05/Apr/21 ] |
|
| 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:
^ 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. |