分佈式數據庫的幾個事實

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

  這是一個金融客戶，他們企業的業務覆蓋面不大，每秒鐘大概交易量是 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 規劃，企業領導的喜好，商務因素，運維團隊的能力，資金，研發能力等諸多因素，因此今天的文章裏我並沒有寫該如何選型，這也不是我能說了算的。我的文章只是給大家在思考這些問題點是提供一些素材，一些我的觀點，也許有些觀點並不正確或者並不全面，當個參考吧。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/gje2tTv7TL1HAq8ZTuKNvg