引子

　　作為企業架構師，我的職業習慣之一，就是不斷的探求各種新的有前景的概念和思想，看其是否有潛力為我所服務的來自各行各業的企業客戶帶來價值。同樣出于對這種理念的追求，我對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)。存儲的類型有助于我們辨別該解決方案適用于哪種類型。然而，在大多數情況下人們發現基于組合方案的解決方案是最佳的選擇。既能通過內存數據存儲支持高性能，又能在寫入足夠多的數據后存儲到磁盤來保證持續性。

　　如何將其與企業IT融合

　　如今的企業中，并非所有用例都直觀地傾向于使用關系型數據庫，或者都需要嚴格的ACID屬性(特別是一致性和隔離性)。在80年代及90年代，絕大部分存儲在企業數據庫里的數據都是結構化的業務事務的“記錄”，必須用受控的方式來生成或訪問，而如今它已一去不復返了。無可爭辯的是，仍有這一類型的數據在那里，并將繼續也應該通過關系型數據庫來建模，存儲和訪問。但對于過去15年以來，隨著Web的發展，電子商務和社交計算的興起所引起的企業里不受控的非結構化并且面向信息的數據大爆炸，該如何應對呢？企業確實不需要關系型數據庫來管理這些數據，因為關系型數據庫的特點決定了它不適用于這些數據的性質和使用方式。

　　上圖總結了現今以web為中心的企業中信息管理的新興模式。而“非關系型數據庫”是處理這些趨勢的最佳選擇(較之關系型數據庫來說)，提供了對非結構化數據的支持，擁有支持分區的水平伸縮性，支持高可用性等等。
　　以下是支持這一觀點的一些實際應用場景：

• 日志挖掘——集群里的多個節點都會產生服務器日志、應用程序日志和用戶活動日志等。對于解決生產環境中的問題，日志挖掘工具非常有用，它能訪問跨服務器的日志記錄，將它們關聯起來并進行分析。使用“非關系型數據庫”來定制這樣的解決方案將會非常容易。

• 分析社交計算——許多企業如今都為用戶(內部用戶、客戶和合作伙伴)提供通過消息論壇，博客等方式來進行社交計算的能力。挖掘這些非結構化的數據對于獲得用戶的喜好偏向以及進一步提升服務有著至關重要的作用。使用“非關系型數據庫”可以很好的解決這一需求。

• 外部數據feed聚合——許多情況下企業需要消費來自合作伙伴的數據。顯然，就算經過了多輪的討論和協商，企業對于來自合作伙伴的數據的格式仍然沒有發言權。同時，許多情況下，基于合作伙伴業務的變更，這些數據格式也頻繁的發生變化。通過“非關系型數據庫”來開發或定制一個ETL解決方案能夠非常成功的解決這一問題。

• 高容量的EAI系統——許多企業的EAI系統都有高容量傳輸流(不管是基于產品的還是定制開發的)。出于可靠性和審計的目的，這些通過EAI系統的消息流通常都需要持久化。對于這一場景，“非關系型數據庫”再次體現出它十分適用于底層的數據存儲，只要能給定環境中源系統和目標系統的數據結構更改和所需的容量。

• 前端訂單處理系統——隨著電子商務的膨脹，通過不同渠道流經零售商、銀行和保險供應商、娛樂服務供應商、物流供應商等等的訂單、應用、服務請求的容量十分巨大。同時，由于不同渠道的所關聯的行為模式的限制，每種情況下系統所使用的信息結構都有所差異，需要加上不同的規則類型。在此之上，絕大部分數據不需要即時的處理和后端對帳。所需要的是，當終端用戶想要從任何地方推送這些數據時，這些請求都能夠被捕獲并且不會被打斷。隨后，通常會有一個對帳系統將其更新到真正的后端源系統并更新終端用戶的訂單狀態。這又是一個可以應用“非關系型數據庫”的場景，可用于初期存儲終端用戶的輸入。這一場景是體現“非關系型數據庫”的應用的極佳例子，它具有高容量，異構的輸入數據類型和對帳的"最終一致性"等等特點。

