大數(shù)據(jù)浪潮襲來 企業(yè)該如何選擇NoSQL

在當(dāng)今這個大數(shù)據(jù)時代下，優(yōu)秀的傳統(tǒng)關(guān)系型數(shù)據(jù)庫管理系統(tǒng)已經(jīng)無法應(yīng)對很多數(shù)據(jù)庫處理任務(wù)。在今天的文章中，我們將一同探討如何在各類NoSQL后備方案中找到適合自己的選擇。

　　在過去幾個禮拜里，我一直在芝加哥為自己的公司部署衛(wèi)星辦公室。雖然硅谷確實算得上是大數(shù)據(jù)供應(yīng)商的搖籃，但芝加哥作為大數(shù)據(jù)用戶及從業(yè)者們的根據(jù)地、重要程度同樣不容忽視。無論是有心參與還是無意偶遇，這里的人們每一天都會跟大數(shù)據(jù)活動產(chǎn)生不少交集。在每一次大數(shù)據(jù)相關(guān)活動當(dāng)中，我們都不可避免地要與NoSQL打交道、議題也總會談到為什么傳統(tǒng)關(guān)系型數(shù)據(jù)庫管理系統(tǒng)已經(jīng)無法滿足如今的新需求。就目前來看，大部分讀者朋友對這一問題還不太熟悉。NoSQL數(shù)據(jù)庫分為幾大不同種類，我們擁有多種合理的出發(fā)點(diǎn)來針對不同數(shù)據(jù)集選用不同的NoSQL數(shù)據(jù)庫類型。總而言之，其實際復(fù)雜程度遠(yuǎn)遠(yuǎn)超出了技術(shù)業(yè)界在營銷中所宣稱的“NoSQL就是規(guī)?；薄oSQL數(shù)據(jù)庫種類如此眾多，部分原因可以歸結(jié)于CAP原理，又被稱為Brewer原理。

　　根據(jù)CAP原理的說法，在以下三種特性當(dāng)中我們只能同時實現(xiàn)兩者：一致性、可用性以及劃分限度。不同的數(shù)據(jù)集以及不同的運(yùn)行時間規(guī)則迫使我們采取不同的解決方案。各類數(shù)據(jù)庫技術(shù)針對的具體問題也有所區(qū)別。數(shù)據(jù)自身的復(fù)雜性以及系統(tǒng)的可擴(kuò)展能力都是需要認(rèn)真考慮的重要因素。

　　產(chǎn)生分歧的另一個理由則源自基礎(chǔ)計算機(jī)科學(xué)、甚至可以算是基礎(chǔ)數(shù)學(xué)運(yùn)算。某些數(shù)據(jù)集能夠輕松與鍵-值對進(jìn)行映射;從本質(zhì)上講，數(shù)據(jù)的表格化并不會削弱其實際意義，我們也沒有必要對數(shù)據(jù)關(guān)系進(jìn)行重組。在另一方面，數(shù)據(jù)集與其它數(shù)據(jù)項目間的關(guān)系可以說同數(shù)據(jù)項目本身一樣重要。

　　換句話來說，關(guān)系型數(shù)據(jù)庫在能夠作為鍵-值對處理的數(shù)據(jù)領(lǐng)域發(fā)揮極大效力，但卻不善于處理要求更多背景信息的數(shù)據(jù)。前者對可擴(kuò)展性提出要求，后者則需要我們?yōu)槠涮峁└嘈阅苜Y源。

　　關(guān)系型數(shù)據(jù)庫以關(guān)系代數(shù)為基礎(chǔ)，我們基本上可以將其視為集合論的衍生產(chǎn)物?；诩险摰年P(guān)系適用于多種數(shù)據(jù)集，但對于必須要求具備父-子或者關(guān)系距離要素的內(nèi)容來說效率不高。在這種情況下，大家可能需要采用圖論來設(shè)計數(shù)據(jù)解決方案。

　　鍵-值對數(shù)據(jù)庫

　　鍵-值對數(shù)據(jù)庫當(dāng)中包括Couchbase以及Apache Cassandra。這些方案具備高度可擴(kuò)展性，但卻無法幫助開發(fā)人員順暢處理復(fù)雜數(shù)據(jù)集。如果大家需要進(jìn)行磁盤備份、分布式散列表并通過一致性對數(shù)據(jù)內(nèi)容加以檢查，那么上述方案既具備良好的規(guī)?；芰?、又能提供出色的處理速度。然而如果我們需要通過某個鍵來獲取另一個鍵、進(jìn)而訪問第三個鍵以查詢相關(guān)值，那么問題就會變得非常復(fù)雜。

　　列族/大表數(shù)據(jù)庫

