一、“形散神聚”的分布式數(shù)據(jù)庫

很多人搞研究習(xí)慣性先去查一查百度百科，我們也效仿：“分布式數(shù)據(jù)庫系統(tǒng)通常使用較小的計(jì)算機(jī)系統(tǒng)，每臺計(jì)算機(jī)可單獨(dú)放在一個地方，每臺計(jì)算機(jī)中都可能有DBMS的一份完整拷貝副本，或者部分拷貝副本，并具有自己局部的數(shù)據(jù)庫，位于不同地點(diǎn)的許多計(jì)算機(jī)通過網(wǎng)絡(luò)互相連接，共同組成一個完整的、全局的邏輯上集中、物理上分布的大型數(shù)據(jù)庫。”

接下來，我們再來看看行業(yè)內(nèi)對它的認(rèn)識，在中國軟件測評中心牽頭下編制的《分布式數(shù)據(jù)庫發(fā)展路徑研究》當(dāng)中描述：“根據(jù)目前我國分布式數(shù)據(jù)庫技術(shù)現(xiàn)狀，我們認(rèn)為分布式數(shù)據(jù)庫是具備分布式事務(wù)處理能力、可平滑擴(kuò)展、分布于計(jì)算機(jī)網(wǎng)絡(luò)且邏輯上統(tǒng)一的數(shù)據(jù)庫，具有分布式事務(wù)處理、平滑拓展和物理分布、邏輯統(tǒng)一等特征。”

總結(jié)來看，我們認(rèn)為用“形散神聚”來描述分布式數(shù)據(jù)庫的特征最為貼切。所謂形散是指其表現(xiàn)出來的計(jì)算資源、分布空間、互聯(lián)拓?fù)涞确矫娴男问?，所謂神聚是指其最終在功能層面完成的數(shù)據(jù)處理能力。

二、分布式數(shù)據(jù)庫的發(fā)展歷史

我們不談太遠(yuǎn)了，從關(guān)系數(shù)據(jù)庫開始吧。20世紀(jì)70年代，IBM公司研究員E.F.Code首次提出了關(guān)系模型，開創(chuàng)了關(guān)系型數(shù)據(jù)庫的時代。80年代開始，第一批商業(yè)化的關(guān)系型數(shù)據(jù)庫開始誕生，例如Oracle、DB2、SQL Server等，90年代，芬蘭的一個工程師Michael Widenius推出了至今大小廠都在使用的MySQL，同一時期PostgreSQL也誕生了。2000年后，但是隨著數(shù)據(jù)量的增加，單機(jī)的數(shù)據(jù)庫瓶頸已經(jīng)不能滿足大數(shù)據(jù)量的需求，這時各種分庫分表的方案開始涌現(xiàn)。2006年谷歌發(fā)了三篇論文，也是被認(rèn)為的大數(shù)據(jù)三駕馬車“GFS、Big Table、Map-Reduce”。這三篇論文的思想誕生了Hadoop生態(tài)，也為分布式數(shù)據(jù)庫做好了鋪墊 。2012年谷歌又發(fā)表了兩篇論文，分別是Spanner和F1，為解決分布式數(shù)據(jù)庫的全局事務(wù)以及數(shù)據(jù)上的拆分提供了理論基礎(chǔ)。再往后就是國內(nèi)很多互聯(lián)網(wǎng)公司的分布式嘗試和發(fā)展，阿里巴巴、騰訊、百度、字節(jié)跳動、美團(tuán)、滴滴、快手、知乎、58等互聯(lián)網(wǎng)公司都已經(jīng)開始使用并且將自己的使用和研發(fā)成果形成產(chǎn)品推向市場，到了今天，以金融行業(yè)為先頭的各行各業(yè)的跟進(jìn)和普遍推廣階段。

三、分布式數(shù)據(jù)庫能解決什么問題？

1. 集中式關(guān)系數(shù)據(jù)庫遇到了什么困境？

（1）數(shù)據(jù)量的處理能力

