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和關系資料庫結合

其實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的悲劇）。