CAP理論和NoSQL的疑問？

在CAP理論中，RDBMS一般都被歸入CA向的資料庫；而MongoDB、HBase這些則被歸入CP向的資料庫。但是稍稍想一下，MongoDB的P是通過Sharding和Replication等方法實現的，HBase的Region也和Sharding很像。

1. 考慮到RDBMS也有Sharding和Replication等技術，為何它被歸入CA而MongoDB、HBase則被歸入CP呢？

2. 另外Mongo、HBase這些對事務等的支持並不算好，為何它們被稱為偏重C，而非偏重A呢？

謝謝！

回家看了三天相關文章，已人肉刪原答案 ?_?

（不過放心好了另外兩個答案也不好，尤其「你當然三個都得算」已經是魔幻了）

• CAP Twelve Years Later: How the "Rules" Have Changed

• You Can』t Sacrifice Partition Tolerance

針對題主的問題嘗試總結的話：

• CAP 中 "C" 是單塊數據複製的一致性，更像 Coherence；ACID 的 "C「 側重於數據的完整性（Integrity），事務操作執行務必滿足所有數據約束；

• CAP 原意是想表達 「單個多副本系統在一個特定時間只能滿足兩個性質」，也就是 「複製副本中如果發生 P 選 A 還是選 C」

• 因此 「三個選兩個」 存在誤導性：沒事不發生 P 的正常情況，不管什麼爛系統也都滿足 C 和 A；至於怎麼犧牲 P 的概念不確定，P 怎麼犧牲這由得我們么？只能買十分可靠的網線，但是 *萬一* 網路掛，那麼還是 C 和 A 選一個 ；但是也可以用概率的角度看待 CA，比如 zookeeper 五個節點掛三個才不可用，那麼認為它在五個節點沒掛三個的概率下滿足 CA 也沒問題；

• sharding 跟 CAP 沒關係，因為沒有數據的多份複製；
• 對存儲系統硬生生分類必要性不大，一般想 CP 還是 AP 都會留個配置；單節點的 RDBMS 壓根不是在 CAP 討論的範疇。

CAP原理是個混淆硬體和軟體的偽定理,詳見CAP原理的偽命題及其解決辦法

C=一致性

A=可用性

P=容錯性

其實RDBMS剛開始的時候很多都是沒有sharding和replication的，所以只有CA是很正常的。那你說現在SQLAzure算什麼，你當然三個都得算。

A一般是談你有幾個9這樣的問題，MongoDB和HBase顯然是不關心這些的，哪怕有replication也不夠，所以怎麼說都不能偏重A。至於他們基本不支持transaction還有C，這個還真不知道為什麼。