數(shù)據(jù)庫選得好，DBA背鍋少！

不知道從何時起

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

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

應用總是癱？上分布式！

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

KPI考核不達標？上分布式！

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

就這樣被神話了

跟數(shù)據(jù)和應用相關的各種疑難雜癥

仿佛都可以拿“分布式大法”來治

果真如此嗎？只能說

用戶心中的「成見」，像一座大山

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

別管什么場景，只管整就完了！

這座大山是如何形成的？

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

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

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

不可否認，確實好！

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

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

海量用戶，高速擴張，峰值秒殺，大批高端技術牛馬負責運維保障…

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

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

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

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

性能和擴展性似乎上來了，但運維成本大幅增加（人力、電費、機房空間、備件）。

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

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

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

一、要搞清自己的業(yè)務需求和痛點，再對癥下藥↓

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

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

二、要對分布式祛魅，很多所謂的“分布式場景”，都跟分布式數(shù)據(jù)庫沒半毛錢關系。

1、“分布式應用”場景：

有的客戶希望用分布式的云原生架構，比如微服務化/分布式應用，支持敏捷開發(fā)DevOps。

分布式應用的本質，是將上層業(yè)務模塊解耦、拆分，每個模塊都可以獨立開發(fā)、維護、擴展，并實現(xiàn)容錯隔離。

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

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

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

2、“分布式用戶”場景

有些用戶的本意是希望節(jié)省成本，一套數(shù)據(jù)庫能滿足多個部門、多個應用的需求。

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

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

3、“分布式標底”場景

前兩種只能算“錯誤認知”，而這一種就堪稱魔幻了。

有人只是覺得分布式數(shù)據(jù)庫更熱門、更拉風，就寫進了采購標底。

結果采購回來，實際部署的時候，卻當成單機版，集中式部署，妥妥“冤大頭”。

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

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

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

選擇金倉，應對企業(yè)全棧場景

接下來，我們以金倉數(shù)據(jù)庫為例，講一講面對各種業(yè)務需求，具體如何選型。

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

第一、分布式應用需求

乍一看，分布式應用很復雜，其實每個拆分后的微服務應用，相比單體應用，功能更加純粹、簡單，反而對數(shù)據(jù)庫的要求大大降低了。

所以，能扛起大型單體應用的金倉數(shù)據(jù)庫，針對分布式應用這點“小Case”，自然輕松拿捏。

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

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

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

第二、多租戶需求

在企業(yè)級場景，不同部門、不同業(yè)務系統(tǒng)，都對數(shù)據(jù)庫有要求。

以往解決這種問題，最簡單粗暴的辦法就是采購多個數(shù)據(jù)庫，多套物理硬件，各跑各的，大家都沒意見。

但這種方式會造成巨大的資源浪費，每個數(shù)據(jù)庫利用率都很低，運維、升級也要獨立完成。

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

針對多租戶需求，金倉數(shù)據(jù)庫是提供兩大類四種場景的成熟解決方案，靈活滿足不同建設現(xiàn)狀、不同隔離級別、不同預算要求。

1、VM級多租戶

適用于客戶已建好有虛擬化/云平臺，金倉數(shù)據(jù)庫可以無縫融入，資源硬件共享、基于VM隔離，支持VM級擴縮容。

2、容器級多租戶

適用于客戶已有K8S容器化平臺層，金倉數(shù)據(jù)庫無縫融入，硬件、OS共享、基于容器隔離，支持pod級擴縮容。

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

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

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

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

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

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

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

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

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

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

1、KES RAC，多寫共享存儲集群

看名字大家就秒懂了，這是對標Oracle RAC的場景。

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

2、KES RWC，讀寫分離集群

基于事務級別的讀寫分離，自動識別SQL語句讀寫種類，一主多備、一寫多讀。

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

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

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

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

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

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

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

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

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

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

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

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

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

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