最近，老魚聽說了一個案例：某銀行計劃部署分散式資料庫來替換業務核心的集中式資料庫。先期計劃在某一核心業務進行試點，然後根據試點情況，再決定是否繼續大規模實施。

試點的核心業務使用的是“O”記資料庫，一個3節點RAC ，3臺小型機， 2臺用於業務系統，1臺放在同城災備中心作為遠端資料備份。替換後，資料庫為某分散式資料庫，使用多達600多臺的X86伺服器。

目前，該試點業務已經部署完成，峰值效能（TPS）較替換前提高50%，平均效能（TPS）提升33.3%，平均事務響應時間未知。

最終，該銀行決定不再繼續實施，而是維持現狀。

到這裡，相信大家應該也能看出點什麼。

3節點RAC能做的事，為什麼需要如此多的X86？

沒錯，即使不同銀行的核心業務複雜度有所差異，即便替換後有50%的效能提升，但是！但是！但是！重要的事情說3遍，反正，在老魚詢問了多位專家後，大家觀點是完全一致的，都不認為需要如此之多的機器，這是在燒錢！即便不差錢，也應該考慮給開發和運維團隊在未來工作中帶來劇增的額外工作量及複雜度。

如果是由於分散式事務導致網路延遲，因此需要更多的伺服器，只能說明這個分散式資料庫架構設計差強人意。平均事務響應時間未知，這是因為在應用層實現了？那以上網路延遲又被推翻。

這個專案5年TCO並不難測算，投入破億是肯定的。硬體成本（伺服器、交換機等）、軟體成本（作業系統、資料庫授權），包含第四/五年維保成本都很容測算。

但有一項成本可能很容易被忽略，那就是運維成本，它或許會佔到整體採購成本的20-30%。分散式資料庫運維是痛點，分散式改造後運維和開發的工作量必然激增。

從運維角度看，因為硬體大量增加，假設原來3臺小型機只需要2個運維，那現在600多臺X86需要的運維就得翻倍，甚至更多。假設一個運維平均年薪20萬，5年就是100萬，如果增加3個就是300萬。其次，大量增加的機器，勢必導致電費、散熱、機房使用等成本提升。

從開發角度看，架構的改變，很少不動應用的，甚至完全重構應用都有可能。

因此，無論是從效能還是成本來說，這個案例都是沒有價效比的。

雖然這個案例有些極端，但反映出的一些市場上真實存在的潛在問題或認知誤區，值得我們去深入探討。

最近幾年，分散式資料庫成為潮流，在各種光環加持下，彷彿黑暗中的燈塔，難免有些過度神話了。

不僅各路廠商或主動、被動的釋出自己的分散式資料庫產品，市場產品群雄逐鹿。很多傳統企業也在紛紛試水分散式資料庫。大有不上分散式資料庫就要被時代淘汰，沒用過分散式資料庫就顯得特別LOW的架勢。

在試水的企業中，有成功的，也有失敗的。由於分散式資料庫尚無統一的業界標準，因此，各有各的看法。

老魚認為：沒有萬能的資料庫，只有最合適的資料庫。

分散式資料庫雖好，但也並非萬能“銀彈”，也分場景，也有自己的短板。而要清楚當前分散式資料庫的最佳適用場景，這就要從分散式資料庫的歷史背景及走紅原因說起。

歷史背景

分散式資料庫在資料庫歷史的早期就有了，其研究始於20世紀70年代，世界上第一個分散式資料庫系統SDD-1是由美國計算機公司（CCA）於1979年在DEC計算機上實現。

但分散式資料庫直到最近幾年才被關注，其原因也是多方面的。

在網際網路誕生以前，企業資料規模不大，以“O”記為代表的傳統資料庫足以滿足絕大多數資料管理的需求，因此，分散式資料庫並無用武之地，這其中還有兩個方面的原因，首先，這個時期，市面並沒有較好的分散式資料庫產品，其次，分散式資料庫本身不可以免的存在一些缺陷。

但進入網際網路時代以後，面對時刻增長的海量資料、同時線上的海量使用者，傳統資料庫的已經難以支撐業務發展。於是，以網際網路行業為首的企業開始探索有效的解決方案。

先是NoSQL發展起來，NoSQL犧牲了關係型資料庫的一些限制，例如：強一致性，為資料處理帶來的擴充套件性。之後又催生了NewSQL，定義了一種新型的資料庫，兼具擴充套件性與傳統關係型資料庫的特性，最典型的代表就是基於谷歌Spanner/F1論文。

在這個過程中，傳統資料庫也在進行自我救贖，最常見的就是分庫分表方式，但這種解決方案需要應用系統做大量改造，需要感知資料儲存位置，同時增加了運維複雜性。

於是，就有了分散式資料庫的兩種技術路線：開源資料庫+分散式中介軟體的解決方案，比如MyCat，優點是可以利用現有開源資料庫成熟穩定的產品功能，缺點是中介軟體畢竟只是一種迂迴的方式，會受限於單機資料庫的功能。

