企業在什麼情況下引入分散式資料庫？

一、“形散神聚”的分散式資料庫

很多人搞研究習慣性先去查一查百度百科，我們也效仿：“分散式資料庫系統通常使用較小的計算機系統，每臺計算機可單獨放在一個地方，每臺計算機中都可能有DBMS的一份完整複製副本，或者部分複製副本，並具有自己區域性的資料庫，位於不同地點的許多計算機透過網路互相連線，共同組成一個完整的、全域性的邏輯上集中、物理上分佈的大型資料庫。”

接下來，我們再來看看行業內對它的認識，在中國軟體測評中心牽頭下編制的《分散式資料庫發展路徑研究》當中描述：“根據目前我國分散式資料庫技術現狀，我們認為分散式資料庫是具備分散式事務處理能力、可平滑擴充套件、分佈於計算機網路且邏輯上統一的資料庫，具有分散式事務處理、平滑擴充和物理分佈、邏輯統一等特徵。”

總結來看，我們認為用“形散神聚”來描述分散式資料庫的特徵最為貼切。所謂形散是指其表現出來的計算資源、分佈空間、互聯拓撲等方面的形式，所謂神聚是指其最終在功能層面完成的資料處理能力。

二、分散式資料庫的發展歷史

我們不談太遠了，從關聯式資料庫開始吧。20世紀70年代，IBM公司研究員E.F.Code首次提出了關係模型，開創了關係型資料庫的時代。80年代開始，第一批商業化的關係型資料庫開始誕生，例如Oracle、DB2、SQL Server等，90年代，芬蘭的一個工程師Michael Widenius推出了至今大小廠都在使用的MySQL，同一時期PostgreSQL也誕生了。2000年後，但是隨著資料量的增加，單機的資料庫瓶頸已經不能滿足大資料量的需求，這時各種分庫分表的方案開始湧現。2006年穀歌發了三篇論文，也是被認為的大資料三駕馬車“GFS、Big Table、Map-Reduce”。這三篇論文的思想誕生了Hadoop生態，也為分散式資料庫做好了鋪墊 。2012年穀歌又發表了兩篇論文，分別是Spanner和F1，為解決分散式資料庫的全域性事務以及資料上的拆分提供了理論基礎。再往後就是國內很多網際網路公司的分散式嘗試和發展，阿里巴巴、騰訊、百度、位元組跳動、美團、滴滴、快手、知乎、58等網際網路公司都已經開始使用並且將自己的使用和研發成果形成產品推向市場，到了今天，以金融行業為先頭的各行各業的跟進和普遍推廣階段。

三、分散式資料庫能解決什麼問題?

3.1 集中式關聯式資料庫遇到了什麼困境?

(一)資料量的處理能力

其實從分散式資料庫的發展歷史上可以看出，是大資料催生的分散式資料庫的誕生和發展。最根本的問題就是資料量的升級導致了傳統關係型資料庫遇到了巨大的挑戰。傳統關係型資料庫在處理GB、TB量級的資料還是可以應付的，但是一旦到了PB及以上級別的資料處理，就算單機硬體技術如何飛躍發展，單靠單節點的處理能力是無論如何也達不到業務所需要的效率目標的。

(二)業務高併發處理能力

隨著網際網路的不斷髮展，從起初的電子商務到現在的各種網際網路模式(工業網際網路、網際網路金融、網際網路社交、...)，支撐這些業務的資料庫必須具備對分散業務請求的高併發處理能力，同時還得保障資料的基本安全屬性。這也是堅持CAP理論當中C&A極致的關係型資料庫所不具備的特性。

(三)資料及架構的擴充套件能力

伴隨著資料量和業務訪問的高併發變化趨勢，必然帶來的結果就是資料膨脹的速度比以往任何時代都要快，並且還無法準確預測。另外一個結果就是與之相匹配的資料處理能力的提高。但是基於傳統集中式架構的資料庫產品很難憑藉基於點的縱向資源優勢來滿足現實的需求，這就要求資料庫具備從架構上到資料載體上都能擴充套件橫向資源的能力，而且是安全的、簡單的、快速的。

(四)資料處理針對突發事件的適應能力

網際網路發展到今天，幾乎各行各業都為之進行了產業的升級換代，不僅越來越多的業務依託於網際網路，而且網際網路催生了很多新型的行業和經濟。網際網路上每天都有有太多的不確定事件發生，以其快速的網路傳播效益和影響廣度，很可能某些行業的相關業務就會受到其影響，例如明星事件。那麼資訊系統的承載能力以及資料的處理能力瞬間就會經受前所未有的考驗，這就要求資料庫同樣有很強的適應能力。

(五)資料模型及訪問的匹配性

