ivaneeo's blog

引子

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

什么是NoSQL——快速回顧

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

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

為了解答這些疑問，我嘗試通過以下幾點(diǎn)特征的描述，來刻畫“非關(guān)系型數(shù)據(jù)庫”的內(nèi)在本質(zhì)。

所謂“非關(guān)系型數(shù)據(jù)庫”指的是

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

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

接口——REST (HBase，CouchDB，Riak等)，MapReduce (HBase，CouchDB，MongoDB，Hypertable等)，Get/Put (Voldemort，Scalaris等)，Thrift (HBase，Hypertable，Cassandra等)，語言特定的API(MongoDB)。

邏輯數(shù)據(jù)模型——面向鍵值對的(Voldemort，Dynomite 等)，面向Column Family的(BigTable，HBase，Hypertable 等)，面向文檔的(Couch DB，MongoDB等)，面向圖的(Neo4j， Infogrid等)

數(shù)據(jù)分布模型——一致性和可用性(HBase，Hypertable， MongoDB等)， 可用性和可分區(qū)性(Cassandra等)。一致性和可分區(qū)性的組合會導(dǎo)致一些非額定的節(jié)點(diǎn)產(chǎn)生可用性的損失。有趣的是目前還沒有一個(gè)“非關(guān)系型數(shù)據(jù)庫”支持這一組合。

數(shù)據(jù)持久性——基于內(nèi)存的(如Redis，Scalaris， Terrastore)，基于磁盤的(如MongoDB，Riak等)，或內(nèi)存及磁盤二者的結(jié)合(如HBase，Hypertable，Cassandra)。存儲的類型有助于我們辨別該解決方案適用于哪種類型。然而，在大多數(shù)情況下人們發(fā)現(xiàn)基于組合方案的解決方案是最佳的選擇。既能通過內(nèi)存數(shù)據(jù)存儲支持高性能，又能在寫入足夠多的數(shù)據(jù)后存儲到磁盤來保證持續(xù)性。

如何將其與企業(yè)IT融合

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

上圖總結(jié)了現(xiàn)今以web為中心的企業(yè)中信息管理的新興模式。而“非關(guān)系型數(shù)據(jù)庫” 是處理這些趨勢的最佳選擇(較之關(guān)系型數(shù)據(jù)庫來說)，提供了對非結(jié)構(gòu)化數(shù)據(jù)的支持，擁有支持分區(qū)的水平伸縮性，支持高可用性等等。

以下是支持這一觀點(diǎn)的一些實(shí)際應(yīng)用場景：

日志挖掘——集群里的多個(gè)節(jié)點(diǎn)都會產(chǎn)生服務(wù)器日志、應(yīng)用程序日志和用戶活動日志等。對于解決生產(chǎn)環(huán)境中的問題，日志挖掘工具非常有用，它能訪問跨服務(wù)器的日志記錄，將它們關(guān)聯(lián)起來并進(jìn)行分析。使用“非關(guān)系型數(shù)據(jù)庫”來定制這樣的解決方案將會非常容易。

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

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

高容量的EAI系統(tǒng)——許多企業(yè)的EAI系統(tǒng)都有高容量傳輸流(不管是基于產(chǎn)品的還是定制開發(fā)的)。出于可靠性和審計(jì)的目的，這些通過EAI系統(tǒng)的消息流通常都需要持久化。對于這一場景，“非關(guān)系型數(shù)據(jù)庫” 再次體現(xiàn)出它十分適用于底層的數(shù)據(jù)存儲，只要能給定環(huán)境中源系統(tǒng)和目標(biāo)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)更改和所需的容量。

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

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

合并和收購——企業(yè)在合并與收購中面臨巨大的挑戰(zhàn)，因?yàn)樗麄冃枰獙⑦m應(yīng)于相同功能的系統(tǒng)整合起來。“非關(guān)系型數(shù)據(jù)庫” 可解決這一問題，不管是快速地組成一個(gè)臨時(shí)的公共數(shù)據(jù)存儲，或者是架構(gòu)一個(gè)未來的數(shù)據(jù)存儲來調(diào)和合并的公司之間現(xiàn)有公共應(yīng)用程序的結(jié)構(gòu)。

