不知道從何時(shí)起

“選數(shù)據(jù)庫(kù)必選分布式”成了一種潮流

數(shù)據(jù)查詢(xún)慢？上分布式！

應(yīng)用總是癱？上分布式！

業(yè)務(wù)體量大？上分布式！

KPI考核不達(dá)標(biāo)？上分布式！

“分布式數(shù)據(jù)庫(kù)”的療效

就這樣被神話(huà)了

跟數(shù)據(jù)和應(yīng)用相關(guān)的各種疑難雜癥

仿佛都可以拿“分布式大法”來(lái)治

果真如此嗎？只能說(shuō)

用戶(hù)心中的「成見(jiàn)」，像一座大山

過(guò)去幾年分布式數(shù)據(jù)庫(kù)造勢(shì)太猛

別管什么場(chǎng)景，只管整就完了！

這座大山是如何形成的？

上個(gè)十年，互聯(lián)網(wǎng)公司的業(yè)務(wù)大爆發(fā)，讓互聯(lián)網(wǎng)范式走上了神壇。

互聯(lián)網(wǎng)大廠(chǎng)的業(yè)務(wù)模型、中臺(tái)理念、應(yīng)用架構(gòu)以及分布式數(shù)據(jù)庫(kù)，甚至互聯(lián)網(wǎng)公司的從業(yè)人員，都成了香餑餑。

那么，由此帶來(lái)的香餑餑之一“分布式數(shù)據(jù)庫(kù)”，到底好不好？

不可否認(rèn)，確實(shí)好！

分布式數(shù)據(jù)庫(kù)的最大優(yōu)勢(shì)在于其橫向擴(kuò)展能力，輕松處理超大規(guī)模數(shù)據(jù)和并發(fā)請(qǐng)求，比如電商平臺(tái)、社交媒體或其它超重載應(yīng)用。

而這，恰恰是互聯(lián)網(wǎng)業(yè)務(wù)場(chǎng)景的特點(diǎn)↓

海量用戶(hù)，高速擴(kuò)張，峰值秒殺，大批高端技術(shù)牛馬負(fù)責(zé)運(yùn)維保障…

但是，一旦拋開(kāi)互聯(lián)網(wǎng)業(yè)務(wù)，來(lái)到傳統(tǒng)企業(yè)級(jí)場(chǎng)景，你會(huì)發(fā)現(xiàn)↓

分布式數(shù)據(jù)庫(kù)沒(méi)那么神，甚至，還有一些劣勢(shì)——

業(yè)內(nèi)曾經(jīng)流傳著一個(gè)很著名的案例：

某銀行做分布式數(shù)據(jù)庫(kù)試點(diǎn)，用600臺(tái)x86服務(wù)器承載分布式數(shù)據(jù)，替換了一個(gè)三節(jié)點(diǎn)O記RAC。

性能和擴(kuò)展性似乎上來(lái)了，但運(yùn)維成本大幅增加（人力、電費(fèi)、機(jī)房空間、備件）。

所以，技術(shù)選擇需要回歸業(yè)務(wù)本質(zhì)，而非追逐技術(shù)潮流。

分布式數(shù)據(jù)庫(kù)絕對(duì)不是包治百病的良藥，任何場(chǎng)景，都需要對(duì)癥下藥。

數(shù)據(jù)庫(kù)到底應(yīng)該如何選？

一、要搞清自己的業(yè)務(wù)需求和痛點(diǎn)，再對(duì)癥下藥↓

如果是面向海量用戶(hù)，超大數(shù)據(jù)量和增長(zhǎng)潛力，并伴有高峰值并發(fā)、秒殺型的典型互聯(lián)網(wǎng)業(yè)務(wù)特征，這確實(shí)是分布式數(shù)據(jù)庫(kù)舒適區(qū)。

如果是復(fù)雜業(yè)務(wù)計(jì)算和數(shù)據(jù)熱點(diǎn)集中的場(chǎng)景，采用集中式庫(kù)更合適，比如12306客票、醫(yī)院HIS、外匯交易、生產(chǎn)調(diào)度、ERP等業(yè)務(wù)

二、要對(duì)分布式祛魅，很多所謂的“分布式場(chǎng)景”，都跟分布式數(shù)據(jù)庫(kù)沒(méi)半毛錢(qián)關(guān)系。

