引子

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

　　什么是NoSQL——快速回顧

　　像許多關(guān)注這一領(lǐng)域的人一樣，我不喜歡從本質(zhì)上將SQL與NoSQL這一術(shù)語(yǔ)對(duì)立起來(lái)。同時(shí)我對(duì)該術(shù)語(yǔ)現(xiàn)有的解釋"Not Only SQL"也不甚滿(mǎn)意。對(duì)我來(lái)說(shuō)，我們這里所討論的并非是是否使用SQL。(相反的是，我們?nèi)匀豢梢赃x擇類(lèi)似SQL這樣的查詢(xún)接口(缺少對(duì)join等的支持)來(lái)與這些數(shù)據(jù)庫(kù)交互，使用現(xiàn)有的資源和技術(shù)來(lái)管理開(kāi)發(fā)伸縮性和可維護(hù)性。)這一運(yùn)動(dòng)是要找到存儲(chǔ)和檢索數(shù)據(jù)的其他高效的途徑，而不是盲目地在任何情況下都把關(guān)系數(shù)據(jù)庫(kù)當(dāng)作萬(wàn)金油。因此，我認(rèn)為'Non Relational Database'(非關(guān)系型數(shù)據(jù)庫(kù))能夠更好的表達(dá)這一思想。
　　無(wú)論采用哪個(gè)名字，“非關(guān)系型數(shù)據(jù)庫(kù)”這一范圍所傳達(dá)出來(lái)的“囊括所有”類(lèi)型的意味，使得這一概念比較模糊(并且它還是否定型的)。這又使得人們(特別是企業(yè)中的決策者)對(duì)于哪些是屬于這個(gè)范圍，哪些不是，更重要的是，對(duì)他們來(lái)說(shuō)這到底意味著什么，感到非常迷惑。
　　為了解答這些疑問(wèn)，我嘗試通過(guò)以下幾點(diǎn)特征的描述，來(lái)刻畫(huà)“非關(guān)系型數(shù)據(jù)庫(kù)”的內(nèi)在本質(zhì)。
　　所謂“非關(guān)系型數(shù)據(jù)庫(kù)”指的是

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

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

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

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

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

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

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

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

　　上圖總結(jié)了現(xiàn)今以web為中心的企業(yè)中信息管理的新興模式。而“非關(guān)系型數(shù)據(jù)庫(kù)”是處理這些趨勢(shì)的最佳選擇(較之關(guān)系型數(shù)據(jù)庫(kù)來(lái)說(shuō))，提供了對(duì)非結(jié)構(gòu)化數(shù)據(jù)的支持，擁有支持分區(qū)的水平伸縮性，支持高可用性等等。
　　以下是支持這一觀點(diǎn)的一些實(shí)際應(yīng)用場(chǎng)景：

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

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

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

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

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

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

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

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

　　業(yè)務(wù)靈活性——更短的周轉(zhuǎn)時(shí)間
　　“非關(guān)系型數(shù)據(jù)庫(kù)”能夠以?xún)煞N基本的方式帶來(lái)業(yè)務(wù)靈活性。

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

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

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

　　更低的所有者總成本

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　數(shù)據(jù)訪問(wèn)抽象

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

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

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

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

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

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

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

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

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

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

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

　　迭代前進(jìn)

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

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

　　結(jié)束語(yǔ)

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

　　關(guān)于作者

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

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

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

it知識(shí)庫(kù)：企業(yè)中的NoSQL，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。