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

試點的核心業(yè)務(wù)使用的是“O”記數(shù)據(jù)庫，一個3節(jié)點RAC ，3臺小型機， 2臺用于業(yè)務(wù)系統(tǒng)，1臺放在同城災(zāi)備中心作為遠程數(shù)據(jù)備份。 替換后，數(shù)據(jù)庫為某分布式數(shù)據(jù)庫，使用多達600多臺的X86服務(wù)器。

[[377439]]

目前，該試點業(yè)務(wù)已經(jīng)部署完成，峰值性能（TPS）較替換前提高50%，平均性能（TPS）提升33.3%，平均事務(wù)響應(yīng)時間未知。

最終，該銀行決定不再繼續(xù)實施，而是維持現(xiàn)狀。

到這里，相信大家應(yīng)該也能看出點什么。

3節(jié)點RAC能做的事，為什么需要如此多的X86？

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

如果是由于分布式事務(wù)導(dǎo)致網(wǎng)絡(luò)延遲，因此需要更多的服務(wù)器，只能說明這個分布式數(shù)據(jù)庫架構(gòu)設(shè)計差強人意。平均事務(wù)響應(yīng)時間未知，這是因為在應(yīng)用層實現(xiàn)了？那以上網(wǎng)絡(luò)延遲又被推翻。

這個項目5年TCO并不難測算，投入破億是肯定的。硬件成本（服務(wù)器、交換機等）、軟件成本（操作系統(tǒng)、數(shù)據(jù)庫授權(quán)），包含第四/五年維保成本都很容測算。

但有一項成本可能很容易被忽略，那就是運維成本，它或許會占到整體采購成本的20-30%。分布式數(shù)據(jù)庫運維是痛點，分布式改造后運維和開發(fā)的工作量必然激增。

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

從開發(fā)角度看，架構(gòu)的改變，很少不動應(yīng)用的，甚至完全重構(gòu)應(yīng)用都有可能。

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

雖然這個案例有些極端，但反映出的一些市場上真實存在的潛在問題或認知誤區(qū)，值得我們?nèi)ド钊胩接憽?/p>

最近幾年，分布式數(shù)據(jù)庫成為潮流，在各種光環(huán)加持下，仿佛黑暗中的燈塔，難免有些過度神話了。

不僅各路廠商或主動、被動的發(fā)布自己的分布式數(shù)據(jù)庫產(chǎn)品，市場產(chǎn)品群雄逐鹿。很多傳統(tǒng)企業(yè)也在紛紛試水分布式數(shù)據(jù)庫。大有不上分布式數(shù)據(jù)庫就要被時代淘汰，沒用過分布式數(shù)據(jù)庫就顯得特別LOW的架勢。

在試水的企業(yè)中，有成功的，也有失敗的。由于分布式數(shù)據(jù)庫尚無統(tǒng)一的業(yè)界標準，因此，各有各的看法。

老魚認為： 沒有萬能的數(shù)據(jù)庫，只有最合適的數(shù)據(jù)庫。

分布式數(shù)據(jù)庫雖好，但也并非萬能“銀彈”，也分場景，也有自己的短板。而要清楚當前分布式數(shù)據(jù)庫的最佳適用場景，這就要從分布式數(shù)據(jù)庫的歷史背景及走紅原因說起。

歷史背景

分布式數(shù)據(jù)庫在數(shù)據(jù)庫歷史的早期就有了，其研究始于20世紀70年代，世界上第一個分布式數(shù)據(jù)庫系統(tǒng)SDD-1是由美國計算機公司（CCA）于1979年在DEC計算機上實現(xiàn)。

但分布式數(shù)據(jù)庫直到最近幾年才被關(guān)注，其原因也是多方面的。

在互聯(lián)網(wǎng)誕生以前，企業(yè)數(shù)據(jù)規(guī)模不大，以“O”記為代表的傳統(tǒng)數(shù)據(jù)庫足以滿足絕大多數(shù)數(shù)據(jù)管理的需求，因此，分布式數(shù)據(jù)庫并無用武之地，這其中還有兩個方面的原因，首先，這個時期，市面并沒有較好的分布式數(shù)據(jù)庫產(chǎn)品，其次，分布式數(shù)據(jù)庫本身不可以免的存在一些缺陷。

