分布式數據庫一定能提高交易性能嗎？我們先來看看RAC，兩個節點的環境，大體上會對交易量提升有幫助，而對于交易延時的提升就不一定了，在少數情況下，如果原有系統存在較為嚴重的資源爭用，那么可能RAC會緩解這種爭用，提高單一交易性能。不過在大多數情況下，集群是有開銷的，單筆交易的延時反而會增加。
今天出差，在高鐵上想起前幾天和一個客戶交流的事情，于是利用高鐵上這段時間，慢慢寫一篇吧。最近這幾天在外面出差，可能不一定有時間發文章了。
這是一個金融客戶，他們企業的業務覆蓋面不大，每秒鐘大概交易量是500筆左右。目前用了兩臺IBM小機跑ORACLE 11.2.0.4 RAC，節點負載比較均衡，CPU使用率高峰期不超過20%。
他們經過分析后認為如果上國產數據庫，必須用分布式的。我問他為什么，他說主要是考慮今后業務量的問題，三五年后有可能交易量翻翻。我就和他算了一下每秒1000筆核心交易大致的負載，相當于一分鐘三萬六千筆。雖然說銀行核心交易和TPMC沒有直接換算公式，不過在目前的一臺兩路PC服務器上，BENCHMARK輕輕松松就可以跑60萬的今天，這確實也不算個事兒了。因此對于此類用戶，甚至說對大多數用戶來說，怕單機處理能力不足是沒必要的。
分布式數據庫一定能提高交易性能嗎？我們先來看看RAC，兩個節點的環境，大體上會對交易量提升有幫助，而對于交易延時的提升就不一定了，在少數情況下，如果原有系統存在較為嚴重的資源爭用，那么可能RAC會緩解這種爭用，提高單一交易性能。不過在大多數情況下，集群是有開銷的，單筆交易的延時反而會增加。去年有個客戶和我交流，他們想把核心交易的RAC拆成HA，因為網聯對交易延時監控太狠了，他們想進一步縮短單筆交易的延時，他們分析了大量核心交易的SQL，發現RAC上消耗的時間占了接近10%。
RAC如此，分布式數據庫也是如此，跨節點的事務和SQL，肯定是有成本低。對于銀行核心交易這類大多數只是簡單的單表操作的交易，哪怕優化的再好，集群的成本也不可能變成負數。分布式數據庫上的提高交易并發能力的案例大多數是可信的，而減少交易時間的案例大多數不太靠譜，往往是在某些不太常見的條件下測試出來的。
綜上所述，我今天要說的關于分布式數據庫的前兩個事實是：1.大多數業務系統的負載并不至于單機集中式數據庫處理不過來，哪怕真出現類似情況，做些簡單的數據庫分拆，只分庫，或者分離一些大開銷負載的統計分析到只讀備機上，就能搞得定。這種拆分，應用開發商都能輕松搞定。 2.分布式數據庫能帶來交易并發能力的提升（基于1的原因，這個能力不足以讓我們必須選分布式數據庫），但是大多數情況下無法提升單筆交易的性能，反而在大多數情況下會略加大單筆交易的延時。
有人問，分布式數據庫在高可用上對于集中式數據庫有沒有優勢？這是我今天要討論的分布式數據庫的第三個事實，我可以十分肯定的回答，是的，分布式數據庫從底層架構上具有極強的容錯能力，在高可用上是有優勢的。不過，這個事實也是有條件的。現在數據庫市場十分混亂，分布式數據庫產品質量也參差不齊。高可用架構設計出來不難，做好不易。因此我們在選擇產品的時候還是要小心，有些數據庫產品在底層故障切換時，并不總是很平穩的，底層故障切換時整個庫都會有較大影響，而且你無法干預，也不知道問題出在哪，這時候你可能會希望這是個集中式數據庫多好。
分布式數據庫的第四個事實是，有時候一群流氓不一定干得過猛男。分布式數據庫剛剛出來的時候，我是很期待的，其中最期待的是分布式數據庫能解決大開銷的復雜查詢。在單機集中式數據庫上，這些SQL已經跑到極限了，還是無法滿足客戶的需求。我以前在幫助一個客戶優化幾個大型報備應用的時候，啟用了跨節點并行查詢，還取得了不錯的效果，因此我剛開始也堅信分布式數據庫在這方面會做得很好。很多分布式數據庫廠商也拿著很多對比測試的結果宣布自己在大查詢上性能比O記高幾倍到幾十倍。這些測試結果沒問題，有問題的的，測試僅僅是測試，你的生產環境不是由這些測試用例組成的。而這個關于分布式數據庫的事實是，群毆雖然是一種好方法，不過有些群毆是專業的軍隊打的，有章法有配合，有些群毆是街頭小混混，沒啥技術含量。分布式數據庫的群毆也是如此，要想有好的SQL性能，CBO優化器，分布式調度，分布式執行器的水平必須高，一個比較糟糕的分布式執行計劃，可能會讓SQL性能遠低于在一個單機上跑，因此選擇適合你業務場景的分布式數據庫十分關鍵。而這個事實更深的一面是，現在的分布式數據庫的技術水平參差不齊，哪怕頂流的分布式數據庫，在某些常用的復雜SQL的性能上，都還不一定干得過ORACLE跑在一個沒有明顯瓶頸的服務器上。
分布式數據庫很易于管理，可以減輕企業數據庫運維的壓力，這是我今天要講的第五個關于分布式數據庫的事實。事實是如此嗎？借用開篇那位RACSIG大佬的話，MAYBE。分布式數據庫是十分復雜的，在大多數情況下很穩定，DBA也貌似沒啥可干的，但是出問題的時候，DBA也好像沒啥事可干的，因為他根本不知道怎么干。運維團隊沒有掌握分布式數據庫運維的時候，很難定位與分析問題，往往只能等著數據庫自動恢復。這對于核心業務系統來說就是災難。這時候可能會想這要是集中式數據庫多好，大不了我關了重啟。
為企業的核心業務選擇數據庫是十分復雜的事情，關系到企業的IT規劃，企業領導的喜好，商務因素，運維團隊的能力，資金，研發能力等諸多因素，因此今天的文章里我并沒有寫該如何選型，這也不是我能說了算的。我的文章只是給大家在思考這些問題點是提供一些素材，一些我的觀點，也許有些觀點并不正確或者并不全面，當個參考吧。
