在當今這個大數據時代下，優秀的傳統關系型數據庫管理系統已經無法應對很多數據庫處理任務。在今天的文章中，我們將一同探討如何在各類NoSQL后備方案中找到適合自己的選擇。
在過去幾個禮拜里，我一直在芝加哥為自己的公司部署衛星辦公室。雖然硅谷確實算得上是大數據供應商的搖籃，但芝加哥作為大數據用戶及從業者們的根據地、重要程度同樣不容忽視。無論是有心參與還是無意偶遇，這里的人們每一天都會跟大數據活動產生不少交集。在每一次大數據相關活動當中，我們都不可避免地要與NoSQL打交道、議題也總會談到為什么傳統關系型數據庫管理系統已經無法滿足如今的新需求。就目前來看，大部分讀者朋友對這一問題還不太熟悉。NoSQL數據庫分為幾大不同種類，我們擁有多種合理的出發點來針對不同數據集選用不同的NoSQL數據庫類型。總而言之，其實際復雜程度遠遠超出了技術業界在營銷中所宣稱的“NoSQL就是規模化”。NoSQL數據庫種類如此眾多，部分原因可以歸結于CAP原理，又被稱為Brewer原理。
根據CAP原理的說法，在以下三種特性當中我們只能同時實現兩者：一致性、可用性以及劃分限度。不同的數據集以及不同的運行時間規則迫使我們采取不同的解決方案。各類數據庫技術針對的具體問題也有所區別。數據自身的復雜性以及系統的可擴展能力都是需要認真考慮的重要因素。
產生分歧的另一個理由則源自基礎計算機科學、甚至可以算是基礎數學運算。某些數據集能夠輕松與鍵-值對進行映射;從本質上講，數據的表格化并不會削弱其實際意義，我們也沒有必要對數據關系進行重組。在另一方面，數據集與其它數據項目間的關系可以說同數據項目本身一樣重要。
換句話來說，關系型數據庫在能夠作為鍵-值對處理的數據領域發揮極大效力，但卻不善于處理要求更多背景信息的數據。前者對可擴展性提出要求，后者則需要我們為其提供更多性能資源。
關系型數據庫以關系代數為基礎，我們基本上可以將其視為集合論的衍生產物。基于集合論的關系適用于多種數據集，但對于必須要求具備父-子或者關系距離要素的內容來說效率不高。在這種情況下，大家可能需要采用圖論來設計數據解決方案。
鍵-值對數據庫
鍵-值對數據庫當中包括Couchbase以及Apache Cassandra。這些方案具備高度可擴展性，但卻無法幫助開發人員順暢處理復雜數據集。如果大家需要進行磁盤備份、分布式散列表并通過一致性對數據內容加以檢查，那么上述方案既具備良好的規模化能力、又能提供出色的處理速度。然而如果我們需要通過某個鍵來獲取另一個鍵、進而訪問第三個鍵以查詢相關值，那么問題就會變得非常復雜。
列族/大表數據庫
大部分鍵-值數據庫(包括Cassandra在內)都會提供某種形式的列組，我們可以將其理解為“列族”或者“大表”。而以HBase為代表的某些數據庫則從開發之初就以列族作為設計思路。這是鍵-值數據庫的一種更為先進的表現形式。從本質上講，其中的鍵與值 存在一定程度的復合。我們可以將其視為一套貫穿多維數組的散列映射。基本每一個列都容納著一行數據。根據DataStax公司(一家專門銷售Cassandra認證版本的企業)產品副總裁Robin Schumacher的觀點，“Cassandra人氣最高的使用實例就是處理時間序列數據，這些數據可以來自設備、傳感器、網站(例如Web日志)乃至金融記錄數據等等。這些數據的產生速度通常非常之快，而且往往一次性來自多個位置、增長幅度驚人，需要出色的寫入能力以及以時間片段為基礎的高性能讀取配。
大家也可以利用MapReduce來打理這類實例，這是因MapReduce最擅長的就是解析半結構化數據。它們具備極高的可擴展性，但通常不具備事務型處理能力。如果數據之間的關系與數據本身的重要性不相上下(例如距離或者路徑計算)，那么請不要使用列族/大表數據庫。
文檔數據庫
很多開發人員認為文檔數據庫可以算是解決問題的靈藥，因為這類方案非常適合面向對象型編程。10gen(MongoDB)、Couchbase以及Apache CouchDB等發展迅猛的廠商都將此作為自己的起步平臺。來自Couchbase的Frank Weigel指出，該公司正在著手從1.8版本開始將原本的鍵-值數據庫轉化為2.0版本下的文檔數據庫。根據他的說法，“文檔數據庫屬于自然而然的發展趨勢。從集群化到數據訪問，文檔數據庫與鍵-值數據庫幾乎完全一致;惟一的區別在于，文檔數據庫能夠理解所存儲數據中的文檔內容。”換句話來說，文檔數據庫會將值作為JSON、而JSON文檔中的元素則能夠通過檢索輕松進行查詢與搜索。
在此類方案中，最理想的狀態就是大家可能已經完成了JSON文檔的生成工作。正如10gen公司總裁Max Schireson在采訪中所說，如果大家的“數據太過復雜，以至于無法通過關系型數據庫進行打理，那么應該考慮嘗試文檔數據庫。舉例來說，一套復雜的衍生安全性實例可能很難以關系形式加以保存。電子健康記錄同樣面臨著這樣的問題。如果大家考慮利用XML方案，那么我強烈各位使用MongoDB——這種數據庫使用的正是JSON/BSON。”
這可能正是大家在企業運作過程中遇到的實際情況——來自用戶、系統、社交網絡或者其它來源的數據不斷產生并紛至沓來。也許這些數據并不一定都是以報告的形式出現，但MongoDB等方案通常也會包含一定程度的MapReduce功能。至少在MongoDB當中，大家可以對任何內容加以查詢，而且即使不借助索引機制也不至于出現我們無法接受的性能問題。
圖形數據庫
圖形數據庫并不太關注數據規模或者可用性，而主要針對我們的數據之間存在怎樣的相關性以及用戶需要如何執行計算任務。正如Neo Technologies公司(主要產品為Neo4j數據庫)產品工程高級主管Philip Rathle所說，圖形數據庫的威力主要體現在“數據集在本質上存在關聯且非表格形式的情況下。其首要數據訪問模式采用事務型機制，即OLTP/記錄系統而非批量處理機制……請大家記住，圖形數據庫允許以事務性方式執行關聯性操作，這一點在關系型數據庫管理系統領域只能通過批量處理來完成。”
這種特性在大部分NoSQL營銷活動中都得到了反復強調：我們選擇圖形數據庫的主要理由之一，就在于我們需要在自己的數據結構中使用超出關系型數據庫能力范圍的準確事務型處理方式。
圖形數據庫的常見用途包括地理空間計算、推薦引擎、網絡/云分析以及生物信息學——基本上，任何重視表達位置之間關系的數據都適合利用圖形數據庫進行處理。這種技術在各類金融分析體系當中同樣扮演著重要角色。如果大家希望了解某家企業的弱點或者“負面消息”，這種直接性關系將成為計算流程中的關鍵所在。要想通過查詢實現同樣的效果，我們不僅需要通過大量代碼編寫SQL查詢語句，其執行速度也不會太快。相比之下，圖形數據庫顯然更擅長此類任務。
如果大家的數據內容比較簡單或者已經存在于表格當中，那么實在沒必要使用圖形數據庫。另外，圖形數據庫也不太適合處理OLAP或者長度分析工作。通常情況下，圖形數據庫往往與索引機制緊密相連、從而實現更理想的搜索與查找效果，但圖形部分必須經過遍歷;對于這一點，大家需要在一部分初始節點上加以修正。
概述：如何挑選？
圖形數據庫的出現很好地詮釋了為何開發人員很難為這些新的數據庫類型命名。“NewDB”是我個人最偏愛的名稱——當然，某些與關系型數據庫管理系統同時代甚至更早的數據庫名稱也不錯。“NoSQL”這個名字就不太好，因為其中或多或少還是支持了一部分SQL功能，而且SQL與這些系統在功能性上也存在著某些交集。
最后，“大數據”這種描述也并非完全正確，因為我們并不一定要通過大型數據集來充分發揮這類數據庫方案的能力——只要它比關系型數據庫更適合即可。“非關系型”也不準確，因為圖形數據庫當中同樣蘊含著明確的關系結構;它們只不過遵循著與傳統關系型數據庫管理系統不同的關系邏輯。
事實上，這些只是一部分能夠解決我們特定難題的特定數據庫。過去十年以來，市場營銷策略總是喜歡把硬件規格、帶寬局限以及更理想的延遲及規模預期作為主要宣傳手段，旨在防止某些早期數據庫像關系型數據庫管理系統那樣遭受廣泛惡評。
正如我們不應該嘗試利用同一套關系型數據庫管理系統解決全部難題，我們同樣不應該嘗試利用集合論本身解決所有數學問題。如今的數據難題正日趨復雜：可擴展能力、性能表現(即低延遲)以及規模化需求正持續走高。為了滿足實際需求，我們需要調整思路、嘗試利用多種數據庫技術完成不同背景下的具體任務。
作者Andrew C. Oliver是一位專業cat herder，同時兼任軟件咨詢顧問。他最廣為人知的成就是創立了POI項目，如今該項目已經由Apache接手。他還曾是JBoss早期開發團隊的成員之一。
京公網安備 11010502049343號