引子

　　作為企業架構師，我的職業習慣之一，就是不斷的探求各種新的有前景的概念和思想，看其是否有潛力為我所服務的來自各行各業的企業客戶帶來價值。同樣出于對這種理念的追求，我對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支出隨時都要仔細審查，以合理的成本獲取合理的質量才值得贊許。在這一領域中“非關系型數據庫”在一定程度上勝于傳統的數據庫，特別是當存儲和處理的數據容量很大時。

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

　　企業采用中所面臨的挑戰

　　拋開所有這些長遠的好處，在企業擁抱“非關系型數據庫”之前，當然還需要經歷各種各樣的挑戰。

　　不考慮因現有思想的轉換和缺乏信心而產生的來自高層的阻力，目前我認為的最主要的戰術性挑戰是：

　　為“非關系型數據庫”認定正確的應用/使用場景
　　盡管從理論上容易論證并非所有的企業數據都需要基于關系和ACID的系統，然而由于關系型數據庫與企業數據間多年的綁定關系，要作出所有的數據可以通過非關系的解決方案而解耦的決定仍然有很多困難。許多時候IT經理(以及其它對于應用程序負有核心的底線責任的各級人員)不明白他們將會失去什么，這樣的擔憂對于從關系型數據庫轉變出來比較不利。企業IT最有價值的資產就是數據。因此，要作出決定使用一種不太明確或者未被廣泛采用的解決方案來管理同樣的數據，這種能力不僅需要轉換思維方式，同時還需要來自高層的強大的支持(和推動)。

　　我們如何選擇最適合我們的產品/解決方案

　　另一個重大的挑戰是找出合適的產品/工具來提供“非關系型數據庫”。正如前面所提到的那樣，現今業界里面有多于25種不同的產品和解決方案，它們在四個方面有著不同的特點。正因為每個產品在這四個方面特點各異，所以要選擇一個產品來應對所有的需求顯得尤為困難。有的時候，可能在企業的不同部門使用到多種類型的非關系型數據庫，最后人們可能會完全出于對標準的需要而轉向關系型數據庫。

　　如何獲得規模經濟

　　這一想法本質上是從前一個問題分支出來的。如果一個組織需要使用多個非關系型數據庫解決方案(由于單個方案的適用問題)，那么保證在技術(開發者，管理者，支持人員)，基礎設施(硬件成本，軟件許可成本，支持成本，咨詢成本)，以及工件(公共組件和服務)方面的規模經濟就是一個大問題。這一方面與傳統的關系型數據庫解決方案比較起來確實更為嚴峻，因為大部分時間組織的數據存儲都是以共享服務的模式在運行的。

　　我們如何保證解決方案的可移植性

 　　從“非關系型數據庫”的發展來看，我們可以很直觀地推測在未來的幾年中這一領域會有許多變化，比如供應商的合并，功能的進步以及標準化。所以對于企業來說一個更好的策略是不要把寶押在某個特定的產品/解決方案上，以后才可以更靈活的轉換到一個更好的經過考驗的產品。由于現在的非關系型產品/解決方案大部分是私有的，因此IT決策者在考慮嘗試“非關系型數據庫”之前，不得不認真考慮可移植性這一重要的問題。這純粹是出于保護現有投資的需要。

　　我們如何獲得合適的產品支持類型

　　現在的“非關系型數據庫”能通過外部組織而提供支持方案的少之又少。就算有，也無法與Oracle，IBM或者微軟等相比。特別是在數據恢復，備份和特定的數據恢復方面，由于許多“非關系型數據庫”在這些方面未能提供一個健壯而易于使用的機制，對于企業決策者來說，仍存在很大的問題。

　　我們如何預算整體成本

　　與重量級的關系型數據庫相比，“非關系型數據庫”通常在性能和伸縮性特征方面能提供的數據更少。我也沒有發現有TPC基準程序方面和類似的其它方面的數據。這將企業決策者置于了一個“沒有方向”的情況下，因為他們不知道需要在硬件、軟件許可、基礎設施管理和支持等方面支出多大的費用。要得出一個預算估計，缺乏判斷的數據就成了一個主要的障礙。因此在項目啟動階段，大部分情況下決策者還是會選擇基于熟悉的關系型數據庫的解決方案。

