今天出差，在高鐵上想起前幾天和一個客戶交流的事情，于是利用高鐵上這段時(shí)間，慢慢寫一篇吧。最近這幾天在外面出差，可能不一定有時(shí)間發(fā)文章了。

這是一個金融客戶，他們企業(yè)的業(yè)務(wù)覆蓋面不大，每秒鐘大概交易量是500筆左右。目前用了兩臺IBM小機(jī)跑ORACLE 11.2.0.4 RAC，節(jié)點(diǎn)負(fù)載比較均衡，CPU使用率高峰期不超過20%。

他們經(jīng)過分析后認(rèn)為如果上國產(chǎn)數(shù)據(jù)庫，必須用分布式的。我問他為什么，他說主要是考慮今后業(yè)務(wù)量的問題，三五年后有可能交易量翻翻。我就和他算了一下每秒1000筆核心交易大致的負(fù)載，相當(dāng)于一分鐘三萬六千筆。雖然說銀行核心交易和TPMC沒有直接換算公式，不過在目前的一臺兩路PC服務(wù)器上，BENCHMARK輕輕松松就可以跑60萬的今天，這確實(shí)也不算個事兒了。因此對于此類用戶，甚至說對大多數(shù)用戶來說，怕單機(jī)處理能力不足是沒必要的。

分布式數(shù)據(jù)庫一定能提高交易性能嗎？我們先來看看RAC，兩個節(jié)點(diǎn)的環(huán)境，大體上會對交易量提升有幫助，而對于交易延時(shí)的提升就不一定了，在少數(shù)情況下，如果原有系統(tǒng)存在較為嚴(yán)重的資源爭用，那么可能RAC會緩解這種爭用，提高單一交易性能。不過在大多數(shù)情況下，集群是有開銷的，單筆交易的延時(shí)反而會增加。去年有個客戶和我交流，他們想把核心交易的RAC拆成HA，因?yàn)榫W(wǎng)聯(lián)對交易延時(shí)監(jiān)控太狠了，他們想進(jìn)一步縮短單筆交易的延時(shí)，他們分析了大量核心交易的SQL，發(fā)現(xiàn)RAC上消耗的時(shí)間占了接近10%。

RAC如此，分布式數(shù)據(jù)庫也是如此，跨節(jié)點(diǎn)的事務(wù)和SQL，肯定是有成本低。對于銀行核心交易這類大多數(shù)只是簡單的單表操作的交易，哪怕優(yōu)化的再好，集群的成本也不可能變成負(fù)數(shù)。分布式數(shù)據(jù)庫上的提高交易并發(fā)能力的案例大多數(shù)是可信的，而減少交易時(shí)間的案例大多數(shù)不太靠譜，往往是在某些不太常見的條件下測試出來的。

綜上所述，我今天要說的關(guān)于分布式數(shù)據(jù)庫的前兩個事實(shí)是：1.大多數(shù)業(yè)務(wù)系統(tǒng)的負(fù)載并不至于單機(jī)集中式數(shù)據(jù)庫處理不過來，哪怕真出現(xiàn)類似情況，做些簡單的數(shù)據(jù)庫分拆，只分庫，或者分離一些大開銷負(fù)載的統(tǒng)計(jì)分析到只讀備機(jī)上，就能搞得定。這種拆分，應(yīng)用開發(fā)商都能輕松搞定。 2.分布式數(shù)據(jù)庫能帶來交易并發(fā)能力的提升（基于1的原因，這個能力不足以讓我們必須選分布式數(shù)據(jù)庫），但是大多數(shù)情況下無法提升單筆交易的性能，反而在大多數(shù)情況下會略加大單筆交易的延時(shí)。

 有人問，分布式數(shù)據(jù)庫在高可用上對于集中式數(shù)據(jù)庫有沒有優(yōu)勢？這是我今天要討論的分布式數(shù)據(jù)庫的第三個事實(shí)，我可以十分肯定的回答，是的，分布式數(shù)據(jù)庫從底層架構(gòu)上具有極強(qiáng)的容錯能力，在高可用上是有優(yōu)勢的。不過，這個事實(shí)也是有條件的?，F(xiàn)在數(shù)據(jù)庫市場十分混亂，分布式數(shù)據(jù)庫產(chǎn)品質(zhì)量也參差不齊。高可用架構(gòu)設(shè)計(jì)出來不難，做好不易。因此我們在選擇產(chǎn)品的時(shí)候還是要小心，有些數(shù)據(jù)庫產(chǎn)品在底層故障切換時(shí)，并不總是很平穩(wěn)的，底層故障切換時(shí)整個庫都會有較大影響，而且你無法干預(yù)，也不知道問題出在哪，這時(shí)候你可能會希望這是個集中式數(shù)據(jù)庫多好。

