昨天的文章發(fā)了以后有朋友就懷疑這文章是給集中式數(shù)據(jù)庫(kù)廠商打call的，實(shí)際上我只是從一個(gè)相對(duì)客觀的角度把我對(duì)分布式數(shù)據(jù)庫(kù)的個(gè)人見(jiàn)解寫(xiě)出來(lái)了。同樣對(duì)于這個(gè)話題，分布式數(shù)據(jù)庫(kù)的擁躉也可以寫(xiě)出一篇比較客觀的文章，觀點(diǎn)看上去完全不同。是不是很奇妙，怎么會(huì)存在兩種截然不同的事實(shí)呢？如果你了解過(guò)陽(yáng)明心學(xué)，從表象和物本質(zhì)的理論來(lái)看這件事，就能理解了。實(shí)際上我們講述的都不是事實(shí)，不是物本質(zhì)。事實(shí)只有一個(gè)，我們所看到的只是表象，描述的只是觀點(diǎn)，而不是事實(shí)本身。我們的描述可以十分接近事實(shí)，但永遠(yuǎn)也無(wú)法變成事實(shí)?；诖耍恍┛此泼艿摹拜^為正確的觀點(diǎn)”就會(huì)存在了。實(shí)際上我們都是在盲人摸象，為分布式數(shù)據(jù)庫(kù)打CALL的朋友可能摸到的是大象的耳朵，而我摸到的是大象的尾巴。

昨天文章的最后我說(shuō)了，企業(yè)選擇什么樣的數(shù)據(jù)庫(kù)取決于其應(yīng)用場(chǎng)景，需求等，不過(guò)可能起決定作用的因素是領(lǐng)導(dǎo)的喜好。我寫(xiě)昨天這篇文章的目的是讓大家不要盲目的去追星分布式數(shù)據(jù)庫(kù)，對(duì)于企業(yè)IT來(lái)說(shuō)，其實(shí)是要考慮整體成本的，從建設(shè)到使用，從建設(shè)到擴(kuò)容升級(jí)，從研發(fā)到運(yùn)維，如果從整體上考慮，盲目的選擇相對(duì)復(fù)雜的分布式數(shù)據(jù)庫(kù)，是后患無(wú)窮的。

不過(guò)確實(shí)也有一些場(chǎng)景，集中式數(shù)據(jù)庫(kù)的能力不足，可能只能借助分布式數(shù)據(jù)庫(kù)了。最近我們?cè)趲涂蛻糇鲆粋€(gè)技術(shù)驗(yàn)證測(cè)試，為他們的最大的一套交易型數(shù)據(jù)庫(kù)系統(tǒng)選擇合適的替代品。這套OLTP加批處理特征的系統(tǒng)的數(shù)據(jù)庫(kù)接近70TB，更大量的明細(xì)的時(shí)序特征的數(shù)據(jù)已經(jīng)剝離到HBASE了。選擇候選數(shù)據(jù)庫(kù)的時(shí)候我們選擇了兩款分布式數(shù)據(jù)庫(kù)和一款集中式數(shù)據(jù)庫(kù)。在測(cè)試前的溝通中，集中式數(shù)據(jù)庫(kù)廠商主動(dòng)放棄了，他們覺(jué)得這個(gè)場(chǎng)景是他們的弱項(xiàng)。

所以我要表達(dá)的觀點(diǎn)并不是一味的否定分布式數(shù)據(jù)庫(kù)，而是提醒企業(yè)，企業(yè)數(shù)據(jù)庫(kù)選型時(shí)保留一定的多樣性，可能對(duì)今后企業(yè)的IT系統(tǒng)發(fā)展更有利。去年和一個(gè)客戶交流的時(shí)候，他們的數(shù)據(jù)庫(kù)替代方案是大量的中小型系統(tǒng)替代選擇一款Oracle數(shù)據(jù)庫(kù)兼容性較好的集中式數(shù)據(jù)庫(kù)進(jìn)行一對(duì)一遷移，較為重要的系統(tǒng)采用數(shù)據(jù)復(fù)制HA高可用架構(gòu)，一般的系統(tǒng)僅僅通過(guò)備份保證數(shù)據(jù)級(jí)安全性。企業(yè)中的幾個(gè)大型的核心系統(tǒng)具有較好的分區(qū)特性，因此都采用了分布式數(shù)據(jù)庫(kù)進(jìn)行替代。他們采用這種方式后，集中式數(shù)據(jù)庫(kù)的運(yùn)維主要采取自主運(yùn)維的模式，而分布式數(shù)據(jù)庫(kù)采用了相對(duì)成本較高的數(shù)據(jù)庫(kù)原廠駐場(chǎng)服務(wù)的模式。通過(guò)這種二元制的模式，有效的控制了今后運(yùn)維的成本。

談到分布式數(shù)據(jù)庫(kù)，還是免不了要談?wù)劮植际綌?shù)據(jù)庫(kù)的選型問(wèn)題，分布式數(shù)據(jù)庫(kù)的市場(chǎng)也很亂，特別是在我國(guó)，連分布式數(shù)據(jù)庫(kù)的定義都十分模糊。按照信通院相關(guān)白皮書(shū)的定義，分布式數(shù)據(jù)庫(kù)分為三大類(lèi)。