　　有時候，就算可以得到這些數字，但也不足以用來形成TCO模型并與傳統的基于關系型數據庫的數據存儲和非關系型數據存儲進行整體的成本分析(Capex+Opex)比較。通常情況下水平伸縮性所要求的大量的硬件機器(以及軟件許可成本，支持成本)，如果與垂直伸縮性乍一比較，會讓人覺得戰戰兢兢，除非由此帶來的好處經過基于TCO模型的全方位比較仍然被證明是可以持續的。

　　關于如何采用NoSQL的兩點思考

　　這是否意味著目前來看企業應該對NoSQL運動持觀望的態度呢？并非如此。誠然，“非關系型數據庫”對于廣泛的采用來說還未到完全成熟的階段。但“非關系型數據庫”作為未來企業骨架的潛力仍不能忽視。特別是不遠的將來企業將更多地處理大容量的半結構化/非結構化以及最終一致性的數據，而不是相對而言小容量的，嚴格結構化的遵循ACID的數據。所以現在而言至關重要的是做企業的關鍵決策人的思想工作，讓他們明白企業的數據處理需要使用“非關系型數據庫”。在這一過程中，要采取一些漸進的步驟把“非關系型數據庫”應用到企業IT的一些關鍵的方面(技術，人員和流程)，并產生一定的價值。這樣，就可以用一種緩慢而穩健的方式從整體上來解決我們之前所總結出來的一系列問題。

　　采用一個產品/解決方案

　　如今市場上的選擇非常多樣化，可根據“非關系型數據庫”側重的面不同而進行差異化的處理。與此同時，企業應用場景可能需要不同類型的特點。然而以不同的解決方案來處理不同的應用/使用場景從規模經濟的角度出發對于企業是不適宜的。因此最好是根據目標應用的需要最終落實到某一個具體的產品/解決方案上。需要注意的是大多數的解決方案在特性上都會有一些折中，有些特性可能在其它的產品中可以獲得，有些可能只是在發展路線圖當中暫時設定了一個位置。因為大部分的產品會在不久的將來不斷趨于成熟，因此可以通過不同配置來提供不同的解決方案。所以只要現有的解決方案能適合目前大部分的需要，不妨作為一個起點將其采納。

　　選擇產品/解決方案的經驗法則

• 支持所需要的邏輯數據模型應當被給予更高的權重。這將從實質上決定該解決方案在當前或未來能否靈活地適應不同的業務需求。
• 調查該產品所支持的物理數據模型的合適與否，據此對這一解決方案所需要的水平伸縮性、可靠性、一致性和分區性作出合理的評估。這同樣能表明備份和恢復機制的可能性。
• 接口支持需要與企業標準的運行環境對齊。由于這些產品支持多樣的接口，所以這一點可以得到很好的處理。
• 只要產品支持水平伸縮性，對于持久化模型的選擇就不再重要了。

　　這里有一份一系列“非關系型數據庫”的對照表。對于現在正認真考慮采用的企業來說，這是一個不錯的起點。為了更貼近企業本身的情況，從25+的集合中挑選出的子集所用到的的關鍵選擇標準是：

1. 最重要的一點首先是企業應用程序必須支持有一定復雜程度的數據結構。否則的話，應用程序管理復雜性的責任將變得非常大。我認為比較合理的應當是介于純粹的鍵值對與關系型模式中間的一種方案。出于這方面的考慮像Vlodemort，Tokyo CabiNET等產品就排除在了我的列表之外。
2. 第二點是以低成本的分片/分區為大容量數據提供水平支持。缺乏這樣的支持就使得解決方案與任何關系型數據庫無異了。因此像Neo4J(盡管他有豐富的基于圖的模型)，Redis，CouchDB等此時此刻就被過濾出我的列表之外了。
3. 最后一條評判標準，在企業級推廣之前我會考慮一定程度的商業支持。否則的話，一旦出現生產環境的問題，我該去找誰呢？出于這一點，我不得不將現在的一些明星產品排除在外，比如Cassandra(盡管有很大的可能不久的將來Rackspace或者Cloudera就會對其提供支持，因為它已經被用于一些生產環境里邊了，比如Twitter，Digg，Facebook)。

　　有了這些過濾標準，我可以精簡這一列表，符合目前企業可用的產品有 MongoDB (下一版本就會提供shards支持)， Riak，Hypertable和HBase。下面這個表格中總結了這四個產品的主要特性。一個企業可以基于自己具體的實際情況從中作出選擇，找到最適合自己需要的特性。

　　數據訪問抽象

