CAP Theorem 和 Database

對 CAP Theorem 基本瞭解後, 我們知道實務上都是在 CP 系統和 AP 系統間選擇, 結合我們 Day 4 介紹的 Database, 我們簡單可以用 CP 系統 和 AP 系統 分類

• CP 系統: RDBMS
• AP 系統: NoSQL Database

就像前面提過的, RDBMS 的 ACID 特性確保了一致性, 所以是 CP 系統的首選; NoSQL Database 則具有 BASE (Basically Available, Soft-state, Eventual consistency) 的特性, 所以適合 AP 系統

(題外話: 由於大型公司勢必會走向分散式系統架構, 所以NoSQL Database 才會越來越普遍)

PACELC Theorem

PACELC (Partition-aware Availability or Consistency, Else Latency or Consistency) Theorem 是 CAP Theorem 的補充

由於 CAP Theorem 主要強調 "分區錯誤發生時" 一致性 和 可用性 的取捨; 但 分區錯誤 並非永遠存在, 所以 PACELC Theorem 進一步針對 "分區錯誤沒有發生" 的情況深入說明

(題外話: PACELC 很長很難記, 其實可以分為 PAC 和 ELC 就好, PAC 就是原本的 CAP, 將 Partition 放在開頭是為了後面的 ELC 做區分, 即當 P 存在時, 要在 AC 間取捨; 當 P 不存在, 即 Else, 要在 LC 間取捨, 所以才說是 CAP Theorem 的延伸)

PACELC Theorem 的精神是, 即使在沒有分區錯誤時, 我們仍然需要在 Latency 和 Consistency 間做選擇, 畢竟同步是需要花時間的

所以我們可以進一步將系統分類如下

• PA/EL
• PA/EC
• PC/EC
• PC/EL (沒有此需求)

/ 前面的部分很好理解, 就是之前介紹過的 CAP Theorem 的選擇, 後半部分則是 Latency 和 Consistency 的選擇

雖然理論上有 PC/EL 系統, 但實務上較少這種選擇

為什麼沒有 PC/EL 系統?

我們可以這樣思考: 沒有分區錯誤才是常態, 分區錯誤發生的取捨才是 "妥協"

我們先要思考我們的系統 "在常態下偏好 一致性 還是 低延遲?"

1. 若我們選擇 一致性, 則當 分區錯誤 發生時, 因為節點間無法溝通, 所以我們只能在 一致性 和 可用性 間權衡
2. 若我們選擇 低延遲, 則當 分區錯誤 發生時, 雖然節點間無法溝通, 但由於我們選擇了 低延遲, 所以理當會選擇 可用性; 若選擇了 一致性, 這就和正常情況的選擇衝突, 有點奇怪

所以, 重點是以 "通常情況下的選擇為主", "分區錯誤時再做妥協"

PC/EL 由於通常情況下的選擇, 即使在分區錯誤時也不需要妥協, 所以不太會有這種系統存在

PACELC Theorem 和 Database

基於上述說明, 我們再進一步將 Database 依照 PACELC 分類

• PA/EL: Dynamo, Cassandra
• PA/EC: MongoDB
• PC/EC: BigTable, HBase

Reference

• System Design Interview Basics: CAP vs. PACELC