[[378053]]

最近，老魚(yú)聽(tīng)說(shuō)了一個(gè)案例！

某銀行計(jì)劃部署分布式數(shù)據(jù)庫(kù)來(lái)替換業(yè)務(wù)核心的集中式數(shù)據(jù)庫(kù)。先期計(jì)劃在某一核心業(yè)務(wù)進(jìn)行試點(diǎn)，然后根據(jù)試點(diǎn)情況，再?zèng)Q定是否繼續(xù)大規(guī)模實(shí)施。

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

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

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

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

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

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

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

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

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

從運(yùn)維角度看，因?yàn)橛布罅吭黾?，假設(shè)原來(lái)3臺(tái)小型機(jī)只需要2個(gè)運(yùn)維，那現(xiàn)在600多臺(tái)X86需要的運(yùn)維就得翻倍，甚至更多。假設(shè)一個(gè)運(yùn)維平均年薪20萬(wàn)，5年就是100萬(wàn)，如果增加3個(gè)就是300萬(wàn)。其次，大量增加的機(jī)器，勢(shì)必導(dǎo)致電費(fèi)、散熱、機(jī)房使用等成本提升。

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

因此，無(wú)論是從性能還是成本來(lái)說(shuō)，這個(gè)案例都是沒(méi)有性?xún)r(jià)比的。

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

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

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

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

老魚(yú)認(rèn)為，沒(méi)有萬(wàn)能的數(shù)據(jù)庫(kù)，只有最合適的數(shù)據(jù)庫(kù)。

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

    ▍歷史背景 

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

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

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

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

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

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

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

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

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

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

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

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

    ▍ 常見(jiàn)誤區(qū) 

1、分布式改造只是個(gè)技術(shù)問(wèn)題

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

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

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

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

2、分布式改造會(huì)降低TCO

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

比如本文開(kāi)頭的案例，就是個(gè)例子，當(dāng)然這個(gè)案例有點(diǎn)極端，再舉個(gè)例子。

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

從這個(gè)案例看，分布式改造只是降低了首次購(gòu)買(mǎi)成本TCA，整體擁有成本TCO并沒(méi)有降低。

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

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

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

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

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

     ▍寫(xiě)在最后 

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

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

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

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

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

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

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

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