分散式資料庫技術的演進和發展方向

来源:https://www.cnblogs.com/huaweiyun/p/18095887
-Advertisement-
Play Games

這些年大家都在談分散式資料庫,各大企業也紛紛開始做資料庫的分散式改造。那麼,所謂的分散式資料庫到底是什麼?採用什麼架構?優勢在哪?為什麼越來越多企業選擇它?分散式資料庫技術會向什麼方向發展?帶著這些疑問,一探究竟吧!參與文末的話題互動,更有機會贏取精美獎品~ 分散式資料庫的架構演進 隨著數據量的爆發 ...


這些年大家都在談分散式資料庫,各大企業也紛紛開始做資料庫的分散式改造。那麼,所謂的分散式資料庫到底是什麼?採用什麼架構?優勢在哪?為什麼越來越多企業選擇它?分散式資料庫技術會向什麼方向發展?帶著這些疑問,一探究竟吧!參與文末的話題互動,更有機會贏取精美獎品~

分散式資料庫的架構演進

隨著數據量的爆發增長,傳統集中式資料庫面臨極大的挑戰:

  • 性能瓶頸:數據規模爆發增長,傳統集中式資料庫難以維持數據量大時的性能,而分散式資料庫的性能可以水平擴展;
  • 缺失混合負載能力:數據量爆發增長帶來對數據分析(OLAP)需求的增長。企業需要使用兩套系統分別支撐事務交易(OLTP)和數據分析(OLAP),不僅造成了大量的數據冗餘,同時增加了系統的複雜度和運維難度。而分散式資料庫的混合負載能力可大幅度提升分析的時效性,減少數據冗餘,並大大提高靈活性;
  • 高昂成本:集中式資料庫水平擴展難,可靠性需要付出高昂的成本。而分散式資料庫的架構支持靈活擴展,實現高可用方案的成本較低。

分散式資料庫與單機資料庫的不同在於其可以將核心功能擴展到多台節點,甚至多個地域,包括事務管理、數據存儲和數據查詢等。從實現方式上看,分散式資料庫主要有3種不同的技術路線:

1. 分散式中間件 + 單機資料庫。

這條路線本質上是分散式系統由兩部分組成:

a) 上層是分散式中間件:維護一套統一的分片規則,提供SQL 解析,請求轉發和結果合併的能力。

b) 底層單機資料庫:開源MySQL或PG單機資料庫,提供數據存儲和執行能力。

這種方式主要使用比較成熟的內核來解決擴展性的問題,所以生態友好、成本較低,也比較容易實現。

不過,缺點也顯而易見。比如功能降級、在全局事務能力和高可用等方面存在短板,需要有針對性增強,導致整個方案的複雜度高、機器冗餘多。最重要的是,因為使用的是開源產品的內核,資料庫會始終受制於開源代碼修改、專利、發行方式等很多方面的風險,這種形式顯然無法滿足當前國內金融、政企客戶的需求。

2. 基於分散式存儲的分散式資料庫。

這種形態基於分散式存儲,再疊加資料庫能力。大部分公有雲資料庫採用這條技術路線。華為雲GaussDB(for MySQL)就是這種形態的典型代表。

這條路線有限地解決了擴展性問題,數據一致性主要依賴分散式存儲引擎。上層的計算節點無狀態,共用存儲提供跨節點讀寫。這種架構充分利用分散式存儲提供的高級特性,更容易形成技術競爭力。但是這種架構的擴展性有限,尤其是寫節點。

另外,這種架構對底座(分散式存儲)有比較重的依賴,線下實現的成本高。

3. 原生分散式資料庫。

這種形態是基於分散式資料庫理論實現的分散式資料庫。這條路線是根據分散式一致性協議做底層設計。原生分散式資料庫將分散式存儲、事務和計算結合在一起,數據由系統自動打散並存儲多個副本,通過一致性協議保證多個副本和事務的一致性。