1、“分布式應(yīng)用”場(chǎng)景：

有的客戶(hù)希望用分布式的云原生架構(gòu)，比如微服務(wù)化/分布式應(yīng)用，支持敏捷開(kāi)發(fā)DevOps。

分布式應(yīng)用的本質(zhì)，是將上層業(yè)務(wù)模塊解耦、拆分，每個(gè)模塊都可以獨(dú)立開(kāi)發(fā)、維護(hù)、擴(kuò)展，并實(shí)現(xiàn)容錯(cuò)隔離。

如果只是應(yīng)用解耦，而數(shù)據(jù)庫(kù)保持不變，很顯然這個(gè)過(guò)程與數(shù)據(jù)庫(kù)是不是分布式?jīng)]關(guān)系。

而如果在應(yīng)用解耦過(guò)程中，同時(shí)將數(shù)據(jù)庫(kù)拆解并綁定到特定微服務(wù)應(yīng)用中，那顯然數(shù)據(jù)庫(kù)面臨的壓力變小了，也與分布式更沒(méi)關(guān)系了。

至于敏捷開(kāi)發(fā)、CICD、DevOps什么的，跟數(shù)據(jù)庫(kù)是不是分布式同樣沒(méi)關(guān)系。

2、“分布式用戶(hù)”場(chǎng)景

有些用戶(hù)的本意是希望節(jié)省成本，一套數(shù)據(jù)庫(kù)能滿(mǎn)足多個(gè)部門(mén)、多個(gè)應(yīng)用的需求。

他們認(rèn)為分布式數(shù)據(jù)庫(kù)能夠更好地滿(mǎn)足這樣多部門(mén)、多業(yè)務(wù)需求。

這種情況跟分布式毫無(wú)關(guān)系，這是數(shù)據(jù)庫(kù)的多租戶(hù)場(chǎng)景，采用支持多租戶(hù)模式的集中式數(shù)據(jù)庫(kù)成本更低、效果更佳。

3、“分布式標(biāo)底”場(chǎng)景

前兩種只能算“錯(cuò)誤認(rèn)知”，而這一種就堪稱(chēng)魔幻了。

有人只是覺(jué)得分布式數(shù)據(jù)庫(kù)更熱門(mén)、更拉風(fēng)，就寫(xiě)進(jìn)了采購(gòu)標(biāo)底。

結(jié)果采購(gòu)回來(lái)，實(shí)際部署的時(shí)候，卻當(dāng)成單機(jī)版，集中式部署，妥妥“冤大頭”。

要知道這種把分布式數(shù)據(jù)庫(kù)當(dāng)集中式部署的情況，綜合性能遠(yuǎn)不如原生的集中式數(shù)據(jù)庫(kù)。

以上這三種“分布式”場(chǎng)景，都不需要“分布式數(shù)據(jù)庫(kù)”。

此時(shí)，選擇合適的集中式數(shù)據(jù)庫(kù)，能夠獲得更優(yōu)的性能、更好的運(yùn)維體驗(yàn)，以及更低的成本。

選擇金倉(cāng)，應(yīng)對(duì)企業(yè)全棧場(chǎng)景

接下來(lái)，我們以金倉(cāng)數(shù)據(jù)庫(kù)為例，講一講面對(duì)各種業(yè)務(wù)需求，具體如何選型。

作為國(guó)產(chǎn)數(shù)據(jù)庫(kù)領(lǐng)域的領(lǐng)軍企業(yè)，金倉(cāng)數(shù)據(jù)庫(kù)產(chǎn)品線(xiàn)豐富，既有集中式產(chǎn)品，也有分布式數(shù)據(jù)庫(kù)，廣泛適配各種業(yè)務(wù)需求。

第一、分布式應(yīng)用需求

乍一看，分布式應(yīng)用很復(fù)雜，其實(shí)每個(gè)拆分后的微服務(wù)應(yīng)用，相比單體應(yīng)用，功能更加純粹、簡(jiǎn)單，反而對(duì)數(shù)據(jù)庫(kù)的要求大大降低了。

