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