這種形態更容易在資料庫本身所擅長的領域發揮優勢,比如說性能、複雜SQL處理能力、企業級能力。集群的擴展和收縮對應用透明,按需擴展,支持大規模部署限制;數據一致性由事務層一致性協議保護,安全性更高;靈活部署,多活架構,對硬體的依賴低,可以通過普通伺服器實現集群和高可用。

因為金融政企客戶在使用分散式技術之前,往往已經有分庫分表、使用分散式中間件產品的經驗,所以對原生分散式架構的認可度更高,學習成本也相對較低,因此,這種形態也是國內當前被採用較多的一種。

華為雲GaussDB分散式資料庫就是這種形態的典型代表。GaussDB基於華為在資料庫領域20多年的戰略投入,已經在金融行業積累了非常豐富的實踐經驗,是企業數字化轉型、核心數據上雲、分散式改造的信賴之選。

原生分散式資料庫的挑戰和關鍵技術

原生分散式資料庫基於分散式資料庫理論,是一款對於用戶應用透明的分散式資料庫。不過,實現分散式關係資料庫有幾個關鍵挑戰:

第一,安全可信。

分散式、雲化環境的複雜性增加了安全風險,比如數據泄露和丟失的風險增加,身份認證和訪問控制以及數據傳輸、存儲安全的控制難度提升。

第二,事務系統的正確性及性能。

分散式資料庫中經常有一次操作涉及多台資料庫的場景,需要一種方案來維護整個資料庫集群事務的ACID特性,避免出現部分成功部分失敗等無法接受的情況。

另外,在大併發場景下事務管理器容易成為性能的單點瓶頸,比如獲取事務唯一標識、全局快照、頻繁交互導致大量的網路通信和鎖等待等。

第三,分散式查詢能力。

在分散式系統中,需要在最短時間內獲取準確的查詢結果,提升查詢性能。

第四,高可用能力。

分散式資料庫需要確保異常場景下(如:節點硬體故障或者Bug宕機等)資料庫系統的連續可用。

分散式資料庫的挑戰和關鍵技術

GaussDB分散式資料庫研發了一系列高性能、高可用、安全特性迎接上述四大挑戰,下麵挑選幾個有代表性的特性加以說明。

全密態

傳統的加密方式在服務端加密,密鑰管理員是可以獲取的。而全密態資料庫的密鑰掌握在用戶自己手上,資料庫管理員無法獲取,加解密過程僅在客戶側完成,數據在存儲、傳輸、查詢整個生命周期過程中均以密文形態存在,避免管理員惡意獲取密鑰解密數據。

全密態資料庫

分散式事務GTM-Lite

如下圖所示,GaussDB沒有採用傳統的事務列表的管理方式,而是提供了一個CSN(提交系列號),通過對比CSN的大小來實現事務可見性判斷。

GTM-Lite技術示意

當事務開始時,根據事務隔離級別的不同,從GTM-Lite獲取一個CSN值,作為這個事務的查詢快照點(如果是可重覆讀,只需要在事務開始時獲取一次CSN值,如果是讀已提交,每次SELECT時都需要重新取一次CSN值)。

當事務提交時,向GTM-Lite申請一個新的CSN值,作為這個事務提交CSN值,並記錄到事務提交記錄中。

GTM-Lite技術通過CSN提交序列號進行可見性判斷,無需耗費大量計算資源來遍歷列表;無鎖化原子操作提供CSN序列號,無需鎖等待;節點間事務交互僅需要一個CSN,網路開銷跟事務規模無關。在保證事務全局強一致的同時,提供高性能的事務處理能力,避免了單GTM的性能瓶頸。

分散式查詢優化

1. 分散式執行

GaussDB是如何處理分散式資料庫集群中的業務應用SQL的呢?

1)業務應用的SQL會下發給CN節點;

2)CN利用資料庫的優化器生成分散式的執行計劃,每個DN會按照執行計劃的要求處理數據;

3)數據基於一致性Hash演算法分佈在每個DN,因此DN在處理數據的過程中,可能需要從其他DN獲取數據,GaussDB提供三種stream流(廣播流broadcast、聚合流gather和重分佈流redistribute)實現數據在DN間的流動;