　　大部分鍵-值數(shù)據(jù)庫(包括Cassandra在內(nèi))都會提供某種形式的列組，我們可以將其理解為“列族”或者“大表”。而以HBase為代表的某些數(shù)據(jù)庫則從開發(fā)之初就以列族作為設(shè)計思路。這是鍵-值數(shù)據(jù)庫的一種更為先進(jìn)的表現(xiàn)形式。從本質(zhì)上講，其中的鍵與值 存在一定程度的復(fù)合。我們可以將其視為一套貫穿多維數(shù)組的散列映射?；久恳粋€列都容納著一行數(shù)據(jù)。根據(jù)DataStax公司(一家專門銷售Cassandra認(rèn)證版本的企業(yè))產(chǎn)品副總裁Robin Schumacher的觀點(diǎn)，“Cassandra人氣最高的使用實例就是處理時間序列數(shù)據(jù)，這些數(shù)據(jù)可以來自設(shè)備、傳感器、網(wǎng)站(例如Web日志)乃至金融記錄數(shù)據(jù)等等。這些數(shù)據(jù)的產(chǎn)生速度通常非常之快，而且往往一次性來自多個位置、增長幅度驚人，需要出色的寫入能力以及以時間片段為基礎(chǔ)的高性能讀取配。

　　大家也可以利用MapReduce來打理這類實例，這是因MapReduce最擅長的就是解析半結(jié)構(gòu)化數(shù)據(jù)。它們具備極高的可擴(kuò)展性，但通常不具備事務(wù)型處理能力。如果數(shù)據(jù)之間的關(guān)系與數(shù)據(jù)本身的重要性不相上下(例如距離或者路徑計算)，那么請不要使用列族/大表數(shù)據(jù)庫。

　　文檔數(shù)據(jù)庫

　　很多開發(fā)人員認(rèn)為文檔數(shù)據(jù)庫可以算是解決問題的靈藥，因為這類方案非常適合面向?qū)ο笮途幊獭?0gen(MongoDB)、Couchbase以及Apache CouchDB等發(fā)展迅猛的廠商都將此作為自己的起步平臺。來自Couchbase的Frank Weigel指出，該公司正在著手從1.8版本開始將原本的鍵-值數(shù)據(jù)庫轉(zhuǎn)化為2.0版本下的文檔數(shù)據(jù)庫。根據(jù)他的說法，“文檔數(shù)據(jù)庫屬于自然而然的發(fā)展趨勢。從集群化到數(shù)據(jù)訪問，文檔數(shù)據(jù)庫與鍵-值數(shù)據(jù)庫幾乎完全一致;惟一的區(qū)別在于，文檔數(shù)據(jù)庫能夠理解所存儲數(shù)據(jù)中的文檔內(nèi)容。”換句話來說，文檔數(shù)據(jù)庫會將值作為JSON、而JSON文檔中的元素則能夠通過檢索輕松進(jìn)行查詢與搜索。

　　在此類方案中，最理想的狀態(tài)就是大家可能已經(jīng)完成了JSON文檔的生成工作。正如10gen公司總裁Max Schireson在采訪中所說，如果大家的“數(shù)據(jù)太過復(fù)雜，以至于無法通過關(guān)系型數(shù)據(jù)庫進(jìn)行打理，那么應(yīng)該考慮嘗試文檔數(shù)據(jù)庫。舉例來說，一套復(fù)雜的衍生安全性實例可能很難以關(guān)系形式加以保存。電子健康記錄同樣面臨著這樣的問題。如果大家考慮利用XML方案，那么我強(qiáng)烈各位使用MongoDB——這種數(shù)據(jù)庫使用的正是JSON/BSON。”

　　這可能正是大家在企業(yè)運(yùn)作過程中遇到的實際情況——來自用戶、系統(tǒng)、社交網(wǎng)絡(luò)或者其它來源的數(shù)據(jù)不斷產(chǎn)生并紛至沓來。也許這些數(shù)據(jù)并不一定都是以報告的形式出現(xiàn)，但MongoDB等方案通常也會包含一定程度的MapReduce功能。至少在MongoDB當(dāng)中，大家可以對任何內(nèi)容加以查詢，而且即使不借助索引機(jī)制也不至于出現(xiàn)我們無法接受的性能問題。

　　圖形數(shù)據(jù)庫

　　圖形數(shù)據(jù)庫并不太關(guān)注數(shù)據(jù)規(guī)模或者可用性，而主要針對我們的數(shù)據(jù)之間存在怎樣的相關(guān)性以及用戶需要如何執(zhí)行計算任務(wù)。正如Neo Technologies公司(主要產(chǎn)品為Neo4j數(shù)據(jù)庫)產(chǎn)品工程高級主管Philip Rathle所說，圖形數(shù)據(jù)庫的威力主要體現(xiàn)在“數(shù)據(jù)集在本質(zhì)上存在關(guān)聯(lián)且非表格形式的情況下。其首要數(shù)據(jù)訪問模式采用事務(wù)型機(jī)制，即OLTP/記錄系統(tǒng)而非批量處理機(jī)制……請大家記住，圖形數(shù)據(jù)庫允許以事務(wù)性方式執(zhí)行關(guān)聯(lián)性操作，這一點(diǎn)在關(guān)系型數(shù)據(jù)庫管理系統(tǒng)領(lǐng)域只能通過批量處理來完成?！?/span>

