CAP and PACELC : the basic theorem of distributed database system

By Howard

Transcript

1. CAP and PACELC : the basic theorem of distributed database system 181024 Copyright ⓒ All Right Reserved by Buzzvil Howard Kim Software Engineer
2. Copyright ⓒ All Right Reserved by Buzzvil Contents 1. What is CAP theorem? 2. Understanding CAP theorem 3. Limit of CAP 4. PACELC 5. Some examples 6. Conclusion
3. Copyright ⓒ All Right Reserved by Buzzvil Referenece - You don’t need CP, you don’t want AP, and you can’t have CA - Siddhartha Reddy
4. Copyright ⓒ All Right Reserved by Buzzvil What is CAP theorem? - “It is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees” - Eric Brewer, University of California, Berkeley (2000) - Seth Gilbert and Nancy Lynch of MIT (2002) - the Basic theorem in DDBS(distributed database system)
5. Copyright ⓒ All Right Reserved by Buzzvil What is CAP theorem?
6. Copyright ⓒ All Right Reserved by Buzzvil C : Consistency Node1 Node2 Read(A) 1 ?? Client 1 Client 2 - Every read receives the most recent write or an error Read(A)
7. Copyright ⓒ All Right Reserved by Buzzvil A : Availability Node Write (A, 2) Done Client Error / Fail - Every request receives a response that is not an error
8. Copyright ⓒ All Right Reserved by Buzzvil P : Partition tolerance - The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes Node1 Node2 → Not P is Possible?
9. Copyright ⓒ All Right Reserved by Buzzvil Why CA (not P) is impossible? - 100% guaranteed network (never fails) → Impossible - even ONE BIG single Node can fail → Power failure, Equipment failure, Software bugs… → actually it is not distributed system So, Partition is a Reality. We can’t have CA.
10. Copyright ⓒ All Right Reserved by Buzzvil What is CAP theorem?
11. Copyright ⓒ All Right Reserved by Buzzvil Understanding CAP Node1 {A:1} Node2 {A:1} Write (A, 2) Client 1 Client 2 Inconsistent
12. Copyright ⓒ All Right Reserved by Buzzvil Understanding CAP Node1 {A:2} Node2 {A:1} Done Client 1 Client 2 Inconsistent
13. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:1} Read(A) Client 1 Client 2 Inconsistent Understanding CAP
14. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:1} 1 Client 1 Client 2 Inconsistent Inconsistent Understanding CAP
15. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:1} Node2 {A:1} Write (A, 2) Client 1 Client 2 Consistent Understanding CAP
16. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:1} Client 1 Client 2 Write (A, 2) Consistent Understanding CAP
17. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:2} Client 1 Client 2 Done Consistent Understanding CAP
18. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:2} Done Client 1 Client 2 Consistent Understanding CAP
19. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:2} Read(A) Client 1 Client 2 Consistent Understanding CAP
20. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:2} 2 Client 1 Client 2 Cool Consistent Understanding CAP
21. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:1} Node2 {A:1} Write (A, 2) Client 1 Client 2 Partition condition Understanding CAP
22. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:1} Client 1 Client 2 Consistent Have to make a choice Understanding CAP
23. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:1} Client 1 Client 2 Consistent Node1 {A:1} Node2 {A:1} Client 1 Client 2 Error Node1 {A:2} Node2 {A:1} Client 1 Client 2 Done Understanding CAP
24. Copyright ⓒ All Right Reserved by Buzzvil Node1 {A:2} Node2 {A:1} Client 1 Client 2 Consistent Node1 {A:1} Node2 {A:1} Client 1 Client 2 Error Node1 {A:2} Node2 {A:1} Client 1 Client 2 Done CP AP Understanding CAP
25. Copyright ⓒ All Right Reserved by Buzzvil Perfect CP (sacrifice Availability)
26. Copyright ⓒ All Right Reserved by Buzzvil Perfect CP (sacrifice Availability) Always consistent in all nodes - Cost is very high : have to check all nodes in every request. - Risk grows rapidly when the number of nodes grows So, We don’t need Perfect CP.
27. Copyright ⓒ All Right Reserved by Buzzvil Perfect AP (sacrifice Consistency)
28. Copyright ⓒ All Right Reserved by Buzzvil Perfect AP (sacrifice Consistency) Always process request and response with OK. - Meaningless response : almost same with empty response - A unlucky client can't notice something is wrong So, We don’t want Perfect AP.
29. Copyright ⓒ All Right Reserved by Buzzvil Some point in spectrum Perfect CP Perfect AP Your System !
30. Copyright ⓒ All Right Reserved by Buzzvil Limit of CAP - CAP theorem is all about partition condition. - Partition is inevitable. But We are not always in partition condition So, We need another axis. → PACELC
31. Copyright ⓒ All Right Reserved by Buzzvil From CAP to PACELC - “... PACELC(pass-elk) however goes further and states that another trade-off also exists: this time between latency and consistency, even in absence of partitions ...” - Daniel J. Abadi from Yale University (2012)
32. Copyright ⓒ All Right Reserved by Buzzvil What is PACELC? If Partition exists Availability / Consistency Else Latency / Consistency
33. Copyright ⓒ All Right Reserved by Buzzvil Expansion to 2-dimension Consistency Availability Your System ! Consistency Latency Partition condition Normal condition
34. Copyright ⓒ All Right Reserved by Buzzvil Example of MySQL - Master-Slave Replication - Partition condition: sacrifice Consistency for Availability - Else: sacrifice Consistency for Latency (Async Replica)
35. Copyright ⓒ All Right Reserved by Buzzvil Example of MySQL - Master-Slave Replication - Partition condition: sacrifice Consistency for Availability - Else: sacrifice Consistency for Latency (Async Replica) sacrifice Latency for Consistency (Semi-sync)
36. Copyright ⓒ All Right Reserved by Buzzvil Example of MySQL Consistency Availability Consistency Latency Async Replication Semi-sync Replication
37. Copyright ⓒ All Right Reserved by Buzzvil Other DBs - DynamoDB, Cassandra : PA/EL (default version) - Mongo DB : PA/EC (baseline) - Volt DB/HBase: PC/EC
38. Copyright ⓒ All Right Reserved by Buzzvil Example of MySQL Consistency Availability Consistency Latency Async Replication Semi-sync Replication
39. Copyright ⓒ All Right Reserved by Buzzvil Conclusion - PACELC is a good tool(frame) for decision making about distributed database system. - Configuration can move the position of DB in PACELC quadrant. - There can be many things that PACELC is missing (e.g. quantity of data, shape of data etc) - Your Business logic matters: Banking vs SNS
40. Copyright ⓒ All Right Reserved by Buzzvil Referneces - You don’t need CP, you don’t want AP, and you can’t have CA - Siddhartha Reddy - https://speakerdeck.com/sids/cap-theorem-you-dont-need-cp-y ou-dont-want-ap-and-you-cant-have-ca - http://happinessoncode.com/2017/07/29/cap-theorem-and-pac elc-theorem/ - https://en.wikipedia.org/wiki/CAP_theorem - https://en.wikipedia.org/wiki/PACELC_theorem - http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf