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

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

[[377439]]

目前，該試點業務已經部署完成，峰值性能（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支出少，業務對于IT的需求同互聯網公司有著根本性的差異。很難承受分布式改造帶來的經濟成本和技術風險，通常只能依托第三方提供的整體方案和服務，因此，對于這類企業，傳統的集中式數據庫仍然是最好的選擇。

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

寫在最后

總的來說，用什么數據庫，完全取決于業務需求。

業務用數據庫來做什么？分析還是交易？或者兩者兼而有之？業務要處理什么樣的數據？對數據庫性能需求是什么？

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

業務要處理什么樣的數據？結構化？半結構化？非結構化數據？決定需要支持的數據模型。原則上“什么數據模型，就用什么庫”。

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

業務需要處理的多大的數據規模、并發吞吐量、響應時間需求是什么？決定了對數據庫的性能需求。

如果業務是秒殺，春節火車票等，有超高峰值、高并發的業務，那么，分布式數據庫會是一個不錯的選擇。

綜上所述，雖然針對架構和數據庫選型的討論會一直存在，但歸其核心，一定要明確的一點就是：“業務需求主導技術創新”，理性分析和對待架構和分布式數據庫的選型，選擇業務場景最適合的架構和數據庫才是王道。