分布式中間件、原生分布式、共享存儲(chǔ)讀寫(xiě)分離都可以算分布式數(shù)據(jù)庫(kù)。我習(xí)慣上還是把讀寫(xiě)分離共享存儲(chǔ)的模式看成是集中式數(shù)據(jù)庫(kù)。剩下的兩類(lèi)分布式數(shù)據(jù)庫(kù)的數(shù)量也是很龐大的。從墨天輪國(guó)產(chǎn)數(shù)據(jù)庫(kù)熱度排行榜往下數(shù)就有OceanBase、TiDB、GaussDB、TDSQL、GBase 8A、AnalyticDB、GoldenDB、AntDB等一大堆分布式關(guān)系型數(shù)據(jù)庫(kù)了。

如果說(shuō)集中式數(shù)據(jù)庫(kù)天生就在擴(kuò)展能力上有天花板，那么打破了這個(gè)天花板的分布式數(shù)據(jù)庫(kù)其實(shí)也是有缺陷的。昨天這方面我已經(jīng)談了不少，今天就不再重復(fù)了。今天要談的是這么多分布式數(shù)據(jù)庫(kù)，到底我們?cè)撊绾稳ミx擇呢？實(shí)際上數(shù)據(jù)庫(kù)選型真的很難十分科學(xué)，一種比較科學(xué)的方法是為你的應(yīng)用去選擇數(shù)據(jù)庫(kù)而不是為你的喜好去選擇數(shù)據(jù)庫(kù)。根據(jù)你的業(yè)務(wù)場(chǎng)景的特點(diǎn)去對(duì)這些數(shù)據(jù)庫(kù)打分，最后選出能夠滿足你的業(yè)務(wù)系統(tǒng)中的一些比較有挑戰(zhàn)性的場(chǎng)景的幾個(gè)候選數(shù)據(jù)庫(kù)，再根據(jù)你喜好去選擇其中之一，相對(duì)會(huì)科學(xué)一些。

如果是要處理簡(jiǎn)單的物聯(lián)網(wǎng)應(yīng)用，那么大多數(shù)分布數(shù)據(jù)庫(kù)都是能夠勝任的，大并發(fā)寫(xiě)入，簡(jiǎn)單的查詢是分布式數(shù)據(jù)庫(kù)最擅長(zhǎng)的場(chǎng)景。如果你的業(yè)務(wù)邏輯十分復(fù)雜，有很多比較復(fù)雜的查詢，甚至還有一些較為復(fù)雜的大型批處理場(chǎng)景，那么數(shù)據(jù)庫(kù)的SQL引擎的能力就十分重要了。分布式數(shù)據(jù)庫(kù)是通過(guò)分布式執(zhí)行的能力來(lái)彌補(bǔ)分布式在保證事務(wù)一致性上和分布式執(zhí)行在網(wǎng)絡(luò)延時(shí)上的開(kāi)銷(xiāo)的。如果算子不能有效的分解與下推，那么就像打群架一樣，一堆流氓哪怕是群毆，戰(zhàn)斗力也不強(qiáng)的。因此在做選擇的時(shí)候，要十分注重SQL引擎的能力。最簡(jiǎn)單的方法是把各種以前在Oracle上也比較吃力的SQL拿出來(lái)，在這些數(shù)據(jù)庫(kù)上跑一跑，看看效果如何。

對(duì)于研發(fā)能力很差，大量的SQL都是從老一輩程序員的代碼里摳出來(lái)，自己也看不太懂，只能通過(guò)層層嵌套往上加業(yè)務(wù)的研發(fā)隊(duì)伍開(kāi)發(fā)的應(yīng)用，那么就需要選擇CBO優(yōu)化器水平較高的數(shù)據(jù)庫(kù)產(chǎn)品了。這種情況下，大部分SQL代理模式的分布式數(shù)據(jù)庫(kù)產(chǎn)品就基本上不用考慮了。

數(shù)據(jù)庫(kù)選型是個(gè)很復(fù)雜的事情，不過(guò)做起來(lái)也可以變得很簡(jiǎn)單。就像我本文中介紹的一個(gè)客戶，大量的中小型的系統(tǒng)可以直接根據(jù)自己的喜好和商務(wù)上的考慮，選擇一款和Oracle兼容性較好的集中式數(shù)據(jù)庫(kù)進(jìn)行替代了。如果應(yīng)用能做一定的改造，直接上開(kāi)源的集中式數(shù)據(jù)庫(kù)就可以了。對(duì)于一些大型的核心系統(tǒng)，可以采用選型的方式，根據(jù)業(yè)務(wù)特點(diǎn)選擇幾個(gè)產(chǎn)品，使用自己的應(yīng)用場(chǎng)景編制測(cè)試用例，做個(gè)及格測(cè)試。對(duì)于考核合格的產(chǎn)品，領(lǐng)導(dǎo)拍板就行了。