本文的作者Sourav Mazumder目前是InfoSys Technologies的***技術架構師。他在信息技術領域有14年以上的經驗。作為Infosys技術顧問團的主要成員，Sourav為 Infosys在美國、歐洲、澳洲和日本的主要客戶，提供保險、電信、銀行、零售、安全、交通以及建筑、工程、施工等多個行業的服務。 他曾參與Web項目的技術架構和路線圖定義，SOA戰略實施，國際戰略定義，UI組件化，性能建模，伸縮性分析，非結構化數據管理等等。Sourav參考的Infosys自身的核心銀行產品Finacle，也為他提供了豐富的產品開發經驗。Sourav還曾參與開發Infosys的J2EE可重用框架，和定義Infosys在架構方面和開發定制應用方面的軟件工程方法。Sourav的經歷還包括在保證架構合規和開發項目的治理方面的工作。Sourav是 iCMG認證的軟件架構師，同時也是TOGAF 8認證的執行者。Sourav最近在LISA伯克利全球化會議上發表了演講。Sourav關于SOA的***白皮書在社區里十分流行。Sourav目前關注 NoSQL，Web 2.0，治理，性能建構和全球化。

以下是文章全文：

作為企業架構師，我的職業習慣之一，就是不斷的探求各種新的有前景的概念和思想，看其是否有潛力為我所服務的來自各行各業的企業客戶帶來價值。同樣出于對這種理念的追求，我對NoSQL領域的關注了也有一段時間了，甚至從這個術語產生(或者錯誤的產生?)之前就開始了。Google首先在這方面點了一把火，發布了論文Big Table架構，對關系數據庫是銀彈這種普遍的信念提出了質疑，而Amazon關于Dynamo的論文則緊隨其后。 過去的一年中我們見證了NoSQL強勁的勢頭，在這一領域有多達25種產品/解決方案發布，并且NoSQL的觸角已經伸向了業界的各個角落。在此前提下，我最近考慮深入這一領域，評估一下我的客戶究竟如何才能從這種NoSQL運動中獲益。不僅如此，我還想探究對于企業來說，是否是到了該認真考慮采納 NoSQL的合適時機了。

什么是NoSQL——快速回顧

像許多關注這一領域的人一樣，我不喜歡從本質上將SQL與NoSQL這一術語對立起來。同時我對該術語現有的解釋"Not Only SQL"也不甚滿意。對我來說，我們這里所討論的并非是是否使用SQL。(相反的是，我們仍然可以選擇類似SQL這樣的查詢接口(缺少對join等的支持)來與這些數據庫交互，使用現有的資源和技術來管理開發伸縮性和可維護性。) 這一運動是要找到存儲和檢索數據的其他高效的途徑，而不是盲目地在任何情況下都把關系數據庫當作萬金油。因此，我認為' Non Relational Database '(非關系型數據庫)能夠更好的表達這一思想。

無論采用哪個名字，“非關系型數據庫”這一范圍所傳達出來的“囊括所有”類型的意味，使得這一概念比較模糊(并且它還是否定型的)。這又使得人們(特別是企業中的決策者)對于哪些是屬于這個范圍，哪些不是，更重要的是，對他們來說這到底意味著什么，感到非常迷惑。

為了解答這些疑問，我嘗試通過以下幾點特征的描述，來刻畫“非關系型數據庫”的內在本質。

所謂“非關系型數據庫”指的是：

1. 使用松耦合類型、可擴展的數據模式來對數據進行邏輯建模(Map，列，文檔，圖表等)，而不是使用固定的關系模式元組來構建數據模型。
2. 以遵循于CAP定理(能保證在一致性，可用性和分區容忍性三者中中達到任意兩個)的跨多節點數據分布模型而設計，支持水平伸縮。這意味著對于多數據中心和動態供應(在生產集群中透明地加入/刪除節點)的必要支持，也即彈性(Elasticity)。
3. 擁有在磁盤或內存中，或者在這兩者中都有的，對數據持久化的能力，有時候還可以使用可熱插拔的定制存儲。
4. 支持多種的'Non-SQL'接口(通常多于一種)來進行數據訪問。

圍繞著圖中四個特征的(數據持久性、邏輯數據模型、數據分布模型和接口)“非關系型數據庫”的各種變形，在最近的一些文章中有詳盡的描述，并且在因特網上有著廣泛的傳播。所以我就不做過多繁復的描述，而是通過一些例子對關鍵的方向進行總結，供快速參考：

• 接口——REST (HBase，CouchDB，Riak等)，MapReduce (HBase，CouchDB，MongoDB，Hypertable等)，Get/Put (Voldemort，Scalaris等)，Thrift (HBase，Hypertable，Cassandra等)，語言特定的API(MongoDB)。
• 邏輯數據模型——面向鍵值對的(Voldemort，Dynomite 等)，面向Column Family的(BigTable，HBase，Hypertable 等)，面向文檔的(Couch DB，MongoDB等)，面向圖的(Neo4j， Infogrid等)
• 數據分布模型——一致性和可用性(HBase，Hypertable， MongoDB等)， 可用性和可分區性(Cassandra等)。一致性和可分區性的組合會導致一些非額定的節點產生可用性的損失。有趣的是目前還沒有一個“非關系型數據庫”支持這一組合。
• 數據持久性—— 基于內存的(如Redis，Scalaris， Terrastore)，基于磁盤的(如MongoDB，Riak等)，或內存及磁盤二者的結合(如 HBase，Hypertable，Cassandra)。存儲的類型有助于我們辨別該解決方案適用于哪種類型。然而，在大多數情況下人們發現基于組合方案的解決方案是***的選擇。既能通過內存數據存儲支持高性能，又能在寫入足夠多的數據后存儲到磁盤來保證持續性。

【編輯推薦】

1. MongoDB之父：MongoDB勝過BigTable
2. 主流NoSQL數據庫全方位評測之MongoDB
3. 教你如何利用MySQL學習MongoDB
4. 在Windows環境下MongoDB搭建和簡單操作
5. Mongodb源碼分析之Mongos分析