但我們?nèi)绾尾拍軠?zhǔn)確的描述，相對于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，企業(yè)使用“非關(guān)系型數(shù)據(jù)庫”帶來的好處呢？下面是可通過非關(guān)系型數(shù)據(jù)庫的核心特點(diǎn)(正如上一節(jié)所討論的)而獲得的一些主要的好處，即企業(yè)的任何IT決策都會參考的核心參數(shù)——成本削減，更好的周轉(zhuǎn)時(shí)間和更優(yōu)良的質(zhì)量。

業(yè)務(wù)靈活性——更短的周轉(zhuǎn)時(shí)間

“非關(guān)系型數(shù)據(jù)庫”能夠以兩種基本的方式帶來業(yè)務(wù)靈活性。

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

更佳的終端用戶體驗(yàn)——更優(yōu)越的質(zhì)量

在現(xiàn)今企業(yè)IT中，應(yīng)用的質(zhì)量主要由終端用戶的滿意度來決定。“非關(guān)系型數(shù)據(jù)庫”通過解決如下終端用戶的考慮因素，能夠達(dá)到同樣的效果，而這些因素也是最容易發(fā)生和最難以處理的。

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

更低的所有者總成本

在如今的競爭市場中，企業(yè)IT支出隨時(shí)都要仔細(xì)審查，以合理的成本獲取合理的質(zhì)量才值得贊許。在這一領(lǐng)域中“非關(guān)系型數(shù)據(jù)庫”在一定程度上勝于傳統(tǒng)的數(shù)據(jù)庫，特別是當(dāng)存儲和處理的數(shù)據(jù)容量很大時(shí)。

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

企業(yè)采用中所面臨的挑戰(zhàn)

拋開所有這些長遠(yuǎn)的好處，在企業(yè)擁抱“非關(guān)系型數(shù)據(jù)庫”之前，當(dāng)然還需要經(jīng)歷各種各樣的挑戰(zhàn)。

不考慮因現(xiàn)有思想的轉(zhuǎn)換和缺乏信心而產(chǎn)生的來自高層的阻力，目前我認(rèn)為的最主要的戰(zhàn)術(shù)性挑戰(zhàn)是：

為“非關(guān)系型數(shù)據(jù)庫”認(rèn)定正確的應(yīng)用/使用場景

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

我們?nèi)绾芜x擇最適合我們的產(chǎn)品/解決方案

另一個(gè)重大的挑戰(zhàn)是找出合適的產(chǎn)品/工具來提供“非關(guān)系型數(shù)據(jù)庫”。正如前面所提到的那樣，現(xiàn)今業(yè)界里面有多于25種不同的產(chǎn)品和解決方案，它們在四個(gè)方面有著不同的特點(diǎn)。正因?yàn)槊總€(gè)產(chǎn)品在這四個(gè)方面特點(diǎn)各異，所以要選擇一個(gè)產(chǎn)品來應(yīng)對所有的需求顯得尤為困難。有的時(shí)候，可能在企業(yè)的不同部門使用到多種類型的非關(guān)系型數(shù)據(jù)庫，最后人們可能會完全出于對標(biāo)準(zhǔn)的需要而轉(zhuǎn)向關(guān)系型數(shù)據(jù)庫。

如何獲得規(guī)模經(jīng)濟(jì)

這一想法本質(zhì)上是從前一個(gè)問題分支出來的。如果一個(gè)組織需要使用多個(gè)非關(guān)系型數(shù)據(jù)庫解決方案(由于單個(gè)方案的適用問題)，那么保證在技術(shù)(開發(fā)者，管理者，支持人員)，基礎(chǔ)設(shè)施(硬件成本，軟件許可成本，支持成本，咨詢成本)，以及工件(公共組件和服務(wù))方面的規(guī)模經(jīng)濟(jì)就是一個(gè)大問題。這一方面與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫解決方案比較起來確實(shí)更為嚴(yán)峻，因?yàn)榇蟛糠謺r(shí)間組織的數(shù)據(jù)存儲都是以共享服務(wù)的模式在運(yùn)行的。