　　這種特性在大部分NoSQL營銷活動中都得到了反復(fù)強(qiáng)調(diào)：我們選擇圖形數(shù)據(jù)庫的主要理由之一，就在于我們需要在自己的數(shù)據(jù)結(jié)構(gòu)中使用超出關(guān)系型數(shù)據(jù)庫能力范圍的準(zhǔn)確事務(wù)型處理方式。

　　圖形數(shù)據(jù)庫的常見用途包括地理空間計算、推薦引擎、網(wǎng)絡(luò)/云分析以及生物信息學(xué)——基本上，任何重視表達(dá)位置之間關(guān)系的數(shù)據(jù)都適合利用圖形數(shù)據(jù)庫進(jìn)行處理。這種技術(shù)在各類金融分析體系當(dāng)中同樣扮演著重要角色。如果大家希望了解某家企業(yè)的弱點(diǎn)或者“負(fù)面消息”，這種直接性關(guān)系將成為計算流程中的關(guān)鍵所在。要想通過查詢實現(xiàn)同樣的效果，我們不僅需要通過大量代碼編寫SQL查詢語句，其執(zhí)行速度也不會太快。相比之下，圖形數(shù)據(jù)庫顯然更擅長此類任務(wù)。

　　如果大家的數(shù)據(jù)內(nèi)容比較簡單或者已經(jīng)存在于表格當(dāng)中，那么實在沒必要使用圖形數(shù)據(jù)庫。另外，圖形數(shù)據(jù)庫也不太適合處理OLAP或者長度分析工作。通常情況下，圖形數(shù)據(jù)庫往往與索引機(jī)制緊密相連、從而實現(xiàn)更理想的搜索與查找效果，但圖形部分必須經(jīng)過遍歷;對于這一點(diǎn)，大家需要在一部分初始節(jié)點(diǎn)上加以修正。

　　概述：如何挑選？

　　圖形數(shù)據(jù)庫的出現(xiàn)很好地詮釋了為何開發(fā)人員很難為這些新的數(shù)據(jù)庫類型命名?！癗ewDB”是我個人最偏愛的名稱——當(dāng)然，某些與關(guān)系型數(shù)據(jù)庫管理系統(tǒng)同時代甚至更早的數(shù)據(jù)庫名稱也不錯。“NoSQL”這個名字就不太好，因為其中或多或少還是支持了一部分SQL功能，而且SQL與這些系統(tǒng)在功能性上也存在著某些交集。

　　最后，“大數(shù)據(jù)”這種描述也并非完全正確，因為我們并不一定要通過大型數(shù)據(jù)集來充分發(fā)揮這類數(shù)據(jù)庫方案的能力——只要它比關(guān)系型數(shù)據(jù)庫更適合即可?！胺顷P(guān)系型”也不準(zhǔn)確，因為圖形數(shù)據(jù)庫當(dāng)中同樣蘊(yùn)含著明確的關(guān)系結(jié)構(gòu);它們只不過遵循著與傳統(tǒng)關(guān)系型數(shù)據(jù)庫管理系統(tǒng)不同的關(guān)系邏輯。

　　事實上，這些只是一部分能夠解決我們特定難題的特定數(shù)據(jù)庫。過去十年以來，市場營銷策略總是喜歡把硬件規(guī)格、帶寬局限以及更理想的延遲及規(guī)模預(yù)期作為主要宣傳手段，旨在防止某些早期數(shù)據(jù)庫像關(guān)系型數(shù)據(jù)庫管理系統(tǒng)那樣遭受廣泛惡評。

　　正如我們不應(yīng)該嘗試?yán)猛惶?a href='/map/guanxixingshujuku/' style='color:#000;font-size:inherit;'>關(guān)系型數(shù)據(jù)庫管理系統(tǒng)解決全部難題，我們同樣不應(yīng)該嘗試?yán)眉险摫旧斫鉀Q所有數(shù)學(xué)問題。如今的數(shù)據(jù)難題正日趨復(fù)雜：可擴(kuò)展能力、性能表現(xiàn)(即低延遲)以及規(guī)?；枨笳掷m(xù)走高。為了滿足實際需求，我們需要調(diào)整思路、嘗試?yán)枚喾N數(shù)據(jù)庫技術(shù)完成不同背景下的具體任務(wù)。