DTCC演講 | PolarDB-X技術架構:雲原生分散式資料庫
作者:阿里雲PolarDB-X資料庫研發負責人 黃貴
PolarDB-X是一款雲原生分散式資料庫,為儲存計算分離的分散式資料庫架構,由以下幾個元件構成:
①後設資料服務(GMS)。GMS是一個高可用叢集,利用 Paxos 協議實現資料的高可用,負責儲存全域性的後設資料,包括資料的分片、資料節點計算節點的拓撲資訊以及日誌節點拓撲資訊,還負責提供全域性授時的服務,用於判斷資料的全域性可見性,提供外部一致性事務保證。
②計算節點。計算節點無狀態,負責接收應用發來的 SQL ,任意計算節點都可以完成 SQL 的解析、重寫、最佳化、轉化為物理執行計劃並執行,支援MPP 的執行框架,負責整個計劃的排程與執行,並最終返回結果。
③資料節點。是資料儲存的載體,同時也負責單機執行計劃的執行。資料節點會組成複製組,每個組由Paxos 一致性協議保證資料的強一致的高可用,為了橫向的擴充套件能力會將其切分為很多分片。資料片會根據一定的規則分佈在各個DN複製組上。
④日誌節點。提供全域性一致的 binlog 能力,相容 MySQL 生態。日誌節點輸出的全域性一致Binlog完全相容單機 MySQL 提供的 Binlog ,因此可以將整個 PolarDB-X 看作單機的MySQL來使用,包括原來的生態、對接的下游數倉、大資料類的生態,都可以透過CDC 消費日誌。
PolarDB-X 架構在阿里雲平臺上,包括生命週期的管理、備份、容災、資料遷移、資料的DevOps、SQL 的全流程診斷、DAS等都依託於雲平臺提供的一整套資料庫服務。
PolarDB-X 作為分散式資料庫,具有以下三個特點:
第一,原生MySQL生態。提供完全相容 MySQL 的能力,包括語法、語義、功能、協議以及生態的相容。原生的 MySQL JDBC的connector或 Java 、Go 等版本的客戶端connector都可以直接連線 PolarDB-X,享受完全一致的體驗。
生態的相容方面,利用CDC,PolarDB-X既可以作為 MySQL 的備機,透過 Binlog 同步資料,使用 MySQL 的 replication 功能,實現主備高可用的模式,也可以作為一個大的MySQL資料庫 透過 CDC 同步給下游的資料生態系統。
第二,一體化透明分散式。PolarDB-X希望使用者不再需要關注資料分佈的細節,也無需為此做太多最佳化,我們希望儘可能地為使用者提供與單機資料庫一致性的體驗,不管是建表還是應用均無需做任何改變即可享受到分散式資料庫的擴充套件能力。降低使用者的使用門檻。另外,PolarDB-X支援手工分割槽模式,按實際業務需求進行調優。分散式主要體現在自動擴充套件、分散式事務以及Online DDL。
第三,企業級資料庫的能力,包括強一致資料的高可用、支援HTAP以及對於資料安全的保障。
分散式資料庫並不是新技術,只是早期的分散式資料庫更多地存在於學術界,作為研究物件。2000 年左右,網際網路開始蓬勃發展,業內意識到了單機資料庫以及集中式資料庫的侷限性,無法應對網際網路的業務增長帶來的海量資料以及對於大規模資料的高併發、高吞吐的寫入需求。
為了增強資料庫的擴充套件性,逐漸發展出了 NoSQL 。而 NoSQL 資料庫為了擴充套件性,放棄了很多關係型資料庫的實用特性,包括ACID等,是的應用不得不編寫複雜的邏輯來儘可能保證資料一致性,變得更復雜。後來,關係型資料庫和分散式技術相結合發展出了NewSQL,這也是分散式資料庫從理論走向應用的發展階段,彼時的分散式資料庫更多地被大型網際網路公司使用。
到了雲時代,分散式資料庫作為雲產品為使用者提供通用的資料庫服務,真正進入商業化發展的階段,不僅關注擴充套件性,還關注易用性以及企業級的特性,因此也必然會出現相容性、資料庫運維等能力上的要求。
分散式資料庫面臨幾個較為突出的問題。
①相容性:傳統資料庫的應用如何更便捷的遷移到分散式資料庫上?
②使用門檻:使用者有使用分散式資料庫的訴求,但是又不希望投入太多學習成本。
③擴充套件能力:分散式架構能否實現真正的線性擴充套件?
④運維複雜度:分散式系統天然具備複雜性,如何應對運維管理上的挑戰?在分散式資料庫上保證ACID、保證資料一致性比傳統資料庫更具難度,比如在資料量巨大的分割槽表上做DDL或建立索引需要付出高昂的代價。
PolarDB-X 全面相容 MySQL 資料庫,包括功能上的相容和生態上的相容。
功能上並不追求百分之百的相容。上圖中圓圈為 MySQL 的能力邊界,塗色的部分是 PolarDB-X目前已經覆蓋的能力。部分PolarDB-X的能力與 MySQL 的實際能力依然存在一定差距,也有部分超出了MySQL的能力。判定相容性的原則需要以使用者訴求為依據,我們會優先覆蓋常用功能,對於不常用的功能,會有選擇性地支援,並逐步補全。
目前, PolarDB-X對 MySQL 的大部分功能基本已經實現相容,也包括擴充套件性的能力,比如儲存過程觸發器、外來鍵等等在分散式資料庫上較難支援的功能,而高可用容災、高併發讀寫等方面的能力已經遠超出現有 MySQL 的能力。
生態的相容主要利用全域性一致的Binlog,即CDC。 CDC 是一個高可用叢集,能夠提供全域性一致的 Binlog 服務。PolarDB-X 作為分散式資料庫,存在很多資料節點,每個資料節點都有日誌流。為了保證資料一致,CDC 會對多機上的日誌做歸併、排序、整流,最終提供與使用者事務發生順序一致的全域性 Binlog 日誌流。日誌流完全相容 MySQL 單機 Binlog ,格式完全一致。下游生態系統消費Binlog時,可以將其看作單機MySQL 來使用。
分散式系統作為雲上的服務,希望為使用者提供集中分散式一體化的體驗。PolarDB-X提供了標準版和企業版兩種形態,兩者可以平滑遷移。標準版百分之百相容單機MySQL,提供了高可用的能力。企業版提供了典型的分散式能力。
對於很多使用者而言,如果當前業務規模不大,則可以先選擇標準版。業務規模擴大以後,無需任何修改即可平滑遷移至企業版。原先在單機上建的表能夠自動變為分散式的表,無論是查詢還是事務,使用上均沒有任何區別。也可以透過 DDL語句指定資料分割槽的規則,保留了按照業務特性進行資料分佈的需求。
集中分散式一體化有兩層含義:其一,既能滿足集中式的需求,也能滿足分散式需求;其二,集中式到分散式可實現完全透明轉化。
切換到分散式形態時,如何保證集中式的體驗?
PolarDB-X提供了 庫級AUTO模式,資料分佈對使用者完全透明,無需指定分割槽鍵,在集中資料庫裡建一張分散式表,資料庫會自動為其做分割槽。同樣,也可以建全域性二級索引加速查詢。
但這必然存在代價,比如預設按主鍵做分割槽,分割槽不一定符合需求。其次,全域性索引開銷較大,導致寫入開銷較大,可能無法滿足對業務效能的要求。
另外,PolarDB-X提供了手動分割槽的模式,可以手動指定分割槽演算法,採用了完全相容 MySQL 的 partition 分割槽表語法,分割槽的演算法可以相容 Oracle 的所有的分割槽的演算法。同時,也可以指定分割槽在不同條件下存放的位置,真正完全契合業務的訪問模式。
分散式資料庫的顯著優點在於能夠無限擴充套件,然而,擴充套件並不是沒有代價的。一旦資料進行擴充套件以後,集中式資料數庫上的事務操作可能會變為跨分割槽的分散式事務操作,會導致效能急劇損失。如上圖所示,即便只有2個NUMA節點,跨NUMA Node訪問的效能也將至少下降1倍。
而同樣的事情發生在分散式架構上,效能損失會更明顯。NUMA Node 之間有匯流排連線,而分散式架構下只有網路連線,即便是高效能網路也會產生巨大的網路延時,導致效能急劇下降。
我們曾經做過實驗,加一個全域性二級索引,寫入效能下降30%;而加8個全域性二級索引,寫入效能將會下降一個數量級。
因此,分散式系統能否做線性擴充套件,取決於訪問模式。如果系統中跨分割槽的事務很少,理論上可以實現線性擴充套件;但如果系統中跨分割槽的事務比較多,則無法實現線性擴充套件。
在硬體沒有實現突破時,很難提升分散式事務的效能。而我們能做的只有儘量減少分散式事務的比例。
因此,我們提出了做資料親和性繫結的概念,將業務上有關聯的表,設定同樣的資料分割槽規則,繫結為一個表組,作為排程基本單位。一個表組裡的表都採用同樣的分割槽規則、同樣的分割槽演算法以及同樣的分割槽個數,減少了分散式事務佔比,從而降低分散式事務帶來的效能開銷。
繫結表組最優的方案是自動識別使用者的訪問模式,自動聚合。
在分散式系統裡,一旦負載均衡受到了挑戰,則會出現資料熱點。PolarDB-X能夠進行實時的資料熱點提取,可以將熱點資料分片重新打散,提取到多個分割槽。它提供了豐富的 DDL 操作語句,能夠實時有效地消除熱點,達到系統的負載均衡。
電商業務一般會按買賣家做分割槽,而大賣家會成為熱點分割槽,此時會重新將賣家再按 order ID做雜湊分割槽,打散熱點,這是二級分割槽的作用。
二級分割槽使用靈活,支援與一級分割槽一樣多的分割槽策略,是完全正交的策略。而且可以任意組合,支援模板化和非模板化的方式,能夠實現精細化控制。比如二級分割槽可以對所有一級分割槽制定統一的規則,將每個一級分割槽都分為 5 個子分割槽,也可以只將某一個分割槽分為 5 個分割槽,其他一級分割槽不變,這樣的模式可以根據業務特點進行靈活的調整,也能夠避免分割槽數量無限膨脹。
分散式帶來的好處在於在企業級能力上提供了一致性保證,利用Paxos+2PC實現了任何時候都有資料強一致的保證。
Paxos主要用於 DN 的複製組,保證資料副本之間的一致性。 MVCC 加2PC 的分散式事務的方式保證了外部的一致性。TSO用於做 Snapshot 隔離級別、事務隔離級別的一致性保證,其優勢在於,做只讀事務時,無需對資料進行加速,透過快照也可以讀到一致的資料檢視,不會讀到某個部分的事務。
企業級能力這一層做了一體化,包括分散式一體化以及線上與歷史歸檔資料一體化。
資料在分散式系統裡的體量非常大,且很多資料均有明顯的冷熱區隔。為了降低成本,我們實現了自動歸檔的能力。
歸檔過程全自動化,在建表時指定資料過期規則,會將過期資料自動建好分割槽進行歸檔,儲存到低成本的OSS儲存裡。自動歸檔也會對冷資料的做壓縮,大幅降低資料容量,結合OSS 低成本的混合儲存方式,相對線上資料的成本有 20 倍下降。
過期的分割槽可以作為外表做線上查詢,即對歷史歸檔資料一樣可以與線上資料做混合查詢。
為了解決分散式資料庫的運維問題,我們做了很多工作,比如做了整體的雲管平臺,核心層面實現了線上資料字典變更,只需ONE Sql,One Enter即可實現。無論是分割槽表的演算法變更、分割槽鍵要變還是熱點資料分裂,都可以用 DDL 的方式操作,所有 DDL 都為 online ,不會影響現有的資料查詢和事務操作。
使用者無需專門找運維視窗,隨時隨地可做資料字典的變更以及演算法的變更來提升效能。
同時,我們提供了完整的實時觀測運維平臺。
我們對資料來源進行了歸類整理,包括metrics、 tracing 、logging,會在 SQL執行路徑上做很多埋點,便於跟蹤整個雲管平臺,進行監控告警、SQL洞察、效能分析診斷、 Profiling 以及Tuning,也可以根據SQL執行模式進行索引推薦。
PolarDB-X有以下幾種典型的應用場景。
PolarDB-X 可以用於替換開源分庫分表。
可以將使用者自建資料庫透過DTS同步到PolarDB-X叢集,可以對原有的建表做結構遷移、將資料做全量遷移以及做實時的增量遷移。
PolarDB-X 支援分庫分表的模式,對接原有的分庫分表時無需對使用者應用做過多改動。
PolarDB-X還可用於單機平滑演進到分散式。
單機 MySQL 的資料庫可以一鍵遷移到線上分散式資料庫,應用 0 修改,在PolarDB-X上直接實現建表語句即可。
完成演進後,原先在單機 MySQL 上難以解決的問題,比如大表如何做拆分等問題都可以在分散式系統上得到很好的解決。分散式系統對於不同的表有不同的解決方法,比如大表可以做成分割槽表,按指定的方式做分割槽;比如針對熱點表,可以將熱點打散後做成分割槽表;一些普通的單表遷到分散式系統後依然可以作為單表使用。
PolarDB-X的另一典型場景是海量資料大集中。
原先的系統中使用了很多資料庫,各種資料庫之間存在資料孤島問題,如何做融合的查詢分析?
PolarDB-X結合DTS 以及ADB提供了一整套解決方案,同時滿足線上資料的處理以及線上資料分析的需要。PolarDB-X還可與ADB做深度融合,中間不再需要資料傳輸的工具,只需進行實時的資料轉換,ADB實時分析轉換好的記憶體的資料副本,實現完全一體化的資料處理以及資料分析的一致性體驗。
針對金融場景的資料強一致需求,PolarDB-X也能提供非常完備的高可用解決方案以及災備方案,包括同城多機房、兩地三中心等解決方案,能夠保證跨地域的高可用、機房級別的容災以及保證資料的一致性。
未來,PolarDB-X將持續往一體化方向演進。
包括集中分散式一體化:要使分散式資料庫更加接近於單機資料庫的體驗;負載處理一體化:能夠處理 transaction 和 analytic 的負載。也包括線上和歷史資料一體化,與雲的基礎設施更加深度的融合,利用雲底下的共享儲存、雲的晶片做硬體結合的一體化。
事務處理與分析一體化利用CDC做實時同步,存放到雲端儲存上,以列式的壓縮格式做儲存。同時 CN 也支援行列混合的分析查詢,對最佳化器具有較高要求,需要能夠識別出處理事務與查詢事務,判斷將其放於行存執行還是列存上執行,計算具體的cost。
未來,我們也計劃透過ADB數倉利用大規模資料分析的計算引擎做一體化的分析工作。
雲原生與分散式融合一體化架構也是未來發展趨勢。
目前所有的DN資料儲存在本地磁碟,未來會將其儲存到共享儲存池,這是未來分散式資料庫發展的重要方向。
我們在做擴充套件時應儘量不動資料,而是實時或獨立地擴充套件計算節點和儲存節點。擴充套件了節點以後,資料要做大量搬遷工作。而如果底下是共享儲存,則無須進行搬遷工作,新增節點後即可投入服務。
另外,共享儲存能夠儲存的資料量會遠遠超過單機的資料規模,也更有可能減少資料跨分割槽的可能性,從而有效減少分散式事務帶來的代價。
如何更好地利用雲的基礎設施提供更好的擴充套件能力以及彈效能力的分散式資料庫,是未來雲原生分散式資料庫的重要發展方向。
來自 “ 廠商動態 ”, 原文作者:廠商動態;原文連結:廠商動態,如有侵權,請聯絡管理員刪除。
相關文章
- DTCC 2020 | 解密OceanBase原生分散式資料庫解密分散式資料庫
- 分散式資料庫的架構演變之路分散式資料庫架構
- DTCC 回顧:技術破局,分散式資料庫創贏未來分散式資料庫
- GaussDB(for MySQL)雲原生資料庫技術演進和挑戰MySql資料庫
- 分散式資料庫技術的演進和發展方向分散式資料庫
- MyCat 啟蒙:分散式系統的資料庫架構演變分散式資料庫架構
- 資料庫的未來:雲原生+分散式資料庫分散式
- 分散式系統架構與雲原生—阿里雲《雲原生架構白皮書》導讀分散式架構阿里
- 阿里雲PolarDB-X資料庫透過分散式資料庫金融標準驗證阿里資料庫分散式
- 2018年喜歡的架構技術演講架構
- 評《資料原生的金融技術架構》架構
- 附PPT下載|DTCC演講:降本增效,阿里雲一站式資料庫上雲實踐阿里資料庫
- 分散式資料庫技術論壇分散式資料庫
- 分散式資料庫架構原理 - Alex Petrov分散式資料庫架構
- 技術沙龍 | 雲時代下的架構演進—企業雲及雲原生技術落地實踐架構
- 技術分享 | 如何迅速將分散式政企應用轉型為雲原生微服務架構分散式微服務架構
- 聊聊Oracle的分散式資料庫技術Oracle分散式資料庫
- (二) MdbCluster分散式記憶體資料庫——分散式架構1分散式記憶體資料庫架構
- 崑崙分散式資料庫架構介紹分散式資料庫架構
- Spring Cloud微服務分散式雲架構 - 整合企業架構的技術點SpringCloud微服務分散式架構
- OceanBase 首席架構師:關聯式資料庫到三代分散式資料庫,我親歷的資料庫演進史架構資料庫分散式
- 騰訊雲TDSQL-C雲原生資料庫技術SQL資料庫
- 講述分散式架構雲平臺解決方案分散式架構
- (二)spring cloud微服務分散式雲架構 - 整合企業架構的技術點SpringCloud微服務分散式架構
- (二)spring cloud微服務分散式雲架構-整合企業架構的技術點SpringCloud微服務分散式架構
- 華為CloudNative分散式資料庫技術解析Cloud分散式資料庫
- 分散式資料庫技術論壇回顧分散式資料庫
- 崑崙分散式資料庫技術特點分散式資料庫
- 崑崙分散式資料庫技術優勢分散式資料庫
- 阿里分散式資料庫未來技術之路阿里分散式資料庫
- 從0.5到4.0,OceanBase單機分散式一體化的技術演進|DTCC 2022分散式
- 圖解分散式架構的演進圖解分散式架構
- 面向資料架構的雲演變架構
- 技術架構演進的思考架構
- 分散式系統技術:儲存之資料庫分散式資料庫
- 阿里雲解決方案架構師,講述分散式架構雲平臺解決方案阿里架構分散式
- 金融級分散式資料庫架構設計要點分散式資料庫架構
- 2024年的雲原生架構需要哪些技術棧架構