分布式數(shù)據(jù)庫的第四個事實(shí)是，有時(shí)候一群流氓不一定干得過猛男。分布式數(shù)據(jù)庫剛剛出來的時(shí)候，我是很期待的，其中最期待的是分布式數(shù)據(jù)庫能解決大開銷的復(fù)雜查詢。在單機(jī)集中式數(shù)據(jù)庫上，這些SQL已經(jīng)跑到極限了，還是無法滿足客戶的需求。我以前在幫助一個客戶優(yōu)化幾個大型報(bào)備應(yīng)用的時(shí)候，啟用了跨節(jié)點(diǎn)并行查詢，還取得了不錯的效果，因此我剛開始也堅(jiān)信分布式數(shù)據(jù)庫在這方面會做得很好。很多分布式數(shù)據(jù)庫廠商也拿著很多對比測試的結(jié)果宣布自己在大查詢上性能比O記高幾倍到幾十倍。這些測試結(jié)果沒問題，有問題的的，測試僅僅是測試，你的生產(chǎn)環(huán)境不是由這些測試用例組成的。而這個關(guān)于分布式數(shù)據(jù)庫的事實(shí)是，群毆雖然是一種好方法，不過有些群毆是專業(yè)的軍隊(duì)打的，有章法有配合，有些群毆是街頭小混混，沒啥技術(shù)含量。分布式數(shù)據(jù)庫的群毆也是如此，要想有好的SQL性能，CBO優(yōu)化器，分布式調(diào)度，分布式執(zhí)行器的水平必須高，一個比較糟糕的分布式執(zhí)行計(jì)劃，可能會讓SQL性能遠(yuǎn)低于在一個單機(jī)上跑，因此選擇適合你業(yè)務(wù)場景的分布式數(shù)據(jù)庫十分關(guān)鍵。而這個事實(shí)更深的一面是，現(xiàn)在的分布式數(shù)據(jù)庫的技術(shù)水平參差不齊，哪怕頂流的分布式數(shù)據(jù)庫，在某些常用的復(fù)雜SQL的性能上，都還不一定干得過ORACLE跑在一個沒有明顯瓶頸的服務(wù)器上。

分布式數(shù)據(jù)庫很易于管理，可以減輕企業(yè)數(shù)據(jù)庫運(yùn)維的壓力，這是我今天要講的第五個關(guān)于分布式數(shù)據(jù)庫的事實(shí)。事實(shí)是如此嗎？借用開篇那位RACSIG大佬的話，MAYBE。分布式數(shù)據(jù)庫是十分復(fù)雜的，在大多數(shù)情況下很穩(wěn)定，DBA也貌似沒啥可干的，但是出問題的時(shí)候，DBA也好像沒啥事可干的，因?yàn)樗静恢涝趺锤?。運(yùn)維團(tuán)隊(duì)沒有掌握分布式數(shù)據(jù)庫運(yùn)維的時(shí)候，很難定位與分析問題，往往只能等著數(shù)據(jù)庫自動恢復(fù)。這對于核心業(yè)務(wù)系統(tǒng)來說就是災(zāi)難。這時(shí)候可能會想這要是集中式數(shù)據(jù)庫多好，大不了我關(guān)了重啟。

為企業(yè)的核心業(yè)務(wù)選擇數(shù)據(jù)庫是十分復(fù)雜的事情，關(guān)系到企業(yè)的IT規(guī)劃，企業(yè)領(lǐng)導(dǎo)的喜好，商務(wù)因素，運(yùn)維團(tuán)隊(duì)的能力，資金，研發(fā)能力等諸多因素，因此今天的文章里我并沒有寫該如何選型，這也不是我能說了算的。我的文章只是給大家在思考這些問題點(diǎn)是提供一些素材，一些我的觀點(diǎn)，也許有些觀點(diǎn)并不正確或者并不全面，當(dāng)個參考吧。