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