在集中式關聯式資料庫盛世的年代，各行各業對資料的需求基本以結構化二維表形式為主，以少量的非結構化或半結構化資料為輔。但是在今天這個資料飛速發展變化的時代，資料從表示形式、訪問特點、存取效率上都發生了巨大的變化。表示形式上，從二維表模型擴充到文件、鍵值、列式、圖等多種型別;訪問特點上，出現了只讀不寫、只寫不讀等各種特殊業務;存取效率上，出現了各種需要記憶體級效率的海量檢索業務。這就要求根據資料模型及訪問特點來匹配正確的資料庫型別，而不能再用通用的思維了。

3.2 分散式資料庫技術為什麼能衝出困境?

在分析分散式資料庫技術為什麼能解決傳統關係型資料庫解決不了的問題之前，我們需要先明確我們所講的分散式資料庫不是一個或者一類資料庫，它應該是具備了“形散神聚”特性的所有資料庫的集合。

首先，具備了“形散神聚”特性的資料庫產品，它可以將分散的計算資源透過網路聚合到一起，形成一個具備獨立資料儲存和處理能力的邏輯整體，也就具備了對海量資料的處理能力。

其次，具備了“形散神聚”特性的資料庫產品，追求的是CAP理論當中的A&P，降低了對C的期望值。這樣放棄強一致性，退而求其次的弱一致性，必然具備將資料的處理由物理上的集中轉化為邏輯上的集中的能力，也就具備了高併發的處理能力。

再次，具備了“形散神聚”特性的資料庫產品，天然具備很好的擴充套件性和適應性。因為這種資料庫的物理節點本來就是分散的，它是依靠資料庫本身的軟體機制將其組合到一起形成有機整體。因此，增加減少節點或者容量對於它來講是一個再正常不過的操作了，只不過需要考慮的是在擴充套件和變化的過程當中資料量遷移的量級和效能問題。

最後，分散式資料庫本身不是一個或者一類產品，在這些產品當中，從資料模型到資料訪問特點上都會有很多專注型的資料庫產品，比如文件類的MongoDB，比如支援記憶體訪問的Redis，比如支援大資料處理的Hbase。與傳統的關係型資料庫相比而言，這些分散式資料庫其實更專注於某些特殊資料模型或者資料訪問場景的資料處理能力，因此從此意義上講，分散式資料庫更適合某些特殊場景下的資料處理，其與特殊場景的匹配性更強。

3.3 分散式資料庫技術解決不了什麼樣的問題?

分散式資料庫既然有那麼多優點，那麼它是不是萬能的?

首先，從分散式資料庫的概念上來講，它並不聚焦在通用場景，而是聚焦在某些特殊的資料訪問場景上，那麼拿到通用場景上或者其他與之屬性不相匹配的場景上，它必然有很多缺陷。比如資料遷移演算法的複雜性和合理性方面、資料模型的不匹配性、資料持久化的缺陷等等。但是就某個特殊場景的技術特性分析來講，必然能找到更適合的分散式資料庫產品。但是就分散式資料庫這種“形散神聚”的共性特點來講，是否有場景必然從分散式資料庫當中找不到相應的“菜”呢?

成也蕭何敗蕭何，優勢在“形散神聚”上，致命的缺陷也在這個上面。這種特性必然導致它在嚴格事務性要求的業務場景下不能完成使命。儘管不斷有人透過婉轉的解決方法來彌補這一點，例如“兩階段事務處理方案”，但是這也是在某些有事務容忍度的業務場景下可以勉強採用。對於事務要求零容忍度的交易類業務場景，還得回到傳統的集中式關係型資料庫上。

四、企業該如何思考分散式資料庫之路?

綜上所述，企業在如何選擇分散式資料庫的技術抉擇上，個人覺得應該遵循以下幾個原則：

一、以資料業務場景為基點，選擇技術路線。

沒有哪一種技術路線能絕對代表未來趨勢，任何技術路線都是服務於業務場景的需求。因此我們選擇技術路線的時候，必然要從分析業務場景的資料模型特點、資料訪問特點以及資料存取效率三方面來剖析需求方面的屬性，然後再去用這些分析出來的結果去匹配適合的資料庫技術路線。

二、不迷信宣傳，相信自己的技術分析和測試。

技術路線的把控是一個非常嚴肅的事情。第三方的評測和廠商宣傳結論，但這些只能做參考，暫不提廣告效益的影響，就單單選型來講，別人的選擇不一定適合自己企業，就算行業相近也有資料量大小多少以及訪問量的區分。所以在廣泛參考的基礎之上還是要分析和測試。

三、不選最先進，只選最合適。

業務場景對資料庫能力要求和側重點會有千差萬別。很難選擇一款通用型產品滿足全場景，那就需要根據實際情況做有針對性的選擇，適合自己場景的資料庫產品就是最優的產品。不要認為某個技術特性就是先進的，代表未來發展趨勢的。