上回說到資料庫沒辦法同時做到完美的一致性、可用性跟分區容忍性，這就是今天要介紹的 CAP 理論。
（以下圖片來源為讀書會成員講義）

CAP 理論

所謂 CAP 理論以中文有名的諺語來說就是「魚與熊掌不可兼得」在分散式系統中不可能同時滿足 CAP 三者。CAP （C (一致性),、A (可用性)、P (分區容忍)）三者只能擇其二（或是勉強都達到一點點點），也就是選擇了 P，就只能再從 C, A 中二選一，如果 CA 都要拿，那就都會無法做到完美。

幾種 CAP 的組合

AP Database — 犧牲一致性的分散式資料庫

在分區容忍的前提下（因為都已經採用分散式架構了），犧牲一致性來提高可用性（盡可能每次都得到回應），不過雖然犧牲了一致性，卻仍可以達到最終一致性（Eventual Consistency，例如總統大選開票時每家新聞台的即時票數都不一致，但在選舉結束後的票數還是會達成一致。），適合在需要快速讀寫，但資料對於一致性的需求較低的場景，例如臉書或各大媒體平台的按讚系統。

例如：Amazon DynamoDB

CP Database — 犧牲可用性的分散式資料庫

在分區容忍的前提下，依然可以得到最新版本的資料，常用於貼文系統、訊息系統等不能犧牲一致性的系統。
例如：Google BigTable、MongoDB、分散式的 RDBMS

CA Database — 犧牲分區容忍性的資料庫

這樣就違反了分散式架構的初衷，因此基本上不會存在於分散式系統中。
例如：單機或是經過 Sharding 的資料庫（不能承受單機損壞）。

Scaling & Availability

接著來提一下擴展與可用性。

Q: RDBMS 怎麼做 Scaling ?
A: Database Sharding。

不過實作過程可說是非常複雜。

Q: 那 RDBMS 怎麼做到高可用性呢？(HA, high availability)
A:

看完 RDBMS，換來看看 NoSQL 的優缺點。

NoSQL 解決了什麼問題？

• 容易擴展的設計架構，由於資料沒有關聯性，因此相較於 RDBMS 更易於 scaling。
• 簡單快速的達到高可用性（HA）: Hash Function: O(1), Distributed Hash Funciton: O(log n)
• 容易進行 Schema 的變更，因為根本沒有 Schema，適合時常變更架構的系統。

然而，老樣子，沒有絕對完美的事情，NoSQL 一樣存在缺點。

NoSQL 的缺點

• 沒有固定的 Schema : 這點其實嚴格來說可以是優點也可以是缺點，得看需求來定論。
• 關聯式資料庫常見的 Transaction 與 JOIN 也就非常難在 NoSQL 實踐。
• 資料量不夠大時，其實效能普遍比 RDBMS 來要差

這邊提到了 Transaction，剛好在之前的篇章也淺淺介紹過 transaction，不過當時只考慮到單機運行的狀況，那在分散式的架構下的 Transaction 又會有什麼不一樣呢？文章開頭有提到，我們需要共識機制的幫忙。

其實共識機制有非常非常多種，不過在分散式資料庫中最常見的共識機制就是 2PC 這個共識機制。

分散式關聯性資料庫的範例：

關於分散式交易的更多資訊

小結

透過兩篇文章，我們大概了解了單機與分散式的架構差異，還有一致性、可用性、分區容忍性魚與熊掌不可兼得的 CAP 理論，也理解到不同組合的資料庫種類，還有分散式架構需要共識機制來完成交易，最後也稍微提到 RDBMS 與 NoSQL 非別怎麼擴展與兩者的區別。不過這篇真的是超淺淺淺談，現實面還有很多需要考慮的問題，分散式也未必是大流量需求下最佳的選擇，因此想要使用時還要謹慎看待囉！

Medium 版本

https://medium.com/@oldmo860617/%E5%88%9D%E6%AD%A5%E8%AA%8D%E8%AD%98%E5%88%86%E6%95%A3%E5%BC%8F%E8%B3%87%E6%96%99%E5%BA%AB%E8%88%87-nosql-cap-%E7%90%86%E8%AB%96-a02d377938d1