我們?nèi)绾伪ＷC解決方案的可移植性

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

我們?nèi)绾潍@得合適的產(chǎn)品支持類型

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

我們?nèi)绾晤A(yù)算整體成本

與重量級的關(guān)系型數(shù)據(jù)庫相比，“非關(guān)系型數(shù)據(jù)庫”通常在性能和伸縮性特征方面能提供的數(shù)據(jù)更少。我也沒有發(fā)現(xiàn)有TPC基準(zhǔn)程序方面和類似的其它方面的數(shù)據(jù)。這將企業(yè)決策者置于了一個(gè)“沒有方向”的情況下，因?yàn)樗麄儾恢佬枰谟布④浖S可、基礎(chǔ)設(shè)施管理和支持等方面支出多大的費(fèi)用。要得出一個(gè)預(yù)算估計(jì)，缺乏判斷的數(shù)據(jù)就成了一個(gè)主要的障礙。因此在項(xiàng)目啟動階段，大部分情況下決策者還是會選擇基于熟悉的關(guān)系型數(shù)據(jù)庫的解決方案。

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

關(guān)于如何采用NoSQL的兩點(diǎn)思考

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

采用一個(gè)產(chǎn)品/解決方案

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

選擇產(chǎn)品/解決方案的經(jīng)驗(yàn)法則

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

這里有一份一系列“非關(guān)系型數(shù)據(jù)庫”的對照表。對于現(xiàn)在正認(rèn)真考慮采用的企業(yè)來說，這是一個(gè)不錯(cuò)的起點(diǎn)。為了更貼近企業(yè)本身的情況，從25+的集合中挑選出的子集所用到的的關(guān)鍵選擇標(biāo)準(zhǔn)是：

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

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

數(shù)據(jù)訪問抽象

為數(shù)據(jù)訪問創(chuàng)建一個(gè)單獨(dú)的抽象層對于“非關(guān)系型數(shù)據(jù)庫”來說是必須的。它可以帶來多方面的好處。首先，應(yīng)用開發(fā)者可以與底層解決方案的細(xì)節(jié)完全隔離開來。這對于技術(shù)方面的伸縮性帶來了好處。同時(shí)未來如果需要更改底層的解決方案也很方便。這也以一個(gè)標(biāo)準(zhǔn)的方式滿足了多個(gè)應(yīng)用的要求(即去掉了Join，Group by等復(fù)雜特性的SQL)。

為性能和伸縮性創(chuàng)建模型

不管選擇怎樣的解決方案，使用標(biāo)準(zhǔn)技術(shù)(比如排隊(duì)網(wǎng)絡(luò)模型，分層排隊(duì)網(wǎng)絡(luò)等)來對性能和伸縮性進(jìn)行建模都是高度推薦的。它能夠?yàn)榛镜姆?wù)器規(guī)劃、拓?fù)湟约罢w的軟件許可證成本，管理運(yùn)行等提供必要的數(shù)據(jù)。這將實(shí)質(zhì)上成為所有預(yù)算計(jì)劃的主要參考數(shù)據(jù)，并對作出決策提供幫助。

構(gòu)建顯式的冗余

要防止數(shù)據(jù)丟失，除了將數(shù)據(jù)復(fù)制到備份服務(wù)器上，沒有其它的辦法了。盡管許多非關(guān)系型數(shù)據(jù)庫提供自動復(fù)制功能，但仍然存在主節(jié)點(diǎn)單點(diǎn)失效的風(fēng)險(xiǎn)。因此最好是使用次節(jié)點(diǎn)備份，并準(zhǔn)備好用于數(shù)據(jù)恢復(fù)和自動數(shù)據(jù)修復(fù)的腳本。出于這樣的目的，應(yīng)當(dāng)充分的了解目標(biāo)解決方案的物理數(shù)據(jù)模型，找出可能的恢復(fù)機(jī)制備選方案，基于企業(yè)的整體需求和實(shí)踐來對這些選項(xiàng)作出評估。

構(gòu)建公共數(shù)據(jù)服務(wù)平臺