4)DN將結果集返回給CN進行彙總;

5)CN將彙總的結果返回給業務應用。

分散式查詢示意

讓我們展開看一下節點間的數據交換。比如某條SQL的執行邏輯如下圖所示:

SQL執行邏輯

以兩個DN為例, 在執行過程中,DN會按照redistribute鍵將數據發送到對應的節點。

Redistribute運算元接收到C/D兩表join的數據之後,根據重分佈鍵計算將數據發給DN1還是DN2,Redistribute Collector收集到重分佈之後的數據之後發給上層的Join運算元再做Join計算。

CN、DN間的數據流動

另外,GaussDB的優化器會根據統計信息選取針對當前SQL性能最優的Stream流運算元完成CN、DN間的數據流動。

2. 全並行架構

GaussDB採用全並行架構,從MPP節點並行、SMP線程並行、到SIMD指令並行,到LLVM CodeGen技術,全面挖掘系統計算資源的潛力,提升查詢性能。

高可用

1. GaussDB重做日誌

重做日誌在如下場景可以發揮作用,提升系統的可用性

1)當資料庫發生故障,如宕機,可以通過重做日誌文件恢複數據。

2)HA架構下,主備通過重做日誌文件進行數據同步。

3)備份恢復時,通過歸檔重做日誌文件實現PITR。

GaussDB使用WAL (Write Ahead Log) 機制實現重做日誌,在提升可用性的同時兼顧性能,即在數據修改時遵循 no-force-at-commit 策略,在提交時並不強制寫。為了保證數據在資料庫發生故障時可以恢復,通過Redo 機制,用連續的、順序的日誌條目的寫出將隨機的、分散的數據塊的寫出推延,這個推延使得數據的寫出可以獲得批量效應的性能提升。

2. 分散式部署

GaussDB支持多種高可用部署形態,保證系統的穩定性和可靠性。下麵我們看兩個典型案例。

1)兩地三中心。

同城有兩個雙活數據中心,兩個數據中心同時承載業務,異地一個容災數據中心;同城可實現節點級、AZ級、數據中心級等故障高可用,同時提供跨城的異地容災能力。

GaussDB兩地三中心高可用部署

2)同城3AZ高可用+異地容災。

同城採用邏輯3AZ、3副本部署,異地採用單AZ、3副本部署,提供了同城抵禦節點級故障和AZ級故障的能力,跨城的Region級容災的能力。

GaussDB同城3AZ高可用+異地容災

分散式資料庫技術的發展方向

基於新需求、新場景、以及全池化架構、新網路和大模型等新技術的出現,我們認為分散式資料庫技術主要向以下六個方向發展。

分散式資料庫技術的發展方向

高可用能力的持續提升

高可用是目前大多數金融政企客戶首要關註的問題,特別是對於多地、多中心容災有要求的客戶。針對這樣的客戶,華為雲GaussDB已經提供了多種解決方案,如支持同城雙活、異地容災、兩地三中心的解決方案,支持同城雙活強同步的解決方案,支持非同步數據複製、多地多活的高可用解決方案。

面向未來,分散式資料庫將具備真正全球部署能力的多活架構。

軟硬體深度協同

硬體和軟體兩者之間相輔相成,互相促進。利用新型硬體(GPU、FPGA、高速網路)和華為在晶元、伺服器、存儲、網路、操作系統、資料庫的全棧軟硬體能力,提升性能和高可用能力。

首先,資料庫的持久化邏輯,深度整合到了計算與存儲分離的技術底座中,分散式資料庫可以獲得在容量、彈性、擴展性方面的巨大提升,同時能提供給客戶一致的體驗。

其次,從計算節點卸載下推到存儲中,特別是對一些複雜的查詢處理,同時疊加並行處理能力,使得這些計算邏輯能充分利用下麵整個存儲池的能力,同時最關鍵的是能做到對業務透明。

