一、“形散神聚”的分布式數據庫

很多人搞研究習慣性先去查一查百度百科，我們也效仿：“分布式數據庫系統通常使用較小的計算機系統，每臺計算機可單獨放在一個地方，每臺計算機中都可能有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等互聯網公司都已經開始使用并且將自己的使用和研發成果形成產品推向市場，到了今天，以金融行業為先頭的各行各業的跟進和普遍推廣階段。

三、分布式數據庫能解決什么問題？

1. 集中式關系數據庫遇到了什么困境？

(1) 數據量的處理能力

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

(2) 業務高并發處理能力

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

(3) 數據及架構的擴展能力

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

(4) 數據處理針對突發事件的適應能力

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

(5) 數據模型及訪問的匹配性

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

2. 分布式數據庫技術為什么能沖出困境？

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

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

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

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

最后，分布式數據庫本身不是一個或者一類產品，在這些產品當中，從數據模型到數據訪問特點上都會有很多專注型的數據庫產品，比如文檔類的MongoDB，比如支持內存訪問的Redis，比如支持大數據處理的Hbase。與傳統的關系型數據庫相比而言，這些分布式數據庫其實更專注于某些特殊數據模型或者數據訪問場景的數據處理能力，因此從此意義上講，分布式數據庫更適合某些特殊場景下的數據處理，其與特殊場景的匹配性更強。

3. 分布式數據庫技術解決不了什么樣的問題？

分布式數據庫既然有那么多優點，那么它是不是萬能的？

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

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

四、企業該如何思考分布式數據庫之路？

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

(1) 以數據業務場景為基點，選擇技術路線。

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

(2) 不迷信宣傳，相信自己的技術分析和測試。

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

(3) 不選最先進，只選最合適。

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