? ? ? 在過去，我們只需要學習和使用一種數據庫技術，就能做幾乎所有的數據庫應用開發。因為成熟穩定的關系數據庫產品并不是很多，而供你選擇的免費版本就更加少了，所以互聯網領域基本上都選擇了免費的MySQL數據庫。在高速發展的WEB2.0時代，我們發現關系數據庫在性能、擴展性、數據的快速備份和恢復、滿足需求的易用性上并不總是能很好的滿足我們的需要，我們越來越趨向于根據業務場景選擇合適的數據庫，以及進行多種數據庫的融合運用。

? ? ?當我們在討論是否要使用NoSQL的時候，你還需要理解NoSQL也是分很多種類的，在NoSQL百花齊放的今天，NoSQL的正確選擇比選擇關系數據庫還具有挑戰性。雖然NoSQL的使用很簡單，但是選擇卻是個麻煩事，這也正是很多人在觀望的一個原因。

NoSQL的分類

?? ? ? ? NoSQL僅僅是一個概念，NoSQL數據庫根據數據的存儲模型和特點分為很多種類。

類型	部分代表	特點
列存儲	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。

?? ? ? ?以上NoSQL數據庫類型的劃分并不是絕對，只是從存儲模型上來進行的大體劃分。它們之間沒有絕對的分界，也有交差的情況，比如Tokyo Cabinet / Tyrant的Table類型存儲，就可以理解為是文檔型存儲，Berkeley DB XML數據庫是基于Berkeley DB之上開發的。

NoSQL還是關系數據庫

?? ? ? 雖然09年出現了比較激進的文章《關系數據庫已死》，但是我們心里都清楚，關系數據庫其實還活得好好的，你還不能不用關系數據庫。但是也說明了一個事實，關系數據庫在處理WEB2.0數據的時候，的確已經出現了瓶頸。

?? ? ? 那么我們到底是用NoSQL還是關系數據庫呢？我想我們沒有必要來進行一個絕對的回答。我們需要根據我們的應用場景來決定我們到底用什么。

? ? ? 如果關系數據庫在你的應用場景中，完全能夠很好的工作，而你又是非常善于使用和維護關系數據庫的，那么我覺得你完全沒有必要遷移到NoSQL上面，除非你是個喜歡折騰的人。如果你是在金融，電信等以數據為王的關鍵領域，目前使用的是Oracle數據庫來提供高可靠性的，除非遇到特別大的瓶頸，不然也別貿然嘗試NoSQL。

?? ? ? ?然而，在WEB2.0的網站中，關系數據庫大部分都出現了瓶頸。在磁盤IO、數據庫可擴展上都花費了開發人員相當多的精力來優化，比如做分表分庫（database sharding）、主從復制、異構復制等等，然而，這些工作需要的技術能力越來越高，也越來越具有挑戰性。如果你正在經歷這些場合，那么我覺得你應該嘗試一下NoSQL了。

選擇合適的NoSQL

?? ? ? 如此多類型的NoSQL，而每種類型的NoSQL又有很多，到底選擇什么類型的NoSQL來作為我們的存儲呢？這并不是一個很好回答的問題，影響我們選擇的因素有很多，而選擇也可能有多種，隨著業務場景，需求的變更可能選擇又會變化。我們常常需要根據如下情況考慮：

數據結構特點。包括結構化、半結構化、字段是否可能變更、是否有大文本字段、數據字段是否可能變化。

寫入特點。包括insert比例、update比例、是否經常更新數據的某一個小字段、原子更新需求。

查詢特點。包括查詢的條件、查詢熱點的范圍。比如用戶信息的查詢，可能就是隨機的，而新聞的查詢就是按照時間，越新的越頻繁。

NoSQL和關系數據庫結合

? ? ? 其實NoSQL數據庫僅僅是關系數據庫在某些方面（性能，擴展）的一個彌補，單從功能上講，NoSQL的幾乎所有的功能，在關系數據庫上都能夠滿足，所以選擇NoSQL的原因并不在功能上。所以，我們一般會把NoSQL和關系數據庫進行結合使用，各取所長，需要使用關系特性的時候我們使用關系數據庫，需要使用NoSQL特性的時候我們使用NoSQL數據庫，各得其所。

? ? ? 舉個簡單的例子吧，比如用戶評論的存儲，評論大概有主鍵id、評論的對象aid、評論內容content、用戶uid等字段。我們能確定的是評論內容content肯定不會在數據庫中用where content=’’查詢，評論內容也是一個大文本字段。那么我們可以把 主鍵id、評論對象aid、用戶id存儲在數據庫，評論內容存儲在NoSQL，這樣數據庫就節省了存儲content占用的磁盤空間，從而節省大量IO，對content也更容易做Cache。

//從MySQL中查詢出評論主鍵id列表 commentIds=DB.query("SELECT id FROM comments where aid='評論對象id' LIMIT 0,20"); //根據主鍵id列表，從NoSQL取回評論實體數據 CommentsList=NoSQL.get(commentIds);

NoSQL代替MySQL

?? ? ? ?在某些應用場合，比如一些配置的關系鍵值映射存儲、用戶名和密碼的存儲、Session會話存儲等等，用NoSQL完全可以替代MySQL存儲。不但具有更高的性能，而且開發也更加方便。

NoSQL作為緩存服務器

? ? ? ?MySQL+Memcached的架構中，我們處處都要精心設計我們的緩存，包括過期時間的設計、緩存的實時性設計、緩存內存大小評估、緩存命中率等等。

NoSQL數據庫一般都具有非常高的性能，在大多數場景下面，你不必再考慮在代碼層為NoSQL構建一層Memcached緩存。NoSQL數據本身在Cache上已經做了相當多的優化工作。

? ? ? ?Memcached這類內存緩存服務器緩存的數據大小受限于內存大小，如果用NoSQL來代替Memcached來緩存數據庫的話，就可以不再受限于內存大小。雖然可能有少量的磁盤IO讀寫，可能比Memcached慢一點，但是完全可以用來緩存數據庫的查詢操作。

規避風險

? ? ? ?由于NoSQL是一個比較新的東西，特別是我們選擇的NoSQL數據庫還不是非常成熟的產品，所以我們可能會遇到未知的風險。為了得到NoSQL的好處，又要考慮規避風險，魚與熊掌如何兼得？

? ? ? 現在業內很多公司的做法就是數據的備份。在往NoSQL里面存儲數據的時候還會往MySQL里面存儲一份。NoSQL數據庫本身也需要進行備份（冷備和熱備）。或者可以考慮使用兩種NoSQL數據庫，出現問題后可以進行切換（避免出現digg使用Cassandra的悲劇）。

總結

?? ? ?本文只是簡單的從MySQL和NoSQL的角度分析如何選擇，以及進行融合使用。其實在選擇NoSQL的時候，你可能還會碰到關于CAP原則，最終一致性，BASE思想的考慮。因為使用MySQL架構的時候，你也會碰到上面的問題，所以這里沒有闡述。

?

參考：http://www.cnblogs.com/sunli/archive/2011/01/24/nosql_or_relation.html

總結

以上是生活随笔為你收集整理的关系数据库NoSQL数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。