所以，能扛起大型單體應(yīng)用的金倉(cāng)數(shù)據(jù)庫(kù)，針對(duì)分布式應(yīng)用這點(diǎn)“小Case”，自然輕松拿捏。

同時(shí)，針對(duì)不同微服務(wù)模塊的業(yè)務(wù)特征，可以采用不同類(lèi)型的數(shù)據(jù)庫(kù)來(lái)搭配，從而達(dá)到最優(yōu)的效果。

比如一個(gè)微服務(wù)化的電商應(yīng)用，包含用戶(hù)、商品、訂單、支付、統(tǒng)計(jì)分析等模塊，那么可以針對(duì)性的進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)。

用戶(hù)服務(wù)：事務(wù)性、高可靠要求，采用KES主備集群；
商品服務(wù)：事務(wù)性，讀多寫(xiě)少、緩存需求高，采用KES讀寫(xiě)分離集群(支持Redis遷移)
訂單服務(wù)：事務(wù)性強(qiáng)、一致性要求高，并發(fā)讀寫(xiě)壓力大，采用KES RAC；
支付服務(wù)：高事務(wù)性、金融級(jí)一致性，采用KES RAC；
統(tǒng)計(jì)分析服務(wù)：數(shù)據(jù)量巨大、實(shí)時(shí)復(fù)雜查詢(xún)分析，采用KES ADC。

第二、多租戶(hù)需求

在企業(yè)級(jí)場(chǎng)景，不同部門(mén)、不同業(yè)務(wù)系統(tǒng)，都對(duì)數(shù)據(jù)庫(kù)有要求。

以往解決這種問(wèn)題，最簡(jiǎn)單粗暴的辦法就是采購(gòu)多個(gè)數(shù)據(jù)庫(kù)，多套物理硬件，各跑各的，大家都沒(méi)意見(jiàn)。

但這種方式會(huì)造成巨大的資源浪費(fèi)，每個(gè)數(shù)據(jù)庫(kù)利用率都很低，運(yùn)維、升級(jí)也要獨(dú)立完成。

想要實(shí)現(xiàn)多用戶(hù)、多部門(mén)共享，最佳的解決方案是采用數(shù)據(jù)庫(kù)的多租戶(hù)功能。

針對(duì)多租戶(hù)需求，金倉(cāng)數(shù)據(jù)庫(kù)是提供兩大類(lèi)四種場(chǎng)景的成熟解決方案，靈活滿(mǎn)足不同建設(shè)現(xiàn)狀、不同隔離級(jí)別、不同預(yù)算要求。

1、VM級(jí)多租戶(hù)

適用于客戶(hù)已建好有虛擬化/云平臺(tái)，金倉(cāng)數(shù)據(jù)庫(kù)可以無(wú)縫融入，資源硬件共享、基于VM隔離，支持VM級(jí)擴(kuò)縮容。

2、容器級(jí)多租戶(hù)

適用于客戶(hù)已有K8S容器化平臺(tái)層，金倉(cāng)數(shù)據(jù)庫(kù)無(wú)縫融入，硬件、OS共享、基于容器隔離，支持pod級(jí)擴(kuò)縮容。

3、數(shù)據(jù)庫(kù)實(shí)例級(jí)多租戶(hù)

適用于中小型應(yīng)用，低成本投入，單個(gè)服務(wù)器跑多個(gè)業(yè)務(wù)系統(tǒng)。金倉(cāng)數(shù)據(jù)庫(kù)天然支持多實(shí)例特性，每個(gè)業(yè)務(wù)獨(dú)占一個(gè)數(shù)據(jù)庫(kù)實(shí)例。

并且在部署的時(shí)候，可以利用多臺(tái)服務(wù)器池化，主備實(shí)例分開(kāi)部署，提升數(shù)據(jù)庫(kù)冗余能力。

同時(shí)，金倉(cāng)也支持分布式數(shù)據(jù)庫(kù)的多實(shí)例模式。

4、數(shù)據(jù)庫(kù)User級(jí)多租戶(hù)

這種模式，通過(guò)將數(shù)據(jù)庫(kù)創(chuàng)建若干資源組，實(shí)現(xiàn)整體資源池化，然后創(chuàng)建用戶(hù)租戶(hù)，并指定分配的資源組。