其實(shí)從分布式數(shù)據(jù)庫的發(fā)展歷史上可以看出，是大數(shù)據(jù)催生的分布式數(shù)據(jù)庫的誕生和發(fā)展。最根本的問題就是數(shù)據(jù)量的升級導(dǎo)致了傳統(tǒng)關(guān)系型數(shù)據(jù)庫遇到了巨大的挑戰(zhàn)。傳統(tǒng)關(guān)系型數(shù)據(jù)庫在處理GB、TB量級的數(shù)據(jù)還是可以應(yīng)付的，但是一旦到了PB及以上級別的數(shù)據(jù)處理，就算單機(jī)硬件技術(shù)如何飛躍發(fā)展，單靠單節(jié)點(diǎn)的處理能力是無論如何也達(dá)不到業(yè)務(wù)所需要的效率目標(biāo)的。

（2）業(yè)務(wù)高并發(fā)處理能力

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

（3）數(shù)據(jù)及架構(gòu)的擴(kuò)展能力

伴隨著數(shù)據(jù)量和業(yè)務(wù)訪問的高并發(fā)變化趨勢，必然帶來的結(jié)果就是數(shù)據(jù)膨脹的速度比以往任何時代都要快，并且還無法準(zhǔn)確預(yù)測。另外一個結(jié)果就是與之相匹配的數(shù)據(jù)處理能力的提高。但是基于傳統(tǒng)集中式架構(gòu)的數(shù)據(jù)庫產(chǎn)品很難憑借基于點(diǎn)的縱向資源優(yōu)勢來滿足現(xiàn)實(shí)的需求，這就要求數(shù)據(jù)庫具備從架構(gòu)上到數(shù)據(jù)載體上都能擴(kuò)展橫向資源的能力，而且是安全的、簡單的、快速的。

（4）數(shù)據(jù)處理針對突發(fā)事件的適應(yīng)能力

互聯(lián)網(wǎng)發(fā)展到今天，幾乎各行各業(yè)都為之進(jìn)行了產(chǎn)業(yè)的升級換代，不僅越來越多的業(yè)務(wù)依托于互聯(lián)網(wǎng)，而且互聯(lián)網(wǎng)催生了很多新型的行業(yè)和經(jīng)濟(jì)?；ヂ?lián)網(wǎng)上每天都有有太多的不確定事件發(fā)生，以其快速的網(wǎng)絡(luò)傳播效益和影響廣度，很可能某些行業(yè)的相關(guān)業(yè)務(wù)就會受到其影響，例如明星事件。那么信息系統(tǒng)的承載能力以及數(shù)據(jù)的處理能力瞬間就會經(jīng)受前所未有的考驗(yàn)，這就要求數(shù)據(jù)庫同樣有很強(qiáng)的適應(yīng)能力。

（5）數(shù)據(jù)模型及訪問的匹配性

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

3.2 分布式數(shù)據(jù)庫技術(shù)為什么能沖出困境？

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

首先，具備了“形散神聚”特性的數(shù)據(jù)庫產(chǎn)品，它可以將分散的計(jì)算資源通過網(wǎng)絡(luò)聚合到一起，形成一個具備獨(dú)立數(shù)據(jù)存儲和處理能力的邏輯整體，也就具備了對海量數(shù)據(jù)的處理能力。

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

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

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

3.3 分布式數(shù)據(jù)庫技術(shù)解決不了什么樣的問題？

分布式數(shù)據(jù)庫既然有那么多優(yōu)點(diǎn)，那么它是不是萬能的？

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

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

四、企業(yè)該如何思考分布式數(shù)據(jù)庫之路？

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

1.以數(shù)據(jù)業(yè)務(wù)場景為基點(diǎn)，選擇技術(shù)路線。

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

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

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

3.不選最先進(jìn)，只選最合適。

業(yè)務(wù)場景對數(shù)據(jù)庫能力要求和側(cè)重點(diǎn)會有千差萬別。很難選擇一款通用型產(chǎn)品滿足全場景，那就需要根據(jù)實(shí)際情況做有針對性的選擇，適合自己場景的數(shù)據(jù)庫產(chǎn)品就是最優(yōu)的產(chǎn)品。不要認(rèn)為某個技術(shù)特性就是先進(jìn)的，代表未來發(fā)展趨勢的。?