昨天的文章發(fā)了以后有朋友就懷疑這文章是給集中式數(shù)據(jù)庫廠商打call的，實際上我只是從一個相對客觀的角度把我對分布式數(shù)據(jù)庫的個人見解寫出來了。同樣對于這個話題，分布式數(shù)據(jù)庫的擁躉也可以寫出一篇比較客觀的文章，觀點看上去完全不同。是不是很奇妙，怎么會存在兩種截然不同的事實呢？如果你了解過陽明心學，從表象和物本質(zhì)的理論來看這件事，就能理解了。實際上我們講述的都不是事實，不是物本質(zhì)。事實只有一個，我們所看到的只是表象，描述的只是觀點，而不是事實本身。我們的描述可以十分接近事實，但永遠也無法變成事實?；诖?，一些看似矛盾的“較為正確的觀點”就會存在了。實際上我們都是在盲人摸象，為分布式數(shù)據(jù)庫打CALL的朋友可能摸到的是大象的耳朵，而我摸到的是大象的尾巴。

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

不過確實也有一些場景，集中式數(shù)據(jù)庫的能力不足，可能只能借助分布式數(shù)據(jù)庫了。最近我們在幫客戶做一個技術(shù)驗證測試，為他們的最大的一套交易型數(shù)據(jù)庫系統(tǒng)選擇合適的替代品。這套OLTP加批處理特征的系統(tǒng)的數(shù)據(jù)庫接近70TB，更大量的明細的時序特征的數(shù)據(jù)已經(jīng)剝離到HBASE了。選擇候選數(shù)據(jù)庫的時候我們選擇了兩款分布式數(shù)據(jù)庫和一款集中式數(shù)據(jù)庫。在測試前的溝通中，集中式數(shù)據(jù)庫廠商主動放棄了，他們覺得這個場景是他們的弱項。

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

談到分布式數(shù)據(jù)庫，還是免不了要談談分布式數(shù)據(jù)庫的選型問題，分布式數(shù)據(jù)庫的市場也很亂，特別是在我國，連分布式數(shù)據(jù)庫的定義都十分模糊。按照信通院相關白皮書的定義，分布式數(shù)據(jù)庫分為三大類。

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

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

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

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

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