最後,就是高性能。高性能的實現除了I/O聚合之外,單條交易的本質就是網路的時延和處理的時延。所以,網路對於分散式資料庫的時延(性能)影響是巨大的。

總而言之,軟硬協同帶給我們的不僅僅是性能擴展方面的優勢,更是可以通過軟硬協同打造真正企業級的可靠性。

企業級混合負載 (HTAP)

近年來企業級混合負載(HTAP)的興起,旨在打破事務處理(TP)和分析(AP)之間的壁壘。分散式資料庫都應具備混合負載能力,即在支持高併發、事務性請求的同時,對分析型的複雜查詢提供了良好的支持,從而大幅度降低成本,同時提高企業決策的效率。

HTAP架構的核心技術:

第一,透明路由。通過自動選擇行存引擎、列存引擎以及行列組合,提供查詢的準確性和實時性,增加客戶的易用性,提升HTAP產品的商用價值。

第二,性能提升。TP要求的是低時延、高吞吐,而AP要求的是複雜查詢的能力。常規執行優化技術包括並行執行、編譯執行、向量化執行等,在這些技術的基礎上進一步加速複雜查詢,支撐企業級混合負載。

第三,數據新鮮度。保證數據高新鮮度、高性能,保證HTAP架構能夠具備更多應對用戶的能力。

第四,資源隔離。用戶對TP性能要求比較高,在引入實時AP的同時,不能影響TP的能力和性能,需要在資源隔離、數據新鮮度以及性能的提升方面做好權衡。

雲原生多主

單一架構其實並不能解決今天行業碰到的所有問題,但雲原生多主架構可以幫助解決兩類問題:

第一個,是高可用的問題,希望能基於多主架構,解決切換時業務中斷的問題。

第二個,是擴展性的問題,基於多主架構,融合軟硬協同的進展,真正能在計算節點以下,持續提升產品的性能和彈性。

數據安全可信

當今世界,每個國家、組織和個人都在關註安全、合規和隱私的問題,幾年前數據無保護隨意獲取並使用的便利不再,這也促進了技術的進步和落地。未來,全行業都會面臨越來越嚴格的對於可信安全方面的要求。

全密態是華為雲資料庫為了提升隱私保護能力研製的一項關鍵技術,全密態支持數據在整個計算過程中同樣是以密文形式存在,實現了讓整個敏感數據在全生命周期當中都得到保護。因此,無論數據處於何種狀態,攻擊者都無法獲取到有效信息,從而保障了企業數據全生命周期的隱私安全。

AI-Native

機器學習已被廣泛用於優化數據管理問題,如數據清理、數據分析、查詢重寫、資料庫診斷等。然而,傳統的機器學習演算法無法解決泛化和推理問題。幸運的是,大模型(LLM)可以幫助解決這些限制,為智能化數據管理提供了很好的機會。

藉助AI/LLM,未來分散式資料庫將朝著全流程、全鏈路、高效易用的智能化資料庫的方向發展,在資料庫咨詢、開發、運維等關鍵階段,構建相應的自動化能力:

第一,咨詢階段,提供專家式輔助,制定精細化方案。

  • HLD助手,結合專家經驗,自動生成資料庫HLD;
  • DB知識庫,通過積累運維工單、答疑、文檔手冊等,形成資料庫行業知識庫;
  • 問答助手,通過提供ChatBot,實現互動式運維。

第二,開發階段,提供開發輔助,提升SQL開發效率。

  • 通過構建NL2SQL轉換能力,讓自然語言轉換為SQL語句;
  • 同時,增強的SQL轉換能力提升異構資料庫間的SQL語句轉換自動化率。

第三,運維階段,實現預測性維護,提升系統可靠性。

  • 智能巡檢,可以構築Schema/SQL、中間件/告警等全鏈路可觀測可跟蹤能力;
  • 智能故障處理,通過全鏈路感知編排,提供精準分析,快速定位故障並給出建議;
  • SQL質量提升能力,可以快速找出問題SQL,診斷根因,提供全局分析。

