關係型數據庫的優點與劣勢：
優點：
a、數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務。
b、對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢。從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢。
c、數據庫的寫實時性和讀實時性需求
對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性，比方說發一條消息之後，過幾秒乃至十幾秒之後，訂閱者纔看到這條動態是完全可以接受的。
劣勢：
a、對數據庫高併發讀寫支持不夠。
關係數據庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬盤IO就已經無法承受了。
b、對海量數據的高效率存儲和訪問的需求支持不夠。
對於關係數據庫來說，在一張2.5億條記錄的表裏面進行SQL查詢，效率是極其低下乃至不可忍受的。如大型web網站的用戶登錄系統，動輒數以億計的帳號，關係數據庫也很難應付。
c、對數據庫的高可擴展性和高可用性的需求支持不夠。
在基於web的架構當中，數據庫是最難進行水平擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。
針對以上的劣勢，NoSQL（非關係型數據庫）應運而生。包括Redis和MongoDB。
NoSQL被我們用得最多的當數key-value存儲，當然還有其他的文檔型的、列存儲、圖型數據庫、xml數據庫等
1、TIPS
（1）Redis（高性能Key-Value數據庫的主要特點就是具有極高的併發讀寫性能，用C寫的）
是滿足極高讀寫性能需求的key-value數據庫，本質是內存數據庫，和memcached類似，整個數據庫統統加載在內存當中進行操作，定期通過異步操作把數據庫數據flush到硬盤上進行保存。因爲是純內存操作，Redis的性能非常出色，每秒可以處理超過10萬次讀寫操作。是性能最快的Key-Value DB。
Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存List鏈表和Set集合的數據結構，而且還支持對List進行各種操作，例如從List兩端push和pop數據，取List區間，排序等等，對Set支持各種集合的並集交集操作，此外單個value的最大限制是1GB，不像memcached只能保存1MB的數據，因此Redis可以用來實現很多有用的功能，比方說用他的List來做FIFO雙向鏈表，實現一個輕量級的高性能消息隊列服務，用他的Set可以做高性能的tag系統等等。另外Redis也可以對存入的Key-Value設置expire時間，因此也可以被當作一個功能加強版的memcached來用。
Redis的主要缺點是數據庫容量受到物理內存的限制，不能用作海量數據的高性能讀寫，並且它沒有原生的可擴展機制，不具有scale（可擴展）能力，要依賴客戶端來實現分佈式讀寫，因此Redis適合的場景主要侷限在較小數據量的高性能操作和運算上。目前使用Redis的網站有github，Engine Yard。
（2）MongoDB
是滿足海量存儲需求和訪問的面向文檔的數據庫。面向文檔的非關係數據庫主要解決的問題不是高性能的併發讀寫，而是保證海量數據存儲的同時，具有良好的查詢性能。MongoDB是用C++開發的。
MongoDB是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構非常鬆散，是類似json的bjson格式，因此可以存儲比較複雜的數據類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似於面向對象的查詢語言，幾乎可以實現類似關係數據庫單表查詢的絕大部分功能，而且還支持對數據建立索引。
Mongo主要解決的是海量數據的訪問效率問題，根據官方的文檔，當數據量達到50GB以上的時候，Mongo的數據庫訪問速度是MySQL的10倍以上。Mongo的併發讀寫效率不是特別出色，根據官方提供的性能測試表明，大約每秒可以處理0.5萬－1.5次讀寫請求。對於Mongo的併發讀寫性能，我（robbin）也打算有空的時候好好測試一下。
因爲Mongo主要是支持海量數據存儲的，所以Mongo還自帶了一個出色的分佈式文件系統GridFS，可以支持海量的數據存儲，但我也看到有些評論認爲GridFS性能不佳，這一點還是有待親自做點測試來驗證了。
最後由於Mongo可以支持複雜的數據結構，而且帶有強大的數據查詢功能，因此非常受到歡迎，很多項目都考慮用MongoDB來替代MySQL來實現不是特別複雜的Web應用，比方說why
we migrated from MySQL to MongoDB就是一個真實的從MySQL遷移到MongoDB的案例，由於數據量實在太大，所以遷移到了Mongo上面，數據查詢的速度得到了非常顯著的提升。
MongoDB也有一個ruby的項目MongoMapper，是模仿Merb的DataMapper編寫的MongoDB的接口，使用起來非常簡單，幾乎和DataMapper一模一樣，功能非常強大易用。
（3）滿足高可擴展性和可用性的面向分佈式計算的數據庫：Cassandra，Voldemort
面向scale能力的數據庫其實主要解決的問題領域和上述兩類數據庫還不太一樣，它首先必須是一個分佈式的數據庫系統，由分佈在不同節點上面的數據庫共同構成一個數據庫服務系統，並且根據這種分佈式架構來提供online的，具有彈性的可擴展能力，例如可以不停機的添加更多數據節點，刪除數據節點等等。因此像Cassandra常常被看成是一個開源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java開發的：
1、Cassandra
Cassandra項目是Facebook在2008年開源出來的，隨後Facebook自己使用Cassandra的另外一個不開源的分支，而開源出來的Cassandra主要被Amazon的Dynamite團隊來維護，並且Cassandra被認爲是Dynamite2.0版本。目前除了Facebook之外，twitter和digg.com都在使用Cassandra。
Cassandra的主要特點就是它不是一個數據庫，而是由一堆數據庫節點共同構成的一個分佈式網絡服務，對Cassandra的一個寫操作，會被複制到其他節點上去，對Cassandra的讀操作，也會被路由到某個節點上面去讀取。對於一個Cassandra羣集來說，擴展性能是比較簡單的事情，只管在羣集裏面添加節點就可以了。我看到有文章說Facebook的Cassandra羣集有超過100臺服務器構成的數據庫羣集。
Cassandra也支持比較豐富的數據結構和功能強大的查詢語言，和MongoDB比較類似，查詢功能比MongoDB稍弱一些，twitter的平臺架構部門領導Evan Weaver寫了一篇文章介紹Cassandra：http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/，有非常詳細的介紹。
Cassandra以單個節點來衡量，其節點的併發讀寫性能不是特別好，有文章說評測下來Cassandra每秒大約不到1萬次讀寫請求，我也看到一些對這個問題進行質疑的評論，但是評價Cassandra單個節點的性能是沒有意義的，真實的分佈式數據庫訪問系統必然是n多個節點構成的系統，其併發性能取決於整個系統的節點數量，路由效率，而不僅僅是單節點的併發負載能力。
web應用的架構當中，web層和app層相對來說都很容易橫向擴展，唯有數據庫是單點的，極難scale，
2、PS
（1）最常用的NoSQL數據庫：
http://www.csdn.net/article/2013-12-25/2817913
（2）