這些年大家都在談分佈式數據庫，各大企業也紛紛開始做數據庫的分佈式改造。那麼，所謂的分佈式數據庫到底是什麼？採用什麼架構？優勢在哪？爲什麼越來越多企業選擇它？分佈式數據庫技術會向什麼方向發展？帶着這些疑問，一探究竟吧！參與文末的話題互動，更有機會贏取精美獎品~
分佈式數據庫的架構演進
隨着數據量的爆發增長，傳統集中式數據庫面臨極大的挑戰：
- 性能瓶頸：數據規模爆發增長，傳統集中式數據庫難以維持數據量大時的性能，而分佈式數據庫的性能可以水平擴展；
- 缺失混合負載能力：數據量爆發增長帶來對數據分析（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字母筆、炫彩馬卡龍指甲刀等好禮，快來參與吧！