綜上,分散式資料庫性能卓越,憑藉高可用、高可擴展性、高性價比等優勢,已經被對資料庫要求最嚴苛的金融行業所認可,並逐漸被應用在更廣闊的領域。不過,從總體發展狀態來看,目前還處於早期,但發展方向明朗,上升空間很大。

參與有獎

GaussTech技術專欄第一期話題討論:

對於分散式資料庫的未來發展,你怎麼看?

1.你認為分散式是資料庫未來的發展趨勢嗎?

2.哪種架構會得到更多企業的青睞?

3.分散式資料庫技術又會向什麼方向發展?

點擊鏈接,即可參與“GaussTech技術專欄第一期”話題討論,就有機會獲得HUAWEI mini藍牙音箱 _綺境森林、《華為數據之道》書籍、新貴族系列中性筆、平裝套芯筆記本、GaussDB字母筆、炫彩馬卡龍指甲刀等好禮,快來參與吧!

 

點擊關註,第一時間瞭解華為雲新鮮技術~

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 目錄微型電腦的硬體共性結構及基本性能指標關於存儲器的介紹微型電腦的基本性能指標1. 字長2. 主頻3. 存儲容量4. 外設擴展能力5. 軟體配置情況Arm Cortex 系列微處理器系列概述Arm Cortex-A 系列處理器Arm Cortex-R 系列處理器Arm Cortex-M 系列處理 ...
  • 目錄遠程策略配置啟用遠程桌面使用設置啟用遠程桌面使用控制面板啟用遠程桌面 工作中有時需要使用遠程桌面,但工控機上面的策略一般都比較保守,遠程桌面經常會失敗。這裡記錄一下使用的遠程策略配置,方便以後工作中使用。 遠程策略配置 運行命令 gpedit.msc 打開本地策略編輯: 打開 電腦配置->管理 ...
  • 參考 Fedora Quick Docs Fedora Server Documentation Deploy an ARM64 Fedora VM on your PC: 3 steps Architectures/AArch64/Install with QEMU Virtualization ...
  • 華為雲GeminiDB是一款相容Redis協議的彈性KV資料庫,支持遠超記憶體的容量和極致的性能,技術自主創新,不受Redis協議變更影響。 ...
  • 資料庫三大範式的學習與資料庫表設計的瞭解 內容簡單介紹 對於資料庫三大範式的理解以及一些設計表示要註意的方面 本章內容梳理圖 資料庫三大範式比較官方的定義 資料庫的三大範式(Normal Forms)是關係資料庫設計中用於確保數據結構化、減少數據冗餘、並提高數據完整性的指導和規則。 以下是三大範式的 ...
  • 1.背景概述 最近在做數據同步測試,需要通過DTS將kafka中的數據同步到資料庫中,4G的數據量同步到資料庫用了大約4個多小時,這看起來並不合理;此時查看資料庫所在主機的CPU,IO的使用率都不高,沒有瓶頸;最後通過排查發現由於kafka,DTS,資料庫不再同一個機房,網路延遲較大,導致同步速率緩 ...
  • 目錄一、什麼是多實例二、MySQL多實例配置1、創建數據目錄2、創建配置文件3、編輯330{7..9}的配置文件4、初始化330{7..9}數據5、修改目錄許可權6、啟動多實例7、查看server_id8、進入單獨的MySQL實例9、關閉實例 一、什麼是多實例 Mysql多實例就是在一臺伺服器上同時開 ...
  • 升級背景 因項目需要使用數據質量模塊功能,可以為數倉提供良好的數據質量監控功能。故要對已有2.0版本升級到3.0版本以上,此次選擇測試了3.0.1 和 3.1.1 兩個版本,對進行同數據等任務調度暫停等操作測試,最後選擇3.0.1 版本 原因: 1. 3.1.1 在測試sql任務時 ,同時啟動上百s ...