但進入互聯(lián)網(wǎng)時代以后，面對時刻增長的海量數(shù)據(jù)、同時在線的海量用戶，傳統(tǒng)數(shù)據(jù)庫的已經(jīng)難以支撐業(yè)務(wù)發(fā)展。于是，以互聯(lián)網(wǎng)行業(yè)為首的企業(yè)開始探索有效的解決方案。

先是NoSQL發(fā)展起來，NoSQL犧牲了關(guān)系型數(shù)據(jù)庫的一些限制，例如：強一致性，為數(shù)據(jù)處理帶來的擴展性。之后又催生了NewSQL，定義了一種新型的數(shù)據(jù)庫，兼具擴展性與傳統(tǒng)關(guān)系型數(shù)據(jù)庫的特性，最典型的代表就是基于谷歌Spanner/F1論文。

在這個過程中，傳統(tǒng)數(shù)據(jù)庫也在進行自我救贖，最常見的就是分庫分表方式，但這種解決方案需要應(yīng)用系統(tǒng)做大量改造，需要感知數(shù)據(jù)存儲位置，同時增加了運維復(fù)雜性。

于是，就有了分布式數(shù)據(jù)庫的兩種技術(shù)路線：開源數(shù)據(jù)庫+分布式中間件的解決方案，比如MyCat，優(yōu)點是可以利用現(xiàn)有開源數(shù)據(jù)庫成熟穩(wěn)定的產(chǎn)品功能，缺點是中間件畢竟只是一種迂回的方式，會受限于單機數(shù)據(jù)庫的功能。

另一種技術(shù)路線即原生分布式數(shù)據(jù)庫，天生具有分布式的特性，從設(shè)計之初就是針對分布式架構(gòu)進行設(shè)計的，缺點是產(chǎn)品成熟度還有待提升，還需要經(jīng)過不同場景、不同規(guī)模數(shù)據(jù)量和不同行業(yè)應(yīng)用的檢驗、改進和完善。

目前，一般性的共識是數(shù)據(jù)量不上一定規(guī)模，沒有超高峰值，沒有高并發(fā)的場景就沒必要用分布式數(shù)據(jù)庫，因為，很可能不但不能獲得什么明顯優(yōu)勢，還要犧牲集中式的單機擴展性和開發(fā)及運維簡單便捷性。

如果只是為了實現(xiàn)國產(chǎn)化替代，其實一些國產(chǎn)關(guān)系型數(shù)據(jù)庫也能滿足需求，并沒有必要直接上分布式數(shù)據(jù)庫。

總的來說，分布式數(shù)據(jù)庫的優(yōu)點是擴展性好，數(shù)據(jù)能分散存儲在多個節(jié)點，能實現(xiàn)水平擴展。并且多個節(jié)點，可以并行執(zhí)行，提高了整體的吞吐。

缺點是分布式事物處理的代價較高，這種代價主要源于兩階段的提交造成過多的消息傳輸；可能的鎖爭用變大；復(fù)制多副本和高可用。其次，產(chǎn)品成熟度有待提升，運維復(fù)雜。

常見誤區(qū)

1.分布式改造只是個技術(shù)問題

從傳統(tǒng)集中式架構(gòu)改造為分布式架構(gòu)，并非一個簡單的技術(shù)問題，而是一個技術(shù)生態(tài)切換的問題。

數(shù)據(jù)庫的分布化，帶來的不僅是數(shù)據(jù)庫系統(tǒng)重構(gòu)，還有應(yīng)用系統(tǒng)的重構(gòu)。分布式數(shù)據(jù)庫一般不支持存儲過程，SQL執(zhí)行效率低，而這些問題通常只能在應(yīng)用端解決。

相比傳統(tǒng)數(shù)據(jù)庫，分布式數(shù)據(jù)庫的開發(fā)和運維的技術(shù)要求會提高一個檔次，民生銀行的技術(shù)負責人就曾表示，分布式改造時，開發(fā)一個智能化的運維平臺非常重要。

因此，上分布式數(shù)據(jù)庫前，需要做好整體規(guī)劃，在資金、環(huán)境改造，人員技能、管理自動化和技術(shù)儲備等各個方面做好充分準備。

2.分布式改造會降低TCO