另一種技術路線即原生分散式資料庫，天生具有分散式的特性，從設計之初就是針對分散式架構進行設計的，缺點是產品成熟度還有待提升，還需要經過不同場景、不同規模資料量和不同行業應用的檢驗、改進和完善。

目前，一般性的共識是資料量不上一定規模，沒有超高峰值，沒有高併發的場景就沒必要用分散式資料庫，因為，很可能不但不能獲得什麼明顯優勢，還要犧牲集中式的單機擴充套件性和開發及運維簡單便捷性。

如果只是為了實現國產化替代，其實一些國產關係型資料庫也能滿足需求，並沒有必要直接上分散式資料庫。

總的來說，分散式資料庫的優點是擴充套件性好，資料能分散儲存在多個節點，能實現水平擴充套件。並且多個節點，可以並行執行，提高了整體的吞吐。

缺點是分散式事物處理的代價較高，這種代價主要源於兩階段的提交造成過多的訊息傳輸；可能的鎖爭用變大；複製多副本和高可用。其次，產品成熟度有待提升，運維複雜。

常見誤區

1.分散式改造只是個技術問題

從傳統集中式架構改造為分散式架構，並非一個簡單的技術問題，而是一個技術生態切換的問題。

資料庫的分佈化，帶來的不僅是資料庫系統重構，還有應用系統的重構。分散式資料庫一般不支援儲存過程，SQL執行效率低，而這些問題通常只能在應用端解決。

相比傳統資料庫，分散式資料庫的開發和運維的技術要求會提高一個檔次，民生銀行的技術負責人就曾表示，分散式改造時，開發一個智慧化的運維平臺非常重要。

因此，上分散式資料庫前，需要做好整體規劃，在資金、環境改造，人員技能、管理自動化和技術儲備等各個方面做好充分準備。

2.分散式改造會降低TCO

分散式資料庫有兩種技術路線：開源資料庫+分散式中介軟體，原生分散式資料庫。由於研發分散式資料庫產品的公司多為網際網路、創業公司等，它們一般都以使用 MySQL為主，因此，很多人認為部署分散式資料庫，軟體採購費用會降低，X86替代RISC，硬體單價會大幅降低，所以，TCO會降下來。但實際情況也可能並非如此。

比如本文開頭的案例，就是個例子，當然這個案例有點極端，再舉個例子。

某全國性銀行的信用卡系統，原資料庫系統為4臺小型機，分佈化改造後，需要120臺數據庫伺服器，軟硬體採購成本降低了50%，但是運維人員增長了66%，開發人員增長了5倍，計算5年整體擁有成本，比原來提高了60%以上。節省的採購成本並不能覆蓋後期增加的運維和開發成本。

從這個案例看，分散式改造只是降低了首次購買成本TCA，整體擁有成本TCO並沒有降低。

3.不發掘現有系統潛力，盲目照搬網際網路模式

有句俗話叫“技術跟著業務走”。IT架構的進化升級需要與企業業務轉型同步，落後則制約業務發展，激進則會造成投資浪費，甚至給業務帶來風險。

傳統企業的核心業務相對穩定，而且使用者數量有限，交易頻率不高，開發人員少、IT支出少，業務對於IT的需求同網際網路公司有著根本性的差異。很難承受分散式改造帶來的經濟成本和技術風險，通常只能依託第三方提供的整體方案和服務，因此，對於這類企業，傳統的集中式資料庫仍然是最好的選擇。

比如本文開頭的案例，要提高資料庫系統性能，只需要把硬體平臺從雙路、四路伺服器升級到八路、十六路等大型伺服器上，就可以覆蓋絕大部分業務需求。成本未必比直接上分散式高，甚至可能還要低。目前，國產伺服器、小型機品類齊全，價格也很透明。如果這樣還不夠，就來個RAC叢集，不少國產關係型資料庫也大都有RAC叢集擴充套件方案。

寫在最後

總的來說，用什麼資料庫，完全取決於業務需求。

業務用資料庫來做什麼？分析還是交易？或者兩者兼而有之？業務要處理什麼樣的資料？對資料庫效能需求是什麼？

如果是傳統的ERP、CRM、財務等與“錢”相關的核心業務系統，需要事務完整性，保證ACID事務，那麼，毫無疑問，傳統的集中式關係型資料庫是最佳選擇。

業務要處理什麼樣的資料？結構化？半結構化？非結構化資料？決定需要支援的資料模型。原則上“什麼資料模型，就用什麼庫”。

如果你要儲存和處理的是圖片、音訊、影片等非結構化資料，那麼，NoSQL資料庫會是最佳選擇。進一步來說，業務要儲存遊戲場景中的角色資訊、經驗道具資訊、好友排名等資訊，而這些資訊一般都和ID（鍵）掛鉤，那麼，鍵值資料庫是個很好的選擇。

業務需要處理的多大的資料規模、併發吞吐量、響應時間需求是什麼？決定了對資料庫的效能需求。

如果業務是秒殺，春節火車票等，有超高峰值、高併發的業務，那麼，分散式資料庫會是一個不錯的選擇。

作者丨老魚