一周排行
    -Advertisement-
    Play Games
  • 1、預覽地址:http://139.155.137.144:9012 2、qq群:801913255 一、前言 隨著網路的發展,企業對於信息系統數據的保密工作愈發重視,不同身份、角色對於數據的訪問許可權都應該大相徑庭。 列如 1、不同登錄人員對一個數據列表的可見度是不一樣的,如數據列、數據行、數據按鈕 ...
  • 前言 上一篇文章寫瞭如何使用RabbitMQ做個簡單的發送郵件項目,然後評論也是比較多,也是準備去學習一下如何確保RabbitMQ的消息可靠性,但是由於時間原因,先來說說設計模式中的簡單工廠模式吧! 在瞭解簡單工廠模式之前,我們要知道C#是一款面向對象的高級程式語言。它有3大特性,封裝、繼承、多態。 ...
  • Nodify學習 一:介紹與使用 - 可樂_加冰 - 博客園 (cnblogs.com) Nodify學習 二:添加節點 - 可樂_加冰 - 博客園 (cnblogs.com) 介紹 Nodify是一個WPF基於節點的編輯器控制項,其中包含一系列節點、連接和連接器組件,旨在簡化構建基於節點的工具的過程 ...
  • 創建一個webapi項目做測試使用。 創建新控制器,搭建一個基礎框架,包括獲取當天日期、wiki的請求地址等 創建一個Http請求幫助類以及方法,用於獲取指定URL的信息 使用http請求訪問指定url,先運行一下,看看返回的內容。內容如圖右邊所示,實際上是一個Json數據。我們主要解析 大事記 部 ...
  • 最近在不少自媒體上看到有關.NET與C#的資訊與評價,感覺大家對.NET與C#還是不太瞭解,尤其是對2016年6月發佈的跨平臺.NET Core 1.0,更是知之甚少。在考慮一番之後,還是決定寫點東西總結一下,也回顧一下.NET的發展歷史。 首先,你沒看錯,.NET是跨平臺的,可以在Windows、 ...
  • Nodify學習 一:介紹與使用 - 可樂_加冰 - 博客園 (cnblogs.com) Nodify學習 二:添加節點 - 可樂_加冰 - 博客園 (cnblogs.com) 添加節點(nodes) 通過上一篇我們已經創建好了編輯器實例現在我們為編輯器添加一個節點 添加model和viewmode ...
  • 前言 資料庫併發,數據審計和軟刪除一直是數據持久化方面的經典問題。早些時候,這些工作需要手寫複雜的SQL或者通過存儲過程和觸發器實現。手寫複雜SQL對軟體可維護性構成了相當大的挑戰,隨著SQL字數的變多,用到的嵌套和複雜語法增加,可讀性和可維護性的難度是幾何級暴漲。因此如何在實現功能的同時控制這些S ...
  • 類型檢查和轉換:當你需要檢查對象是否為特定類型,並且希望在同一時間內將其轉換為那個類型時,模式匹配提供了一種更簡潔的方式來完成這一任務,避免了使用傳統的as和is操作符後還需要進行額外的null檢查。 複雜條件邏輯:在處理複雜的條件邏輯時,特別是涉及到多個條件和類型的情況下,使用模式匹配可以使代碼更 ...
  • 在日常開發中,我們經常需要和文件打交道,特別是桌面開發,有時候就會需要載入大批量的文件,而且可能還會存在部分文件缺失的情況,那麼如何才能快速的判斷文件是否存在呢?如果處理不當的,且文件數量比較多的時候,可能會造成卡頓等情況,進而影響程式的使用體驗。今天就以一個簡單的小例子,簡述兩種不同的判斷文件是否... ...
  • 前言 資料庫併發,數據審計和軟刪除一直是數據持久化方面的經典問題。早些時候,這些工作需要手寫複雜的SQL或者通過存儲過程和觸發器實現。手寫複雜SQL對軟體可維護性構成了相當大的挑戰,隨著SQL字數的變多,用到的嵌套和複雜語法增加,可讀性和可維護性的難度是幾何級暴漲。因此如何在實現功能的同時控制這些S ...