NoSQL數(shù)據(jù)庫選型，DBA該考慮什么？
原創(chuàng)【51CTO外電頭條】我們?cè)?jīng)討論過“到底NoSQL能在我們的工作中發(fā)揮什么作用？”我們也在考慮如何選擇一款NoSQL數(shù)據(jù)庫方面提出過101個(gè)相關(guān)問題。我們甚至召開了一個(gè)在線研討會(huì)，深入剖析了SQL、NoSQL或者同時(shí)應(yīng)用兩者在網(wǎng)頁應(yīng)用程序的擴(kuò)展性方面能帶來哪些助益。
現(xiàn)在我們改變目標(biāo)，轉(zhuǎn)而思索哪些具體應(yīng)用因素會(huì)對(duì)選擇產(chǎn)生影響以及哪種系統(tǒng)在應(yīng)對(duì)此類因素時(shí)更加適用。
你有什么意見？
首先，我們先來聊聊各類數(shù)據(jù)模型。下列相關(guān)信息參考自Emil Eifrem的博文及NoSQL數(shù)據(jù)庫說明。
文檔類數(shù)據(jù)庫
傳承:受Lotus Notes啟發(fā)而來。
數(shù)據(jù)模型:文檔匯總，包括鍵-值匯總。
實(shí)例: CouchDB, MongoDB
優(yōu)勢(shì): 數(shù)據(jù)建模自然、程序員易于上手、開發(fā)流程短、兼容網(wǎng)頁模式、便于達(dá)成CRUD（即添加、查詢、更新及刪除的簡(jiǎn)稱）。
圖形類數(shù)據(jù)庫
傳承:來自 Euler 及圖形理論。
數(shù)據(jù)模型:節(jié)點(diǎn)及關(guān)系，二者結(jié)合能夠保持鍵-值間的成對(duì)狀態(tài)
實(shí)例: AllegroGraph, InfoGrid, Neo4j
優(yōu)勢(shì):輕松玩轉(zhuǎn)復(fù)雜的圖形問題、處理速度快
關(guān)系類數(shù)據(jù)庫
傳承:源自 E. F. Codd在大型共享數(shù)據(jù)庫中所提出的數(shù)據(jù)關(guān)系模型理論
數(shù)據(jù)模型:以關(guān)系組為基礎(chǔ)
實(shí)例: VoltDB, Clustrix, MySQL
優(yōu)勢(shì):性能強(qiáng)大、聯(lián)機(jī)事務(wù)處理系統(tǒng)擴(kuò)展性好、支持SQL訪問、視圖直觀、擅長處理交易關(guān)系、與程序員間的交互效果優(yōu)異
面向?qū)ο箢悢?shù)據(jù)庫
傳承:源自圖形數(shù)據(jù)庫方面的研究成果
數(shù)據(jù)模型: 對(duì)象
實(shí)例: Objectivity, Gemstone
優(yōu)勢(shì):擅長處理復(fù)雜的對(duì)象模型、快速的鍵-值訪問及鍵-功能訪問并且兼具圖形數(shù)據(jù)庫的各類功能
鍵-值存儲(chǔ)
傳承: Amazon Dynamo中的paper概念及分布式hash表
數(shù)據(jù)模型:對(duì)成對(duì)鍵-值的全局化匯總
實(shí)例: Membase, Riak
優(yōu)勢(shì):尺寸掌控得當(dāng)、擅長處理持續(xù)的小規(guī)模讀寫需求、速度快、程序員易于上手
BigTable Clones
傳承自:谷歌BigTable中的paper概念
數(shù)據(jù)模型:縱列群，即在某個(gè)表格模型中，每行在理論上至少可以有一套單獨(dú)的縱列配置
實(shí)例: HBase, Hypertable, Cassandra
優(yōu)勢(shì):尺寸掌控得當(dāng)、擅長應(yīng)對(duì)大規(guī)模寫入負(fù)載、可用性高、支持多數(shù)據(jù)中心、支持映射簡(jiǎn)化
數(shù)據(jù)結(jié)構(gòu)類服務(wù)
傳承: 不明
實(shí)例: Redis
數(shù)據(jù)模型: 執(zhí)行過程基于索引、列表、集合及字符串值
優(yōu)勢(shì):為數(shù)據(jù)庫應(yīng)用引入前所未有的新鮮血液
網(wǎng)格類數(shù)據(jù)庫
傳承:源自數(shù)據(jù)網(wǎng)格及元組空間研究
數(shù)據(jù)模型:基于空間的構(gòu)架
實(shí)例: GigaSpaces, Coherence
優(yōu)勢(shì):優(yōu)良的性能表現(xiàn)及上佳的交易處理擴(kuò)展性
我們?cè)摓樽约旱膽?yīng)用程序選擇哪套方案？
選擇的關(guān)鍵在于重新思考我們的應(yīng)用程序如何依據(jù)不同數(shù)據(jù)模型及不同產(chǎn)品進(jìn)行有針對(duì)性的協(xié)同工作。即用正確的數(shù)據(jù)模型處理對(duì)應(yīng)的現(xiàn)實(shí)任務(wù)、用正確的產(chǎn)品解決對(duì)應(yīng)的現(xiàn)實(shí)問題。
要探究哪類數(shù)據(jù)模型能夠切實(shí)為我們的應(yīng)用程序提供幫助，可以參考“到底NoSQL能在我們的工作中發(fā)揮什么作用？”一文。在這篇文章中，我試著將各種不同特性、不同功能的常用創(chuàng)建系統(tǒng)中的那些非常規(guī)的應(yīng)用實(shí)例綜合起來。
將應(yīng)用實(shí)例中的客觀需求與我們的選擇聯(lián)系起來。這樣大家就能夠逆向分析出我們的基礎(chǔ)架構(gòu)中適合引入哪些產(chǎn)品。至于具體結(jié)論是NoSQL還是SQL，這已經(jīng)不重要了。
關(guān)注數(shù)據(jù)模型、產(chǎn)品特性以及自身需要。產(chǎn)品總是將各種不同的功能集中起來，因此我們很難單純從某一類數(shù)據(jù)模型構(gòu)成方式的角度直接找到最合用的那款。
對(duì)功能及特性的需求存在優(yōu)先級(jí)，只要對(duì)這種優(yōu)先級(jí)具備較為清晰的了解，我們就能夠做出最佳選擇。
如果我們的應(yīng)用程序需要…
復(fù)雜的交易：因?yàn)闆]人愿意承受數(shù)據(jù)丟失，或者大家更傾向于一套簡(jiǎn)單易用的交易編程模式，那么請(qǐng)考慮使用關(guān)系類或網(wǎng)格類數(shù)據(jù)庫。
例如:一套庫存系統(tǒng)可能需要完整的ACID（即數(shù)據(jù)庫事務(wù)執(zhí)行四要素：原子性、一致性、隔離性及持久性）。顧客選中了一件產(chǎn)品卻被告知沒有庫存了，這類情況顯然容易引起麻煩。因?yàn)榇蠖鄶?shù)時(shí)候，我們想要的并不是額外補(bǔ)償、而只是選中的那件貨品。
若是以擴(kuò)展性為優(yōu)先，那么NoSQL或SQL都能應(yīng)對(duì)自如。這種情況下我們需要關(guān)注那些支持向外擴(kuò)展、分類處理、實(shí)時(shí)添加及移除設(shè)備、負(fù)載平衡、自動(dòng)分類及整理并且容錯(cuò)率較高的系統(tǒng)。
要求持續(xù)保有數(shù)據(jù)庫寫入功能，則需要較高的可用性。在這種情況下不妨關(guān)注BigTable類產(chǎn)品，其在一致性方面表現(xiàn)出眾。
如有大量的小規(guī)模持續(xù)讀寫要求，也就是說工作負(fù)載處于波動(dòng)狀態(tài)，可以關(guān)注文檔類、鍵-值類或是那些提供快速內(nèi)存訪問功能的數(shù)據(jù)庫。引入固態(tài)硬盤作為存儲(chǔ)媒介也是不錯(cuò)的選擇。
以社交網(wǎng)絡(luò)為實(shí)施重點(diǎn)的話，我們首先想到的就是圖形類數(shù)據(jù)庫；其次則是Riak這種關(guān)系類數(shù)據(jù)庫。具備簡(jiǎn)單SQL功能的常駐內(nèi)存式關(guān)系數(shù)據(jù)庫基本上就可以滿足小型數(shù)據(jù)集合的需求。Redis的集合及列表操作也能發(fā)揮作用。
如果我們的應(yīng)用程序需要…
在訪問模式及數(shù)據(jù)類型多種多樣的情況下，文檔類數(shù)據(jù)庫比較值得考慮。這類數(shù)據(jù)庫不僅靈活性好，性能表現(xiàn)也可圈可點(diǎn)。
需要完備的脫機(jī)報(bào)告與大型數(shù)據(jù)集的話，首選產(chǎn)品是Hadoop，其次則是支持映射簡(jiǎn)化的其它產(chǎn)品。不過僅僅支持映射簡(jiǎn)化還不足以提供如Hadoop一樣上佳的處理能力。
如果業(yè)務(wù)跨越數(shù)個(gè)數(shù)據(jù)中心，Bigtable Clone及其它提供分布式選項(xiàng)的產(chǎn)品能夠應(yīng)對(duì)由地域距離引起的延遲現(xiàn)象，并具備較好的分區(qū)兼容性。
要建立CRUD應(yīng)用程序，首選文檔類數(shù)據(jù)庫。這類產(chǎn)品簡(jiǎn)化了從外部訪問復(fù)雜數(shù)據(jù)的過程。需要內(nèi)置搜索功能的話，推薦Riak。
要對(duì)數(shù)據(jù)結(jié)構(gòu)中的諸如列表、集合、隊(duì)列及發(fā)布/訂閱信息進(jìn)行操作，Redis是不二之選。其具備的分布式鎖定、覆蓋式日志及其它各種功能都會(huì)在這類應(yīng)用狀態(tài)下大放異彩。
將數(shù)據(jù)以便于處理的形式反饋給程序員（例如以JSON、HTTP、REST、Javascript這類形式），文檔類數(shù)據(jù)庫能夠滿足這類訴求，鍵-值類數(shù)據(jù)庫效果次之。
如果我們的應(yīng)用程序需要…
以直觀視圖的形式進(jìn)行同步交易，并且具備實(shí)時(shí)數(shù)據(jù)反饋功能，VoltDB算得上一把好手。其數(shù)據(jù)匯總以及時(shí)間窗口化的表現(xiàn)都非常搶眼。
若是需要企業(yè)級(jí)的支持及服務(wù)水平協(xié)議，我們需要著眼于特殊市場(chǎng)。Membase就是這樣一個(gè)例子。
要記錄持續(xù)的數(shù)據(jù)流，卻找不到必要的一致性保障？BigTable Clone交出了令人滿意的答卷，因?yàn)槠涔ぷ骰诜植际轿募到y(tǒng)，所以可以應(yīng)對(duì)大量的寫入操作。
要讓操作過程變得盡可能簡(jiǎn)單，答案一定在托管或平臺(tái)即服務(wù)類方案之中。它們存在的目的正是處理這類要求。
要向企業(yè)級(jí)客戶做出推薦？不妨考慮關(guān)系類數(shù)據(jù)庫，因?yàn)樗鼈兊拈L項(xiàng)就是具備解決繁雜關(guān)系問題的技術(shù)。
如果需要利用動(dòng)態(tài)方式建立對(duì)象之間的關(guān)系以使其具有動(dòng)態(tài)特性，圖形類數(shù)據(jù)庫能幫上大忙。這類產(chǎn)品往往不需要特定的模式及模型，因此可以通過編程逐步建立。
S3這類存儲(chǔ)服務(wù)則是為支持大型媒體信息而生。相比之下NoSQL系統(tǒng)則往往無法處理大型二進(jìn)制數(shù)據(jù)塊，盡管MongoDB本身具備文件服務(wù)功能。
如果我們的應(yīng)用程序需要…
有高效批量上傳大量數(shù)據(jù)的需求？我們還是得找點(diǎn)有對(duì)應(yīng)功能的產(chǎn)品。大多數(shù)產(chǎn)品都無法勝任，因?yàn)樗鼈儾恢С峙坎僮鳌?/p>
文檔類數(shù)據(jù)庫或是鍵－值類數(shù)據(jù)庫能夠利用流暢的模式化系統(tǒng)提供便捷的上傳途徑，因?yàn)檫@兩類產(chǎn)品不僅支持可選區(qū)域、添加區(qū)域及刪除區(qū)域，而且無需建立完整的模式遷移框架。
要實(shí)現(xiàn)完整性限制，就得選擇一款支持SQL DLL的產(chǎn)品，并在存儲(chǔ)過程或是應(yīng)用程序代碼中加以運(yùn)行。
對(duì)于協(xié)同工作極為依賴的時(shí)候就要選擇圖形類數(shù)據(jù)庫，因?yàn)檫@類產(chǎn)品支持在不同實(shí)體間的迅速切換。
數(shù)據(jù)的移動(dòng)距離較短且不必經(jīng)過網(wǎng)絡(luò)時(shí)，可以在預(yù)存程序中做出選擇。預(yù)存程序在關(guān)系類、網(wǎng)格類、文檔類甚至是鍵-值類數(shù)據(jù)庫中都能找到。
如果我們的應(yīng)用程序需要…
鍵-值存儲(chǔ)體系擅長處理BLOB類數(shù)據(jù)的緩存及存儲(chǔ)問題。緩存可以用于應(yīng)對(duì)網(wǎng)頁或復(fù)雜對(duì)象的存儲(chǔ)，這種方案能夠降低延遲、并且比起使用關(guān)系類數(shù)據(jù)庫來說成本也較低。
對(duì)于數(shù)據(jù)安全及工作狀態(tài)要求較高的話可以嘗試使用定制產(chǎn)品，并且在普遍的工作范疇（例如向上擴(kuò)展、調(diào)整、分布式緩存、分區(qū)及反規(guī)范化等等）之外一定要為擴(kuò)展性（或其它方面）準(zhǔn)備解決方案。
多樣化的數(shù)據(jù)類型意味著我們的數(shù)據(jù)不能簡(jiǎn)單用表格來管理或是用縱列來劃分，其復(fù)雜的結(jié)構(gòu)及用戶組成（也可能還有其它各種因素）只有文檔類、鍵-值類以及Bigtable Clone這些數(shù)據(jù)庫才能應(yīng)付。上述各類數(shù)據(jù)庫都具備極為靈活的數(shù)據(jù)類型處理能力。
有時(shí)其它業(yè)務(wù)部門會(huì)需要進(jìn)行快速關(guān)系查詢，引入這種查詢方式可以使我們不必為了偶爾的查看而重建一切信息。任何支持SQL的數(shù)據(jù)庫都能實(shí)現(xiàn)這類查詢。至于在云平臺(tái)上運(yùn)行并自動(dòng)充分利用云平臺(tái)的功能——這種美好的愿望目前還只能是愿望。
如果我們的應(yīng)用程序需要…
支持輔助索引，以便通過不同的關(guān)鍵詞查找數(shù)據(jù)，這要由關(guān)系類數(shù)據(jù)庫及Cassandra推出的新輔助索引系統(tǒng)共同支持才能實(shí)現(xiàn)。
創(chuàng)建一套處于不斷增長中的數(shù)據(jù)集合（真正天文數(shù)量級(jí)的數(shù)據(jù)）然而訪問量卻并不大，那么Bigtable Clone是最佳選擇，因?yàn)樗鼤?huì)將數(shù)據(jù)妥善安排在分布式文件系統(tǒng)當(dāng)中。
需要整合其它類型的服務(wù)并確保數(shù)據(jù)庫提供延后寫入同步功能？那最好的實(shí)現(xiàn)方式是捕捉數(shù)據(jù)庫的各種變化并將其反饋到其它系統(tǒng)中以保障運(yùn)作的一致性。
通過容錯(cuò)性檢查了解系統(tǒng)對(duì)供電中斷、隔離及其它故障情況的適應(yīng)程度。
若是當(dāng)前的某項(xiàng)技術(shù)尚無人問津、自己卻感覺大有潛力可挖，不妨在這條路上堅(jiān)持走下去。這種情況有時(shí)會(huì)帶來意料之外的美好前景。
嘗試在移動(dòng)平臺(tái)上工作并關(guān)注CouchDB及移動(dòng)版couchbase。
哪種方案更好？
25%的狀態(tài)改善尚不足以讓我們下決心選擇NoSQL。
選擇標(biāo)準(zhǔn)是否恰當(dāng)取決于實(shí)際情況。這類標(biāo)準(zhǔn)對(duì)你的方案有指導(dǎo)意義嗎？
如果你的公司尚處于起步階段，并且需要盡快推出自己的產(chǎn)品，這時(shí)不要再猶豫不決了。無論是SQL還是NoSQL都可以作為參考。
性能表現(xiàn)在一臺(tái)主機(jī)上來說也許差別并不大，但如果我們要將其部署在N多臺(tái)主機(jī)上呢？
世上萬物皆不完美，如果大家常逛Amazon論壇就會(huì)發(fā)現(xiàn)上面的EBS響應(yīng)緩慢，當(dāng)然沒準(zhǔn)我這屬于特例。不過GAE的數(shù)據(jù)存儲(chǔ)體系響應(yīng)也很緩慢，有時(shí)甚至干脆顯示紅叉。每種我們使用著的產(chǎn)品都存在諸多問題，但對(duì)于自己親手選擇的方案，你能接受它所存在的問題嗎？
原文標(biāo)題：35+ Use Cases for Choosing Your Next NoSQL Database
【編輯推薦】
