前言 近幾年NoSQL資料庫興起，各種新的產品層出不窮，在此學習下NoSQL的基本理論，並認識下常見的NoSQL資料庫。 一 NoSQL資料庫興起的原因 隨著大數據技術興起和Web2.0時代的到來。傳統關係型資料庫已經無法滿足當前的資料庫需求了。 無法滿足的需求主要有3點: 海量數據的存儲與管理 （ ...
前言
近幾年NoSQL資料庫興起，各種新的產品層出不窮，在此學習下NoSQL的基本理論，並認識下常見的NoSQL資料庫。
一 NoSQL資料庫興起的原因
隨著大數據技術興起和Web2.0時代的到來。傳統關係型資料庫已經無法滿足當前的資料庫需求了。
無法滿足的需求主要有3點:
- 海量數據的存儲與管理 （傳統關係型資料庫已經無法支撐）
- 大數據量下的併發性 （傳統關係型資料庫嚴格的事務機制導致了海量數據的操作會導致大範圍的數據鎖定，降低併發性）
- 高可用性，高擴展性（用戶更關註是否功能可用。海量數據需要橫向擴展資料庫滿足需求，縱向已經無法滿足）
與之相比原本關係型資料庫的優點已經不被許多公司所需要，主要也有3點：
- 嚴格的資料庫事務（如微信，新浪微博等互聯網公司，丟失一條消息等，ACID的實現與否並不是很重要）
- 嚴格的讀寫實時性（同理，一條消息伺服器寫入後，其他人是否立即看到並不太重要）
- 複雜的條件查詢（為了節約硬體存儲空間降低冗餘，傳統關係型資料庫會將各種信息分表存儲，但是現在硬體性能已經足夠將信息全部存儲。並不太需要複雜的多表查詢操作）
為了滿足大數據量下的業務需求，傳統關係型資料庫也發展出多種技術手段，但是最終事實證明NoSQL資料庫才是最適合的選擇。傳統關係型資料庫的解決方案經歷瞭如下幾個階段：
- 主從複製，實現讀寫分離。設置一個主伺服器，若幹從伺服器。主伺服器負責寫操作，並實時複製修改內容到從伺服器上。從伺服器負責讀操作。（但是對於寫請求的負擔仍然無法解決）
- 分庫，分流一部分請求。分庫又分為橫向分庫和縱向分庫，橫向分庫即將不同業務維度的資料庫拆分開來，伺服器根據業務場景，查詢不同資料庫。縱向分庫即將數據行按照一定的規律分別存儲到不同資料庫內。如：根據hash，根據生產時間等。（但是導致了不同庫之間不能直接查詢，且仍然無法滿足更大的數據要求）
- 分表，類似於分庫。通過橫向或者縱向切分表。
二 NoSQL資料庫的四大類型
分別是 ：
- 鍵值資料庫
- 列族資料庫
- 文檔資料庫
- 圖資料庫
2.1 普遍的特性（優點）
- 數據結構靈活。（傳統關係型資料庫有嚴格的欄位要求，且後續修改複雜）
- 可擴展性強（容易橫向擴展，支持分散式，且擴展的複雜度不高，對比傳統關係型資料庫的擴展非常複雜）
- 支持高併發操作。
2.2 各自的特性
- 鍵值資料庫。是鍵值對的存儲資料庫。
- 優點：適合大量寫操作。
- 缺點：但是存儲的數據沒有結構化，複雜查詢效率低。
- 應用：常用做內容緩存。
- 代表產品：Redis，Memcached
- 列族資料庫，底層基於列族進行存儲的資料庫。（查找時，基於行鍵列族查找，可以看做鍵值資料庫的變種）
- 優點：查詢速度快，橫向擴展性尤其好，適合分散式系統，屏蔽了分散式的複雜性。
- 缺點：功能簡單，大都不支持事務一致性。（Hadoop的HBase是支持的）
- 應用：分散式的數據存儲。
- 代表產品：Cassandra，HBase
- 文檔資料庫，基於鍵存儲文檔。（也可看做鍵值資料庫的變種）
- 優點：半結構化，數據格式可以自解釋，如：JSON,XML。因此數據結構非常靈活，且併發性高。
- 缺點：缺乏統一的查詢語法
- 應用：存儲文檔型數據，半結構化數據。
- 代表產品：MongoDB，CouchDB
- 圖資料庫，基於圖數據結構的資料庫。
- 優點：支持複雜的圖演算法與關係圖譜
- 缺點：只適合圖和關係的應用領域，其他領域性能較差。
- 應用：複雜圖結構，如社交網路，關係圖譜。
- 代表產品：Neo4J，InfoGrid
三 NoSQL資料庫的三大基石
3.1 CAP理論三個特性
- C：一致性（任何一個讀操作總是能讀取到之前完成的寫操作結果）
- A：可用性（每一個操作總是能夠在確定的時間內返回，也就是系統隨時都是可用的）
- P：分區容忍性（出現網路分區，整個系統仍然可用）
經過證明，一個分散式系統不能同時滿足三個特性，最多滿足兩個。
傳統關係型資料庫滿足了CA，放棄了P。因此擴展困難。而現在大部分互聯網系統都是分散式系統，不可能放棄P特性。
通俗的解釋下為何只能同時滿足兩個特性：
假設同時滿足C和A和P。P保證了系統存在不同的網路節點，那麼為了保證C，系統會嘗試與其他的節點同步數據信息，但是出現網路問題導致系統分區時（即節點無法互相通信），會導致同步無法立刻完成，這樣就無法滿足A了。
此時只需要去除一個特性即可：
- 去除P，保留CA。則沒有了網路通信問題，在實現C數據一致性時，可以很快的完成，也保證了A。
- 去除A，保留CP。則不要求立刻完成，在實現C數據一致性時，即使出現了網路分區P，也可以慢慢等待。
- 去除C，保留AP。則不需要保證數據一致性了，即使網路出現分區，各個節點都能單獨運行，保證了用戶可用(反正系統已經不在乎各個節點數據的一致了)。
3.2 BASE理論
BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性。
- BA：基本可用。一部分分區出現問題，系統仍然可用,主要保證核心功能可用。（電商大促時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現）
- S：軟狀態。數據的一致性要求降低，可以一段時間不滿足一致性。相對應的是硬狀態。（分散式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。mysql replication的非同步複製也是一種體現。）
- E：最終一致性。弱一致性，後續操作無法立刻獲取更新的信息。相對應的是強一致性。最終一致性是特殊的弱一致性，只保證了。
3.3 最終一致性
（明明BASE就包含了最終一致性，不知道書中為何又將它單獨列為三大理論基礎之一）
