NoSQL發展簡史、粗略分類及選擇

    這裏對近來看的部分NoSQL資料作一個彙總記錄，主要包括簡史、粗略分類及數據庫選擇的考慮事項。NoSQL常見的解釋是「non-relational」，有時也稱做Not Only SQL。

    一、數據庫發展的簡單歷史，我的感受這篇文章（Ref：[2]）講得挺好的，知道過去才能把握將來：

    在90年代，一個網站的訪問量通常都不大，用單個數據庫徹底能夠輕鬆應付。在那個時候，更多的都是靜態網頁，動態交互類型的網站很少。

    到了最近10年，網站開始快速發展。火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。在初期，論壇的流量其實也不大，若是你接觸網絡比較早，你可能還記得那個時候還有文本型存儲的論壇程序，能夠想象通常的論壇的流量有多大。

    後來，隨着訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序再也不僅僅專一在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是經過文件緩存來緩解數據庫壓力，可是當訪問量繼續增大的時候，多臺web機器經過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就天然的成爲一個很是時尚的技術產品。

    Memcached做爲一個獨立的分佈式的緩存服務器，爲多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，而後又出現了一致性hash來解決增長或減小緩存服務器致使從新hash帶來的大量緩存失效的弊端。

    因爲數據庫的寫入壓力增長，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從複製技術來達到讀寫分離，以提升讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了。

    隨着web2.0的繼續高速發展，在Memcached的高速緩存，MySQL的主從複製，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，因爲MyISAM使用表鎖，在高併發下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數據增加的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力通常的公司帶來了但願。雖然MySQL推出了MySQL Cluster集羣，可是因爲在互聯網幾乎沒有成功案例，性能也不能知足互聯網的要求，只是在高可靠性上提供了很是大的保證。

    MySQL的擴展性瓶頸：在互聯網，大部分的MySQL都應該是IO密集型的，事實上，若是你的MySQL是個CPU密集型的話，那麼極可能你的MySQL設計得有性能問題，須要優化了。大數據量高併發環境下的MySQL應用開發愈來愈複雜，也愈來愈具備技術挑戰性。分表分庫的規則把握都是須要經驗的。雖然有像淘寶這樣技術實力強大的公司開發了透明的中間件層來屏蔽開發者的複雜性，可是避免不了整個架構的複雜性。分庫分表的子庫到必定階段又面臨擴展問題。還有就是需求的變動，可能又須要一種新的分庫方式。

    MySQL數據庫也常常存儲一些大文本字段，致使數據庫表很是的大，在作數據庫恢復的時候就致使很是的慢，不容易快速恢復數據庫。好比1000萬4KB大小的文本就接近40GB的大小，若是能把這些數據從MySQL省去，MySQL將變得很是的小。

    關係數據庫很強大，可是它並不能很好的應付全部的應用場景。MySQL的擴展性差（須要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。

    二、NoSQL的優點[2]

    易擴展

    NoSQL數據庫種類繁多，可是一個共同的特色都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就很是容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

    大數據量，高性能

    NoSQL數據庫都具備很是高的讀寫性能，尤爲在大數據量下，一樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。通常MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，因此NoSQL在這個層面上來講就要性能高不少了。

    靈活的數據模型

    NoSQL無需事先爲要存儲的數據創建字段，隨時能夠存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件很是麻煩的事情。若是是很是大數據量的表，增長字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤爲明顯。

    高可用

    NoSQL在不太影響性能的狀況，就能夠方便的實現高可用的架構。好比Cassandra，HBase模型，經過複製模型也能實現高可用。

    三、NoSQL的簡單分類

    NoSQL僅僅是一個概念，NoSQL數據庫根據數據的存儲模型和特色分爲不少種類[3]:

類型	部分表明	特色
列存儲	Hbase Cassandra Hypertable	顧名思義，是按列存儲數據的。最大的特色是方便存儲結構化和半結構化數據，方便作數據壓縮，對針對某一列或者某幾列的查詢有很是大的IO優點。
文檔存儲	MongoDB CouchDB	文檔存儲通常用相似json的格式存儲，存儲的內容是文檔型的。這樣也就有有機會對某些字段創建索引，實現關係數據庫的某些功能。
key-value存儲	Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis	能夠經過key快速查詢到其value。通常來講，存儲無論value的格式，照單全收。（Redis包含了其餘功能）
圖存儲	Neo4J FlockDB	圖形關係的最佳存儲。使用傳統關係數據庫來解決的話性能低下，並且設計使用不方便。
對象存儲	db4o Versant	經過相似面嚮對象語言的語法操做數據庫，經過對象的方式存取數據。
xml數據庫	Berkeley DB XML BaseX	高效的存儲XML數據，並支持XML的內部查詢語法，好比XQuery,Xpath。

 

    另外也會有一些細的分類等，例如：    

    類bigTable技術的數據庫示例：HBase（不一樣於通常的關係數據庫,它是一個適合於非結構化數據存儲的數據庫.另外一個不一樣的是HBase基於列的而不是基於行的模式）；Cassandra（一個混合型的非關係的數據庫）；Hypertable（Bigtable的一個開源實現）。

    內存數據庫：redis key-value存儲系統，但也支持持久化機制（快照，AOF等）；Memcached，不過不支持持久化；Memlink 是天涯社區開發的一個高性能、持久化、分佈式的Key-list/queue數據引擎。與Memcached不一樣的是，它的value是一個list/queue。而且提供了諸如持久化，分佈式的功能。聽起來有點像Redis，但它號稱比Redis更好。[4]

    注意：MemcacheDB與memcached不一樣，它是一個分佈式、key-value形式的持久存儲系統，不是一個緩存組件，而是一個基於對象存取的、可靠的、快速的持久存儲引擎。 協議跟memcache一致（不完整），所以不少memcached客戶端均可以跟它鏈接。MemcacheDB採用Berkeley DB做爲持久存儲組件，故不少Berkeley DB的特性的他都支持。MemcacheDB的前端：memcached的網絡層，後端：BerkeleyDB存儲。

 

    四、數據庫的選擇問題

    首先，須要肯定業務需求，是否須要NoSQL產品。對於大多數百萬量級、千萬量級的應用，MySQL也能支持。

    其次，在明確須要NoSQL產品後，應根據業務需求抽象出數據模型，好比：有些數據是須要採用key-value系統存儲，有些數據是須要採用key-list系統存儲，有些數據是採用文檔數據庫存儲等等。

    對於NoSQL產品候選列表的選項，能夠從以下維度進行考慮：

1. 系統的容量、性能、軟硬件環境是否符合需求？
2. 數據的安全機制如何？各類異常是否會丟失數據？
3. 具有主從複製功能？何種一致性策略？
4. 可擴展性？自動擴展 or 程序進行擴展？

    系統的可控性？系統的成熟度、對開發者的支持度、bug誰來修復等等[5]

 

 

Ref：

[1] http://zh.wikipedia.org/zh/NoSQL

[2] http://www.infoq.com/cn/news/2011/01/nosql-why  注：這個連接的內容感受挺好的，包括一些討論

[3] http://blog.csdn.net/zhongguoren666/article/details/8423589

[4] http://www.cnblogs.com/skyme/archive/2012/07/26/2609835.html

[5] http://www.infoq.com/cn/news/2010/11/tianya-memlink/