CAP
CAP理論最早是在2000年7月19號，由Berkeley的Eric Brewer教授在ACM PODC會議上的一個開題演講中提出，PPT在此。此後，MIT的Seth Gilbert和Nancy Lynch，理論上證明了Brewer猜想是正確的，CAP理論在學術上正式作爲一個定理出現了。
CAP理論的C就是一致性（Consistency），這裏不多解釋，想了解的可以看看我之前寫過的一致性的一些東西；A就是可用性（availability），可以理解爲是否可獲取數據，以及獲取數據的速度；P就是分區容忍度（partion tolerance），指的是系統中的數據分佈性的大小對系統的正確性，性能的影響（一定程度上就是可擴展性）。這個理論的主要意思就是這三個是不可以同時做到很好的，我們在實現一個分佈式系統時（包括分佈式數據庫），是不可能同時完美的實現三個方面。其實這個理論可以用“魚和熊掌不可兼得”一言以蔽之。
NoSQL一定程度上就是基於這個理論提出來的，因爲傳統的SQL數據庫（關係型數據庫）都是都是具有ACID屬性，對一致性要求很高，因此降低了A（availability）和P（partion tolerance），因此，爲了提高系統性能和可擴展性，必須犧牲C（consistency），推翻關係型數據庫中ACID這一套。
依據CAP理論，從應用的需求不同，我們對數據庫（其實就是一種結構化數據存儲，和Bolb恰好不同）時，可以從三方面考慮：
- 考慮CA，這就是傳統上的關係型數據庫(RMDB).
- 考慮CP，主要是一些Key-value數據庫，典型代表爲google的Big Table
- 考慮AP，主要是一些面向文檔的適用於分佈式系統的數據庫，如SimpleDB。
而對大型網站尤其是SNS網站，對於數據的短期存儲，可用性與分區容忍性優先級要高於數據一致性，一般會盡量朝着 A、P 的方向設計，而對於數據的持久存儲，可以通過傳統的SQL來保證一致性（最終一致性）。
CAP理論出現後，很多大規模的網站，尤其是SNS網站的數據庫設計都利用其思想，包括Amazon,Facebook和Twitter這幾個新興的IT巨頭，因此，一定程度上來講，他們都是CAP的信徒。另一方面，他們從實踐上證明了CAP理論的正確性。
最終一致性
- 存儲系統
存儲系統可以理解爲一個黑盒子，它爲我們提供了可用性和持久性的保證。
- Process A
ProcessA主要實現從存儲系統write和read操作
- Process B 和ProcessC
ProcessB和C是獨立於A，並且B和C也相互獨立的，它們同時也實現對存儲系統的write和read操作。
下面以上面的場景來描述下不同程度的一致性：
- 強一致性
強一致性（即時一致性） 假如A先寫入了一個值到存儲系統，存儲系統保證後續A,B,C的讀取操作都將返回最新值
- 弱一致性
假如A先寫入了一個值到存儲系統，存儲系統不能保證後續A,B,C的讀取操作能讀取到最新值。此種情況下有一個“不一致性窗口”的概念，它特指從A寫入值，到後續操作A,B,C讀取到最新值這一段時間。
- 最終一致性
最終一致性是弱一致性的一種特例。假如A首先write了一個值到存儲系統，存儲系統保證如果在A,B,C後續讀取之前沒有其它寫操作更新同樣的值的話，最終所有的讀取操作都會讀取到最A寫入的最新值。此種情況下，如果沒有失敗發生的話，“不一致性窗口”的大小依賴於以下的幾個因素：交互延遲，系統的負載，以及複製技術中replica的個數（這個可以理解爲master/salve模式中，salve的個數），最終一致性方面最出名的系統可以說是DNS系統，當更新一個域名的IP以後，根據配置策略以及緩存控制策略的不同，最終所有的客戶都會看到最新的值。
變體
- Causal consistency（因果一致性）
如果Process A通知Process B它已經更新了數據，那麼Process B的後續讀取操作則讀取A寫入的最新值，而與A沒有因果關係的C則可以最終一致性。
- Read-your-writes consistency
如果Process A寫入了最新的值，那麼Process A的後續操作都會讀取到最新值。但是其它用戶可能要過一會纔可以看到。
- Session consistency
此種一致性要求客戶端和存儲系統交互的整個會話階段保證Read-your-writes consistency.Hibernate的session提供的一致性保證就屬於此種一致性。
- Monotonic read consistency
此種一致性要求如果Process A已經讀取了對象的某個值，那麼後續操作將不會讀取到更早的值。
- Monotonic write consistency
此種一致性保證系統會序列化執行一個Process中的所有寫操作。
BASE
說起來很有趣，BASE的英文意義是鹼，而ACID是酸。真的是水火不容啊。
- Basically Availble --基本可用
- Soft-state --軟狀態/柔性 事務
"Soft state" 可以理解爲"無連接"的, 而 "Hard state" 是"面向連接"的
- Eventual Consistency --最終一致性
最終一致性， 也是是 ACID 的最終目的。
BASE思想的主要實現有
1.按功能劃分數據庫
2.sharding碎片
BASE思想主要強調基本的可用性，如果你需要高可用性，也就是純粹的高性能，那麼就要以一致性或容錯性爲犧牲，BASE思想的方案在性能上還是有潛力可挖的。
從CAP原理講起，然後將目前的各大 NoSQL 產品進行了分類，如下：
按功能分類：
- Relational 關係性數據庫，這裏就不多說了，像我們常用的 MySQL 就是傑了代表。
- Key-value 鍵值存儲，支持簡單的get ，set，delete等協議。
- Column-oriented 列式存儲，通常不支持join操作，與傳統關係型數據庫的行式存儲相比他的存儲是列式的，這樣會讓很多統計聚合操作更簡單方便。
- Document-oriented 文檔型存儲，通常是將數據存在Json或者Xml，同樣不支持join操作。這種存儲方式可以很容易地被面向對象的語言所使用。
滿足一致性，可用性的系統，通常在可擴展性上不太強大：
- Traditional RDBMSs like Postgres, MySQL, etc (relational)
- Vertica (column-oriented)
- Aster Data (relational)
- Greenplum (relational)
滿足一致性，分區容忍性的系統，通常性能不是特別高:
- BigTable (column-oriented/tabular)
- Hypertable (column-oriented/tabular)
- HBase (column-oriented/tabular)
- MongoDB (document-oriented)
- Terrastore (document-oriented)
- Redis (key-value)
- Scalaris (key-value)
- MemcacheDB (key-value)
- Berkeley DB (key-value)
滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些:
- Dynamo (key-value)
- Voldemort (key-value)
- Tokyo Cabinet (key-value)
- KAI (key-value)
- Cassandra (column-oriented/tabular)
- CouchDB (document-oriented)
- SimpleDB (document-oriented)
- Riak (document-oriented)