　　為數據訪問創建一個單獨的抽象層對于“非關系型數據庫”來說是必須的。它可以帶來多方面的好處。首先，應用開發者可以與底層解決方案的細節完全隔離開來。這對于技術方面的伸縮性帶來了好處。同時未來如果需要更改底層的解決方案也很方便。這也以一個標準的方式滿足了多個應用的要求(即去掉了Join，Group by等復雜特性的SQL)。

　　為性能和伸縮性創建模型

 　　不管選擇怎樣的解決方案，使用標準技術(比如排隊網絡模型，分層排隊網絡等)來對性能和伸縮性進行建模都是高度推薦的。它能夠為基本的服務器規劃、拓撲以及整體的軟件許可證成本，管理運行等提供必要的數據。這將實質上成為所有預算計劃的主要參考數據，并對作出決策提供幫助。

　　構建顯式的冗余

　　要防止數據丟失，除了將數據復制到備份服務器上，沒有其它的辦法了。盡管許多非關系型數據庫提供自動復制功能，但仍然存在主節點單點失效的風險。因此最好是使用次節點備份，并準備好用于數據恢復和自動數據修復的腳本。出于這樣的目的，應當充分的了解目標解決方案的物理數據模型，找出可能的恢復機制備選方案，基于企業的整體需求和實踐來對這些選項作出評估。

　　構建公共數據服務平臺

　　就像公共共享服務的關系型數據庫一樣，也可以構建非關系型數據庫的公共數據服務來促進規模經濟效應，滿足基礎設施和支持的需要。這對于未來進一步演化和更改也有幫助。這可以作為愿望列表上的最終目標，通過中期或長期的努力來達到這一成熟水平。然而，初始階段就設立這樣的遠景有助于在整個過程中作出正確的決策。

　　壯大企業的技術力量

　　每個組織都有一部分人對于學習新生的和非傳統的事物充滿熱忱。成立這樣的小組，并挑選人員(全職的或兼職的)，密切關注這方面的動向，了解問題和挑戰，進行前瞻性的思考，能夠為使用這些技術的項目提供方向和幫助。同時，這個小組還可以為決策者澄清炒作的疑云，提供來自真實數據的觀點。

　　建立與產品社區的關系

　　選擇了產品之后，與產品社區建立起良好的關系對于雙方的成功都有極大的好處。許多非關系型數據庫目前都有十分活躍的社區，非常愿意相互幫助。企業與社區之間的良好合作能給大家帶來一個雙贏的局面。如能提前對問題和解決方案有了解，那么企業在對某些特性或版本作出決策時就能成竹在胸。反過來，企業又能對產品特性的路線圖產生影響作用，這對他們自身和社區都是有利的。另一方面，社區也能從實際層次的問題中得到反饋，從而豐富和完善產品。來自大型企業的成功案例同樣能讓他們處于領先。

　　迭代前進

　　考慮到非關系型數據庫相對的成熟度，風險最小的采用策略就是遵循迭代開發的方法論。構建公共數據服務平臺和標準化數據訪問抽象不可能是一蹴而就的。相反，通過迭代和面向重構的方式能更好的達到目標。運用不太成熟的技術進行轉型的過程，中途改變解決方案也不會太意外的。與此同時，采用敏捷的方式來看待事物，能夠幫助建立起一個能從管理和實現兩方面不斷吸引改進的開放態度。

　　然而，在這一問題上實現迭代，非常重要的一點是定義一個決策條件矩陣。比如操作指南(和例子)，來判斷一個應用的對象模型是否適合關系型或非關系的范圍，對基礎設施規劃作出指導，列出必需的測試用例等等。

　　結束語

　　企業的非關系型數據庫采用過程中最大的挑戰就是轉變決策者的思想觀念——讓他們相信并非所有的數據/對象都適合關系型數據庫。最能證明這一點就是選擇合適的用例去嘗試非關系型數據庫，進而證實在合適的背景下，非關系型數據庫是比關系型數據庫更有效的解決方案。找到一些“非關鍵業務”(但能立竿見影的)適合于非關系型數據庫的項目。這些項目的成功(甚至失敗)都能有助于觀念的改變。這也能有助于不斷學習如何才能以一種不同的方式來更好的采用非關系型數據庫。這些少兒學步般的嘗試所作出的努力與投入都是值得的，如果企業想要在將來使用“非關系型數據庫”來重塑其信息管理體系的話。

　　關于作者

　　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，治理，性能建構和全球化。

it知識庫：企業中的NoSQL，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。