從而實(shí)現(xiàn)數(shù)據(jù)庫(kù)實(shí)例部署多租戶(hù)系統(tǒng)，租戶(hù)間資源隔離，提升軟硬件資源利用率，大幅降低成本。

第三、集中式高可用數(shù)據(jù)庫(kù)需求

大中型企業(yè)的生產(chǎn)級(jí)核心應(yīng)用，都需要數(shù)據(jù)庫(kù)支持高可用集群，或者再明確一點(diǎn)，他們希望對(duì)Oracle RAC進(jìn)行國(guó)產(chǎn)化替代。

此時(shí)，就輪到金倉(cāng)的另兩個(gè)重磅數(shù)據(jù)庫(kù)產(chǎn)品登場(chǎng)了。

1、KES RAC，多寫(xiě)共享存儲(chǔ)集群

看名字大家就秒懂了，這是對(duì)標(biāo)Oracle RAC的場(chǎng)景。

KES RAC集群支持2-8個(gè)節(jié)點(diǎn)規(guī)模，讀寫(xiě)請(qǐng)求橫向擴(kuò)展（吞吐量加速比超過(guò)0.8），提供“RPO=0、RTO<10s”可用性，滿(mǎn)足金融級(jí)一致性、高事務(wù)性和大規(guī)模并發(fā)讀寫(xiě)需求。

2、KES RWC，讀寫(xiě)分離集群

基于事務(wù)級(jí)別的讀寫(xiě)分離，自動(dòng)識(shí)別SQL語(yǔ)句讀寫(xiě)種類(lèi)，一主多備、一寫(xiě)多讀。

KES RWC適用于大規(guī)模并發(fā)查詢(xún)、讀多寫(xiě)少的中/重載業(yè)務(wù)場(chǎng)景，支持從實(shí)例、集群到多中心的高可用保障，數(shù)據(jù)零丟失，故障秒切換。

第四、真正的分布式數(shù)據(jù)庫(kù)需求

在企業(yè)級(jí)市場(chǎng)，確實(shí)存在一些真實(shí)的分布式數(shù)據(jù)庫(kù)需求：比如超大型應(yīng)用（超高并發(fā)、海量存儲(chǔ)、橫向擴(kuò)展）、極致高可用（跨中心多活、局部高容錯(cuò)）等等。

針對(duì)這樣的現(xiàn)實(shí)需求和潛在需求，金倉(cāng)數(shù)據(jù)庫(kù)提供了強(qiáng)大的“分布式三劍客”。

1、KES TDC，基于分布式存儲(chǔ)的透明分布式方案。

該方案對(duì)上層應(yīng)用完全透明，不需要應(yīng)用改造，可平滑遷移，并具備橫向擴(kuò)展能力和節(jié)點(diǎn)故障容錯(cuò)能力。

適用于超大型集團(tuán)辦公平臺(tái)、政務(wù)核心平臺(tái)、醫(yī)療HIS系統(tǒng)、銀行信貸管理系統(tǒng)、港口TOS系統(tǒng)等…

2、KES Sharding，基于分布式中間件的分布式方案。

該方案需要應(yīng)用支持分庫(kù)分表改造，適用于對(duì)并發(fā)、容量、吞吐量擴(kuò)展性要求高的事務(wù)處理場(chǎng)景，如運(yùn)營(yíng)商網(wǎng)間結(jié)算、基金公司TA系統(tǒng)等。

3、KES ADC，基于分布式+融合多存儲(chǔ)引擎的分析性分布式方案。

該方案適用于大規(guī)模AP或者HTAP場(chǎng)景，類(lèi)似數(shù)倉(cāng)、實(shí)時(shí)數(shù)倉(cāng)，諸如數(shù)據(jù)統(tǒng)一匯總平臺(tái)、大數(shù)據(jù)分析平臺(tái)、進(jìn)出口貿(mào)易貨物統(tǒng)計(jì)系統(tǒng)等等。

最后，還是那句話(huà)：技術(shù)的選擇要回歸業(yè)務(wù)本質(zhì)，而非追逐技術(shù)潮流。

明白這個(gè)道理，我們就掌握了消除成見(jiàn)、翻越大山的核心奧義。

怎么樣？您的數(shù)據(jù)庫(kù)選對(duì)了嗎？