就像公共共享服務(wù)的關(guān)系型數(shù)據(jù)庫一樣，也可以構(gòu)建非關(guān)系型數(shù)據(jù)庫的公共數(shù)據(jù)服務(wù)來促進(jìn)規(guī)模經(jīng)濟(jì)效應(yīng)，滿足基礎(chǔ)設(shè)施和支持的需要。這對于未來進(jìn)一步演化和更改也有幫助。這可以作為愿望列表上的最終目標(biāo)，通過中期或長期的努力來達(dá)到這一成熟水平。然而，初始階段就設(shè)立這樣的遠(yuǎn)景有助于在整個(gè)過程中作出正確的決策。

壯大企業(yè)的技術(shù)力量

每個(gè)組織都有一部分人對于學(xué)習(xí)新生的和非傳統(tǒng)的事物充滿熱忱。成立這樣的小組，并挑選人員(全職的或兼職的)，密切關(guān)注這方面的動向，了解問題和挑戰(zhàn)，進(jìn)行前瞻性的思考，能夠?yàn)槭褂眠@些技術(shù)的項(xiàng)目提供方向和幫助。同時(shí)，這個(gè)小組還可以為決策者澄清炒作的疑云，提供來自真實(shí)數(shù)據(jù)的觀點(diǎn)。

建立與產(chǎn)品社區(qū)的關(guān)系

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

迭代前進(jìn)

考慮到非關(guān)系型數(shù)據(jù)庫相對的成熟度，風(fēng)險(xiǎn)最小的采用策略就是遵循迭代開發(fā)的方法論。構(gòu)建公共數(shù)據(jù)服務(wù)平臺和標(biāo)準(zhǔn)化數(shù)據(jù)訪問抽象不可能是一蹴而就的。相反，通過迭代和面向重構(gòu)的方式能更好的達(dá)到目標(biāo)。運(yùn)用不太成熟的技術(shù)進(jìn)行轉(zhuǎn)型的過程，中途改變解決方案也不會太意外的。與此同時(shí)，采用敏捷的方式來看待事物，能夠幫助建立起一個(gè)能從管理和實(shí)現(xiàn)兩方面不斷吸引改進(jìn)的開放態(tài)度。

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

結(jié)束語

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

關(guān)于作者

Sourav Mazumder目前是InfoSys Technologies的首席技術(shù)架構(gòu)師。他在信息技術(shù)領(lǐng)域有14年以上的經(jīng)驗(yàn)。作為Infosys技術(shù)顧問團(tuán)的主要成員，Sourav為Infosys在美國、歐洲、澳洲和日本的主要客戶，提供保險(xiǎn)、電信、銀行、零售、安全、交通以及建筑、工程、施工等多個(gè)行業(yè)的服務(wù)。 他曾參與Web項(xiàng)目的技術(shù)架構(gòu)和路線圖定義，SOA戰(zhàn)略實(shí)施，國際戰(zhàn)略定義，UI組件化，性能建模，伸縮性分析，非結(jié)構(gòu)化數(shù)據(jù)管理等等。Sourav參考的Infosys自身的核心銀行產(chǎn)品Finacle，也為他提供了豐富的產(chǎn)品開發(fā)經(jīng)驗(yàn)。Sourav還曾參與開發(fā)Infosys的J2EE可重用框架，和定義Infosys在架構(gòu)方面和開發(fā)定制應(yīng)用方面的軟件工程方法。Sourav的經(jīng)歷還包括在保證架構(gòu)合規(guī)和開發(fā)項(xiàng)目的治理方面的工作。

Sourav是iCMG認(rèn)證的軟件架構(gòu)師，同時(shí)也是TOGAF 8認(rèn)證的執(zhí)行者。Sourav最近在LISA伯克利全球化會議上發(fā)表了演講。Sourav關(guān)于SOA的最新白皮書在社區(qū)里十分流行。

Sourav目前關(guān)注NoSQL，Web 2.0，治理，性能建構(gòu)和全球化。

感謝馬國耀對本文的審校。

給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家加入到InfoQ中文站用戶討論組中與我們的編輯和其他讀者朋友交流。