http://cloud.csdn.net/a/20110808/302768.html
在兩三年前，選擇數據庫是一件非常容易的事。資金充足的企業會選擇甲骨文數據庫，使用微軟產品的企業通常SQL Server，而預算不足企業則會選擇MySQL。不過，如今的情況已經大不相同了。
最近兩三年，許多企業都推出了他們自己的開源項目以用於存儲信息。在許多案例中，這些項目拋棄了傳統的關係型數據庫準則。許多人將這些項目稱爲NoSQL，即“Not Only SQL”的縮寫。雖然有些NoSQL數據庫很簡單，但是還有一部分NoSQL數據庫極爲複雜。不過，它們的目標都是通過替代關係型數據庫，並實現更高的系統性能。
NoSQL的支持者通過放棄傳統架構成功建立起了速度更快，擴展性更高的應用。不過，一些保守的數據庫管理員對此卻不屑一顧。他們認爲，許多SQL已經解決的問題將成爲NoSQL的絆腳石。對此，NoSQL支持者並不在意，因爲他們有着不同的項目需求，而如今他們正在瞄準新的目標。
NoSQL項目有什麼不同之處呢？這些新型數據庫被人們以自己的方式建立起來。相反，老的SQL數據庫則聚合了大量的功能和一套標準語言。程序包可能會將鍵與值進行配對，但是它們可以針對不同的使用案例進行調整。主要的變量並不在於數據格式，而在於它們多久被複制、存儲和分割。
例如，你是否存儲一些例如個人電子郵件地址等經常被恢復的數據？一些數據是否被存儲起來，以防不時之需，比如日誌文件？你是希望有更多使用小容量數據的用戶，還是希望只有幾名使用大容量數據的用戶？如果你丟失了幾行用戶數據，那麼你的行爲是否會影響到你的用戶的生存，這些用戶是否會起訴你？
過去，每名架構師都會爲MySQL的設置而苦惱。現在，架構師可以選擇一個全新的項目。如果你的項目需求與新型數據庫的性能匹配，那麼這種混亂中無疑蘊藏着巨大的優勢。如果它們非常規整，性能將會獲得不可思議的提升。但是，開發人員不會建造出一個可以解決所有問題的“無畏戰艦”。
以前，開發者會創建很好的跨數據庫函數庫以消除差異，讓它們變得更加容易轉換。例如，許多Java開發者會在JDBC函數庫上編寫代碼。這些數據庫有着很好的互操作性。老的函數庫沒有一個可以與這些新數據庫協同工作。儘管許多項目使用的是相似的方法，但是將一個函數庫移植到另一個之上需要進行大量的重新編寫工作。
更糟糕的是，許多輔助項目消失了。報告生成工具有許多種類，但是沒有一個新型數據庫可以使用這些工具。如果不進行一番折騰，它們是不會工作的。與SQL協同工作的程序包可能有成百上千種，但是能夠幫助NoSQL的程序包卻很少。有跡象顯示，這種互操作性需要很長時間才能出現在NoSQL上。此外，查詢語言也存在着很大的差異。
Cassandra
Facebook需要一個更快、更廉價的方式處理數以億計的狀態更新。因此，他們啓動了這一項目，並最終將其移植到了Apache上，這就是Cassandra。在Apache上，它能夠得到許多社區的幫助。目前Cassandra已經不再僅僅用於Facebook，許多爲該項目工作的程序員來自其他公司。如今DataStax.com公司正致力於爲Cassandra提供商業支持。
Cassandra是一個跟蹤如Facebook上的狀態更新等大量數據的優秀工具。這一工具可以幫助創建一個計算機網絡，網絡上的所有計算都擁有相同的數據。這意味着每臺機器都可以被相互替代。一旦數據通過P2P網絡節點，它們的一致性就會喪失。關鍵是“最終一致”，而不是“時刻一致”。如果你發現你的狀態更新在Facebook消失一下，然後又重新出現，你就明白這意味着什麼。
CouchDB
CouchDB被用於存儲文檔，最大的變化在於查詢。取代一些基本查詢結構的是，CouchDB通過兩種功能來搜索文檔，以導航並減少數據。一個編排文檔格式，另一個確定包括哪些文檔。一名清楚存儲程序的、熟練的甲骨文數據庫操作人員會做同樣的事情。但是，導航和減少結構將讓基層程序員大開眼界。目前，AJAX開發人員已經能夠編寫出相當複雜的搜索程序，這些程序可以寫入一些更爲複雜的邏輯。
CouchDB的核心由Erlang編寫。但是API和界面卻是JavaScript或是JSON。
JavaScript API僅僅是加強CouchDB對普通Web開發人員的吸引力。這些開發人員可以將文檔，甚至整個網站存儲在數據庫中。
MongoDB
MongoDB是一個關於JavaScript如何掌握世界的典型。程序獲取格式化爲JSON格式的數據，然後將它們存儲起來。查詢是JavaScript的基礎功能，這與使用瀏覽器控制檯沒有太大的差別，只是簡化了一些東西。最大的區別是，MongoDB會爲你的數據庫創建索引，如果索引被正確地創建，那麼反饋查詢結果的速度將會很快。另外，該數據庫可以與大量的其他工具協同工作。
Redis
與CouchDB和MongoDB一樣，Redis用於存儲文檔和由鍵值對組織的文件。與其他的NoSQL數據庫不同的是，其存儲的不僅僅是字符串或是數字，其中還包括分類和未分類的字符串集合作爲與鍵關聯的值。這一特點使其可以爲用戶提供更爲複雜的集合操作。用戶不再需要下載數據計算交集，因爲Redis能夠在服務器上做這一工作。
Redis催生了一些沒有過多編碼的簡單結構。Luke Melia通過創建一個全新集合追蹤其網站上的訪問者。最後五個集合的並集可確定那些當時在線的訪問者。這一帶有好友列表的並集的交集可以生成在線好友列表。這類集操作擁有許多應用。Redis集羣爲我們揭示了其強大的功能。
Redis將數據存儲在內存中，僅記錄下每次變化的列表。由於其具有功能強大，可寫入硬盤中寫入的緩存，許多人甚至並不將Redis稱之爲數據庫。由於Redis只需要在數據讀入內存之前進行等待，因此速度要比傳統數據庫快很多，但是不適時機的斷電導致其存在潛在的應用風險。
Riak
Riak是設計最爲精巧的數據存儲，其擁有其他產品的絕大多數功能，並且對副本有着更多的控制。儘管基本結構存儲着多對鍵值，但是恢復它們和確保它們的一致性的選項很多。比如寫入操作包括了要求Riak確認數據何時被成功傳輸到集羣其他機器上的參數。如果你不希望僅信任一臺機器，在發送確認信息前，你可以要求其等待，直至兩臺、三臺或是54臺機器寫入了數據。這也是該團隊能夠打出“最終一致性不是數據遺失的藉口”這一口號的原因。
數據自身並不僅僅寫在硬盤中。這只是其中的一個選項，但是並不是主要的。Riak使用的是插件式存儲引擎（默認爲Bitcask）。該引擎用它們自己的內部格式將數據寫入硬盤中。此外，它還有多種選項，包括MySQL使用的InnoDB版本。Riak的集羣能力可以確保所有一切都萬無一失。
在抓取數據時，Riak會消除任何可能出現的錯誤。如果在兩個節點的目標版本不同，那麼Riak會選擇最新升級版本，或是將兩個目標版本都反饋回來，交由你的客戶端代碼做決定。對於發現數據中存在的潛在錯誤，這是一個非常有用的選項。
Neo4J
在我們所提到的幾個應用之中，Neo4J是最具特色一個。它可以用於存儲圖而不是數據。它對圖數據是以節點和邊（關係）模式進行存儲。社交網絡應用是它的強項。Neo4J非常的新，開發人員仍然在尋找更好的算法。在新版本中，開發人員開始嘗試新的緩存策略：由於Neo4J能夠緩存節點信息，因此搜索算法運行速度很快。開發人員還爲其增加了類似XSL模式匹配的新查詢語言。
Neo4J受到了Neo Technology公司的支持。該公司推出的商業用版本數據庫擁有備份、故障恢復和複雜監視功能。
FlockDB
有些人抱怨代碼過於複雜，他們認爲Neo4J過於複雜，超出了他們的需求。那麼他們不妨嘗試一下FlockDB。FlockDB是一個實時的、分佈式的數據庫，是Twitter網站基礎設施的核心組件。Twitter在一年多以前推出了基於Apache許可證的開源項目FlockDB。如果你想建立起自己的Twitter，那麼你需要下載Gizzard工具，其作用是分割跨多個Flock的數據。由於FlockDB存儲兩個節點之間的關聯，我們中的許多人將FlockDB稱爲“圖數據庫”。不過，也有人認爲這一稱呼僅適用於像Neo4J這類複雜的工具。
如何選擇NoSQL數據庫？
關於如何選擇NoSQL數據庫這一問題並不好回答。許多IT部門會隨便選一個，有時候他們選擇的數據庫並不能滿足他們的需求。由於優秀的開發人員希望能夠平衡項目的優勢、商業支持的可獲得性以及文檔質量，因此選擇一個最佳數據庫是十分困難的。
這些數據庫都存儲了大堆的鍵和值，但是真正的問題是如何在服務器中合理分配負載，如何將變更傳遞給它們。另一個問題是託管。雲服務能夠替你完成所有的維護，這一點非常具有吸引力。與SQL數據庫相比，NoSQL數據庫的數據交換更爲困難。目前全球還沒有一個標準的查詢語言，也沒有一個像JDBC一樣的大型虛擬層。儘管如此，NoSQL數據庫已經對我們具備了足夠的吸引力。
