不知道從何時起
“選數據庫必選分布式”成了一種潮流
數據查詢慢?上分布式!
應用總是癱?上分布式!
業務體量大?上分布式!
KPI考核不達标?上分布式!
“分布式數據庫”的療效
就這樣被神話了
跟數據和應用相關的各種疑難雜症
仿佛都可以拿“分布式大法”來治
果真如此嗎?隻能說
用戶心中的「成見」，像一座大山
過去幾年分布式數據庫造勢太猛
别管什麼場景，隻管整就完了!
這座大山是如何形成的?
上個十年，互聯網公司的業務大爆發，讓互聯網範式走上了神壇。
互聯網大廠的業務模型、中台理念、應用架構以及分布式數據庫，甚至互聯網公司的從業人員，都成了香饽饽。
那麼，由此帶來的香饽饽之一“分布式數據庫”，到底好不好?
不可否認，确實好!
分布式數據庫的最大優勢在于其橫向擴展能力，輕松處理超大規模數據和并發請求，比如電商平台、社交媒體或其它超重載應用。
而這，恰恰是互聯網業務場景的特點↓
海量用戶，高速擴張，峰值秒殺，大批高端技術牛馬負責運維保障…
但是，一旦抛開互聯網業務，來到傳統企業級場景，你會發現↓
分布式數據庫沒那麼神，甚至，還有一些劣勢——
業内曾經流傳着一個很著名的案例：
某銀行做分布式數據庫試點，用600台x86服務器承載分布式數據，替換了一個三節點O記RAC。
性能和擴展性似乎上來了，但運維成本大幅增加(人力、電費、機房空間、備件)。
所以，技術選擇需要回歸業務本質，而非追逐技術潮流。
分布式數據庫絕對不是包治百病的良藥，任何場景，都需要對症下藥。
數據庫到底應該如何選?
一、要搞清自己的業務需求和痛點，再對症下藥↓
如果是面向海量用戶，超大數據量和增長潛力，并伴有高峰值并發、秒殺型的典型互聯網業務特征，這确實是分布式數據庫舒适區。
如果是複雜業務計算和數據熱點集中的場景，采用集中式庫更合适，比如12306客票、醫院HIS、外彙交易、生産調度、ERP等業務。
二、要對分布式祛魅，很多所謂的“分布式場景”，都跟分布式數據庫沒半毛錢關系。
1、“
有的客戶希望用分布式的雲原生架構，比如微服務化/分布式應用，支持敏捷開發DevOps。
分布式應用的本質，是将上層業務模塊解耦、拆分，每個模塊都可以獨立開發、維護、擴展，并實現容錯隔離。
如果隻是應用解耦，而數據庫保持不變，很顯然這個過程與數據庫是不是分布式沒關系。
而如果在應用解耦過程中，同時将數據庫拆解并綁定到特定微服務應用中，那顯然數據庫面臨的壓力變小了，也與分布式更沒關系了。
至于敏捷開發、CICD、DevOps什麼的，跟數據庫是不是分布式同樣沒關系。
2、“
有些用戶的本意是希望節省成本，一套數據庫能滿足多個部門、多個應用的需求。
他們認為分布式數據庫能夠更好地滿足這樣多部門、多業務需求。
這種情況跟分布式毫無關系，這是數據庫的多租戶場景，采用支持多租戶模式的集中式數據庫成本更低、效果更佳。
3、“
前兩種隻能算“錯誤認知”，而這一種就堪稱魔幻了。
有人隻是覺得分布式數據庫更熱門、更拉風，就寫進了采購标底。
結果采購回來，實際部署的時候，卻當成單機版，集中式部署，妥妥“冤大頭”。
要知道這種把分布式數據庫當集中式部署的情況，綜合性能遠不如原生的集中式數據庫。
以上這三種“分布式”場景，都不需要“分布式數據庫”。
此時，選擇合适的集中式數據庫，能夠獲得更優的性能、更好的運維體驗，以及更低的成本。
選擇金倉，應對企業全棧場景
接下來，我們以金倉數據庫為例，講一講面對各種業務需求，具體如何選型。
作為國産數據庫領域的領軍企業，金倉數據庫産品線豐富，既有集中式産品，也有分布式數據庫，廣泛适配各種業務需求。
第一、分布式應用需求
乍一看，分布式應用很複雜，其實每個拆分後的微服務應用，相比單體應用，功能更加純粹、簡單，反而對數據庫的要求大大降低了。
所以，能扛起大型單體應用的金倉數據庫，針對分布式應用這點“小Case”，自然輕松拿捏。
同時，針對不同微服務模塊的業務特征，可以采用不同類型的數據庫來搭配，從而達到最優的效果。
比如一個微服務化的電商應用，包含用戶、商品、訂單、支付、統計分析等模塊，那麼可以針對性的進行數據庫設計。
用戶服務：事務性、高可靠要求，采用KES主備集群;
商品服務：事務性，讀多寫少、緩存需求高，采用KES讀寫分離集群(支持Redis遷移)
訂單服務：事務性強、一緻性要求高，并發讀寫壓力大，采用KES RAC;
支付服務：高事務性、金融級一緻性，采用KES RAC;
統計分析服務：數據量巨大、實時複雜查詢分析，采用KES ADC。
第二、多租戶需求
在企業級場景，不同部門、不同業務系統，都對數據庫有要求。
以往解決這種問題，最簡單粗暴的辦法就是采購多個數據庫，多套物理硬件，各跑各的，大家都沒意見。
但這種方式會造成巨大的資源浪費，每個數據庫利用率都很低，運維、升級也要獨立完成。
想要實現多用戶、多部門共享，最佳的解決方案是采用數據庫的多租戶功能。
針對多租戶需求，金倉數據庫是提供兩大類四種場景的成熟解決方案，靈活滿足不同建設現狀、不同隔離級别、不同預算要求。
1、VM級多租戶
适用于客戶已建好有虛拟化/雲平台，金倉數據庫可以無縫融入，資源硬件共享、基于VM隔離，支持VM級擴縮容。
2、容器級多租戶
适用于客戶已有K8S容器化平台層，金倉數據庫無縫融入，硬件、OS共享、基于容器隔離，支持pod級擴縮容。
3、數據庫實例級多租戶
适用于中小型應用，低成本投入，單個服務器跑多個業務系統。金倉數據庫天然支持多實例特性，每個業務獨占一個數據庫實例。
并且在部署的時候，可以利用多台服務器池化，主備實例分開部署，提升數據庫冗餘能力。
同時，金倉也支持分布式數據庫的多實例模式。
4、數據庫User級多租戶
這種模式，通過将數據庫創建若幹資源組，實現整體資源池化，然後創建用戶租戶，并指定分配的資源組。
從而實現數據庫實例部署多租戶系統，租戶間資源隔離，提升軟硬件資源利用率，大幅降低成本。
第三、集中式高可用數據庫需求
大中型企業的生産級核心應用，都需要數據庫支持高可用集群，或者再明确一點，他們希望對Oracle RAC進行國産化替代。
此時，就輪到金倉的另兩個重磅數據庫産品登場了。
1、KES RAC，多寫共享存儲集群
看名字大家就秒懂了，這是對标Oracle RAC的場景。
KES RAC集群支持2-8個節點規模，讀寫請求橫向擴展(吞吐量加速比超過0.8)，提供“RPO=0、RTO<10s”可用性，滿足金融級一緻性、高事務性和大規模并發讀寫需求。
2、KES RWC，讀寫分離集群
基于事務級别的讀寫分離，自動識别SQL語句讀寫種類，一主多備、一寫多讀。
KES RWC适用于大規模并發查詢、讀多寫少的中/重載業務場景，支持從實例、集群到多中心的高可用保障，數據零丢失，故障秒切換。
第四、真正的分布式數據庫需求
在企業級市場，确實存在一些真實的分布式數據庫需求：比如超大型應用(超高并發、海量存儲、橫向擴展)、極緻高可用(跨中心多活、局部高容錯)等等。
針對這樣的現實需求和潛在需求，金倉數據庫提供了強大的“分布式三劍客”。
1、KES TDC，基于分布式存儲的透明分布式方案。
該方案對上層應用完全透明，不需要應用改造，可平滑遷移，并具備橫向擴展能力和節點故障容錯能力。
适用于超大型集團辦公平台、政務核心平台、醫療HIS系統、銀行信貸管理系統、港口TOS系統等…
2、KES Sharding，基于分布式中間件的分布式方案。
該方案需要應用支持分庫分表改造，适用于對并發、容量、吞吐量擴展性要求高的事務處理場景，如運營商網間結算、基金公司TA系統等。
3、KES ADC，基于分布式+融合多存儲引擎的分析性分布式方案。
該方案适用于大規模AP或者HTAP場景，類似數倉、實時數倉，諸如數據統一彙總平台、大數據分析平台、進出口貿易貨物統計系統等等。
最後，還是那句話：技術的選擇要回歸業務本質，而非追逐技術潮流。
明白這個道理，我們就掌握了消除成見、翻越大山的核心奧義。
怎麼樣?您的數據庫選對了嗎?
免責聲明：本文僅代表作者個人觀點，與每日科技網無關。其原創性以及文中陳述文字和内容未經本站證實，對本文以及其中全部或者部分内容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考，并請自行核實相關内容。
本網站有部分内容均轉載自其它媒體，轉載目的在于傳遞更多信息，并不代表本網贊同其觀點和對其真實性負責，若因作品内容、知識産權、版權和其他問題，請及時提供相關證明等材料并與我們聯系，本網站将在規定時間内給予删除等相關處理.
