NoSQL介紹

什麼是NoSQL

  NoSQL，泛指非關係型的數據庫，NoSQL即Not-Only SQL，它能夠做爲關係型數據庫的良好補充。隨着互聯網web2.0網站的興起，非關係型的數據庫如今成了一個極其熱門的新領域，非關係數據庫產品的發展很是迅速。而傳統的關係數據庫在應付web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了不少難以克服的問題，例如： 

一、High performance - 對數據庫高併發讀寫的需求

  web2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，因此基本上沒法使用動態頁面靜態化技術，所以數據庫併發負載很是高，每每要達到每秒上萬次讀寫請求。關係數據庫應付上萬次SQL查詢還勉強頂得住，可是應付上萬次SQL寫數據請求，硬盤IO就已經沒法承受了。其實對於普通的BBS網站，每每也存在對高併發寫請求的需求，例如網站的實時統計在線用戶狀態，記錄熱門帖子的點擊次數，投票計數等，所以這是一個至關廣泛的需求。

二、Huge Storage - 對海量數據的高效率存儲和訪問的需求 

  相似Facebook，twitter，Friendfeed這樣的SNS網站，天天用戶產生海量的用戶動態，以Friendfeed爲例，一個月就達到了2.5億條用戶動態，對於關係數據庫來講，在一張2.5億條記錄的表裏面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登陸系統，例如騰訊，盛大，動輒數以億計的賬號，關係數據庫也很難應付。 

三、High Scalability && High Availability- 對數據庫的高可擴展性和高可用性的需求 

  在基於web的架構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的經過添加更多的硬件和服務節點來擴展性能和負載能力。對於不少須要提供24小時不間斷服務的網站來講，對數據庫系統進行升級和擴展是很是痛苦的事情，每每須要停機維護和數據遷移，爲何數據庫不能經過不斷的添加服務器節點來實現擴展呢？ 

四、數據來源多，原始數據不容易結構化，有強schema約束的關係型數據庫再也不合適 
五、對數據存儲的要求有變化，以CAP理論爲指導，大多數系統並不要求強一致性，而是對數據存儲系統的Availability & Partition tolerance有更高要求

 

NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤爲是大數據應用難題。

  

NOSQL數據庫一般知足BASE約束： 
1）Basic Availability 基本可用
系統在外界看來彷佛總處於可用狀態，這是經過多機水平擴展的集羣部署方案實現的，只要多數節點正常就能保證系統基本的可用性，只有落在故障節點的用戶請求才會感知到系統不可用。 
2）Soft-state 柔性一致狀態
大多數NOSQL系統經過犧牲強一致性來保證可用性和分區容忍性，也即，一個節點寫入新數據後，更新不會當即傳播至集羣其它節點，因此落在其它節點上的讀請求可能會讀到舊數據。 
3）Eventual consistency 最終一致
NOSQL系統對最終一致性一般是能夠保證的。值得一提的是，Neo4j這個圖數據庫雖然也屬NOSQL陣營，但它是能夠保證ACID約束的。

從定義來看，與關係型數據庫的ACID強約束相比，BASE約束要鬆散一些，但靈活性有優點，所以，知足前述數據特徵的互聯網系統愈來愈依賴NOSQL系統也就不足爲奇了。固然，一些對數據有ACID要求的系統仍是應該首選關係型數據庫。 
總之，數據特徵決定了咱們在實際工程中應該使用何種存儲系統。

 

NoSQL數據庫的四大分類以下：

 

 

一、 鍵值(Key-Value)存儲數據庫　Key-Value Stores

KV型NOSQL系統起源於Amazon開發的Dynamo系統（Amazon AWS提供的DynamoDB就是這貨），能夠把它理解爲一個分佈式的hashmap，支持SEG/GET元操做。

一個完整的分佈式KV系統會將KEY按策略儘可能均勻地散列在不一樣的節點上。其中一致性哈希是比較優雅的散列策略，它能夠保證當某個節點掛掉時，只有該節點的數據須要從新散列。做爲對比，若採用取模哈希策略，則集羣有節點不可用時，取模的分母N發生變化，會致使幾乎全部的KEY都要從新散列，代價過高。

大多數KV NOSQL一般不會關心存入的value究竟是什麼，在它看來，那只是一堆字節而已，因此開發者也沒法經過value的某些屬性來獲取整個value。若是開發者有根據value的部分字段查找數據的需求，那應該考慮使用文檔型NOSQL系統。

典型的KV型NOSQL系統：Memcached, Redis及DynamoDB, Tokyo Cabinet/Tyrant, Voldemort, Berkeley DB

典型應用： 內容緩存，主要用於處理大量數據的高訪問負載。 

數據模型： 一系列鍵值對

優點： 快速查詢

劣勢： 存儲的數據缺乏結構化

不適用場景：

1.取代經過鍵查詢，而是經過值來查詢。Key-Value數據庫中根本沒有經過值查詢的途徑

2.須要儲存數據之間的關係。在Key-Value數據庫中不能經過兩個或以上的鍵來關聯數據。

3.事務的支持。在Key-Value數據庫中故障產生時不能夠進行回滾。

 

二、 列存儲數據庫　Column Family Stores

列式NOSQL系統起源於Google的BigTable，其數據模型能夠看做是一個每行列數可變的數據表，它能夠細分爲4種實現模式，以下圖所示。 
 