分布式數(shù)據(jù)庫有兩種技術(shù)路線：開源數(shù)據(jù)庫+分布式中間件，原生分布式數(shù)據(jù)庫。由于研發(fā)分布式數(shù)據(jù)庫產(chǎn)品的公司多為互聯(lián)網(wǎng)、創(chuàng)業(yè)公司等，它們一般都以使用 MySQL為主，因此，很多人認為部署分布式數(shù)據(jù)庫，軟件采購費用會降低，X86替代RISC，硬件單價會大幅降低，所以，TCO會降下來。但實際情況也可能并非如此。

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

某全國性銀行的信用卡系統(tǒng)，原數(shù)據(jù)庫系統(tǒng)為4臺小型機，分布化改造后，需要120臺數(shù)據(jù)庫服務(wù)器，軟硬件采購成本降低了50%，但是運維人員增長了66%，開發(fā)人員增長了5倍，計算5年整體擁有成本，比原來提高了60%以上。節(jié)省的采購成本并不能覆蓋后期增加的運維和開發(fā)成本。

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

3.不發(fā)掘現(xiàn)有系統(tǒng)潛力，盲目照搬互聯(lián)網(wǎng)模式

有句俗話叫“技術(shù)跟著業(yè)務(wù)走”。IT架構(gòu)的進化升級需要與企業(yè)業(yè)務(wù)轉(zhuǎn)型同步，落后則制約業(yè)務(wù)發(fā)展，激進則會造成投資浪費，甚至給業(yè)務(wù)帶來風險。

傳統(tǒng)企業(yè)和互聯(lián)網(wǎng)公司的業(yè)務(wù)相比有著根本性的不同?；ヂ?lián)網(wǎng)公司有三個顯著的特點，即海量的用戶、用戶的高頻訪問和交易、業(yè)務(wù)的高頻創(chuàng)新，比如抖音、快手、今日頭條，一年時間就可以發(fā)展幾千萬用戶，每個用戶每天多次登陸使用。所以，IT基礎(chǔ)架構(gòu)一定以擴展性、靈活性為第一追求。

傳統(tǒng)企業(yè)的核心業(yè)務(wù)相對穩(wěn)定，而且用戶數(shù)量有限，交易頻率不高，開發(fā)人員少、IT支出少，業(yè)務(wù)對于IT的需求同互聯(lián)網(wǎng)公司有著根本性的差異。很難承受分布式改造帶來的經(jīng)濟成本和技術(shù)風險，通常只能依托第三方提供的整體方案和服務(wù)，因此，對于這類企業(yè)，傳統(tǒng)的集中式數(shù)據(jù)庫仍然是最好的選擇。

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

寫在最后

總的來說，用什么數(shù)據(jù)庫，完全取決于業(yè)務(wù)需求。

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

如果是傳統(tǒng)的ERP、CRM、財務(wù)等與“錢”相關(guān)的核心業(yè)務(wù)系統(tǒng)，需要事務(wù)完整性，保證ACID事務(wù)，那么，毫無疑問，傳統(tǒng)的集中式關(guān)系型數(shù)據(jù)庫是最佳選擇。

業(yè)務(wù)要處理什么樣的數(shù)據(jù)？結(jié)構(gòu)化？半結(jié)構(gòu)化？非結(jié)構(gòu)化數(shù)據(jù)？決定需要支持的數(shù)據(jù)模型。原則上“什么數(shù)據(jù)模型，就用什么庫”。

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

業(yè)務(wù)需要處理的多大的數(shù)據(jù)規(guī)模、并發(fā)吞吐量、響應(yīng)時間需求是什么？決定了對數(shù)據(jù)庫的性能需求。

如果業(yè)務(wù)是秒殺，春節(jié)火車票等，有超高峰值、高并發(fā)的業(yè)務(wù)，那么，分布式數(shù)據(jù)庫會是一個不錯的選擇。

綜上所述，雖然針對架構(gòu)和數(shù)據(jù)庫選型的討論會一直存在，但歸其核心，一定要明確的一點就是：“業(yè)務(wù)需求主導(dǎo)技術(shù)創(chuàng)新”，理性分析和對待架構(gòu)和分布式數(shù)據(jù)庫的選型，選擇業(yè)務(wù)場景最適合的架構(gòu)和數(shù)據(jù)庫才是王道。