• 企業內容管理服務——出于各種各樣的目的，內容管理在企業內部得到了廣泛的應用，橫跨多個不同的功能部門比如銷售、市場、零售和人力資源等。企業大多數時間所面臨的挑戰是用一個公共的內容管理服務平臺，將不同部門的需求整合到一起，而它們的元數據是各不相同的。這又是“非關系型數據庫”發揮作用的地方。

• 合并和收購——企業在合并與收購中面臨巨大的挑戰，因為他們需要將適應于相同功能的系統整合起來。“非關系型數據庫”可解決這一問題，不管是快速地組成一個臨時的公共數據存儲，或者是架構一個未來的數據存儲來調和合并的公司之間現有公共應用程序的結構。

　　但我們如何才能準確的描述，相對于傳統的關系型數據庫，企業使用“非關系型數據庫”帶來的好處呢？下面是可通過非關系型數據庫的核心特點(正如上一節所討論的)而獲得的一些主要的好處，即企業的任何IT決策都會參考的核心參數——成本削減，更好的周轉時間和更優良的質量。

　　業務靈活性——更短的周轉時間
　　“非關系型數據庫”能夠以兩種基本的方式帶來業務靈活性。

• 模式自由的邏輯數據模型有助于在為任何業務進行調整時帶來更快的周轉時間，把對現有應用和功能造成影響減到最少。在大多數情況下因任意的變更而給你帶來的遷移工作幾乎為零。
• 水平伸縮性能夠在當越來越多的用戶負載造成負載周期性變化，或者應用突然變更的使用模式時，提供堅固的保障。面向水平伸縮性的架構也是邁向基于SLA構建(例如云)的第一步，這樣才能保證在不斷變化的使用情形下業務的延續性。

　　更佳的終端用戶體驗——更優越的質量
　　在現今企業IT中，應用的質量主要由終端用戶的滿意度來決定。“非關系型數據庫”通過解決如下終端用戶的考慮因素，能夠達到同樣的效果，而這些因素也是最容易發生和最難以處理的。

• “非關系型數據庫”為提升應用的性能帶來了極大的機會。分布式數據的核心概念是保證磁盤I/O(尋道速率)絕不能成為應用性能的瓶頸。盡管性能更多的是由傳輸速率來決定。在此之上，絕大部分解決方案支持各種不同的新一代的高速計算的范式，比如MapReduce，排序列，Bloom Filter，僅可追加的B樹，Memtable等。
• 現今用戶滿意度的另一個重要的方面就是可靠性。終端用戶希望在想要訪問應用時就能訪問到，并且至少是在當他們分配到時間的時候能隨時執行他們的任務。所以不可用的應用需要不惜代價的避免。許多現代的“非關系型數據庫”都能適應并支持這一類有著嚴格和最終一致性的可用性的需求。

　　更低的所有者總成本

　　在如今的競爭市場中，企業IT支出隨時都要仔細審查，以合理的成本獲取合理的質量才值得贊許。在這一領域中“非關系型數據庫”在一定程度上勝于傳統的數據庫，特別是當存儲和處理的數據容量很大時。

• 水平伸縮性的基本前提保證了它們可以運行于廉價機器之上。這不僅削減了硬件資本的成本，同時還削減了諸如電力，維護等運維成本。同時這還進一步的為利用諸如云、虛擬數據中心等下一代低成本的基礎設施打下了基礎。
• 從長期來看，更少的維護能帶來更多的運維成本優勢。對于關系型數據庫，這絕對是一個需要存儲大容量數據的場景。為大容量的數據調優數據庫需要高超的技藝，也就意味著更高的成本。相較之下，“非關系型數據庫”始終提供快速和響應的特點，就算是在數據大幅上升的情況下。索引和緩存也以同樣的方式工作。開發者不必過多擔心硬件、磁盤、重新索引及文件布局等，而是把更多的精力投入了應用程序的開發上。