其中，Super Colunm Family模型能夠理解爲maps of maps，例如能夠把一個做者和他的專輯結構化地存成Super Colunm Family模式，以下圖所示。 
 
與KV型或文檔型的NOSQL系統相比，列式存儲系統對數據模型的表達力更強。

典型的列式NOSQL系統：BigTable, Cassandra, HBase, Cassandra, Riak

典型應用：分佈式的文件系統

數據模型：以列簇式存儲，將同一列數據存在一塊兒

優點：查找速度快，可擴展性強，更容易進行分佈式擴展

劣勢：功能相對侷限

適用場景：1.日誌 2.博客平臺,咱們儲存每一個信息到不一樣的列族中。舉個例子，標籤能夠儲存在一個，類別能夠在一個，而文章則在另外一個。

不適用場景：1.ACID事務 2.原型設計。在模型設計之初，咱們根本不可能去預測它的查詢方式，而一旦查詢方式改變，咱們就必須從新設計列族。

 

三、 文檔型數據庫　Document Stores

對於須要跟具備層次文檔結構的數據打交道的開發者來講，文檔型NOSQL系統提供了最天然的存儲模式，它支持讀/寫一些標準格式的文檔數據（典型如XML, YAML和JSON，甚至支持2進制的BSON格式）。

在最簡單的應用中，文檔數據能夠經過其ID進行讀寫操做，此時，能夠將文檔型NOSQL系統看做是K-V系統。

但文檔型NOSQL系統更廣泛的應用場合是根據文檔的某個屬性字段來獲取整個文檔。根據屬性快速獲取包含該屬性的全部文檔的操做是經過索引來實現的，也即文檔數據在寫入時，系統會對某些文檔屬性創建索引，從而支持高效地反查操做。而維護索引是有代價的，所以，文檔型NOSQL數據庫適用於讀多寫少的場合。

須要注意的是，對於單個文檔的讀寫，文檔型NOSQL系統能夠保證原子操做，但批量寫入的事物原子性目前還不能由系統保證，須要開發者在應用程序中顯式處理。

此外，目前大多數文檔型NOSQL系統須要用戶來規劃數據在集羣多個實例間的sharding策略，所以，系統的水平擴展問題須要在選型時重點考慮，例如MongoDB早期版本的auto sharding在運維上就容易坑人，致使其一直被詬病。做爲對比，主流的KV NOSQL系統和列式NOSQL系統在底層實現時就支持自動sharding，一般無需開發者花費很大精力來處理。

典型的文檔型NOSQL系統：MongoDB和Apache CouchDB

典型應用：Web應用（與Key-Value相似，Value是結構化的）

數據模型： 一系列鍵值對

 優點：數據結構要求不嚴格

 劣勢： 查詢性能不高，並且缺少統一的查詢語法

不適用場景：不支持事務

 

四、 圖形(Graph)數據庫　Graph Databases

上面介紹的KV系統、文檔型系統及列式存儲系統可被統一稱爲聚合存儲系統（Aggregate Stores），它們的共同點是不適合處理具備耦合關係的數據，即它們不適合用於須要理解數據關聯關係的複雜查詢，而這正是圖數據庫的用武之地。

圖數據庫能夠細分爲底層存儲引擎和處理引擎兩部分。有些圖數據庫實現了native的、爲存儲和管理圖數據作過特別優化的圖存儲引擎（例如Neo4j），而有些圖數據庫底層存儲是外接系統。至於處理引擎，有些數據庫實現了具有index-free adjacency特性的引擎（如Neo4j），而有些圖數據庫並未作到這一點。

圖數據庫在查找數據時並不會特別依賴索引（嚴格地說，只是在定位初始節點時會用到索引），由於對於圖來講，節點間的關係能夠用有向邊表達出來。基於圖的查詢會利用這種局部臨接關係遍歷圖，而非根據全局索引對圖中節點作遍歷，所以，對於有關聯關係的數據來講，利用圖進行查詢的性能會很高。

圖數據庫在組織數據時，經常使用的數據模型包括：屬性圖（property graphs）、超圖（hypergraphs）和三元組（triples)，其中屬性圖模型是圖數據庫組織數據時廣泛採用的主流模型，Neo4j便是採用屬性圖模型來表達數據間的關聯關係。

上述3種圖數據模型間的詳細區別涉及較多術語，限於篇幅，本文不贅述，感興趣的話能夠翻閱」Graph Database (2nd Edition)」一書的附錄部分。

相關數據庫：Neo4J、InfoGrid、Infinite Graph

典型應用：社交網絡

數據模型：圖結構

優點：利用圖結構相關算法。

劣勢：須要對整個圖作計算才能得出結果，不容易作分佈式的集羣方案。

 

3. 參考資料

1. Wikipedia: NOSQL
2. Wikipedia: CAP theorem
3. Book: Graph Database (2nd Edition), Appendix A. NOSQL Overview
4. Wikipedia: Consistent Hashing
5. Neo4j Blog: Demining the 「Join Bomb」 with Graph Queries, 文中解釋了index-free adjacency對圖遍歷的重要性

參考連接：

http://blog.csdn.net/slvher/article/details/50212923

http://blog.csdn.net/sinat_20827235/article/details/52403639