PolarDB-X 開源脈絡(luò)

• 2021年10月在云棲大會上，阿里云正式對外開源了云原生分布式數(shù)據(jù)庫PolarDB-X，采用_全內(nèi)核開源_的模式，開源內(nèi)容包含計算引擎、存儲引擎、日志引擎、Kube等。

• 2022年1月，正式發(fā)布 2.0.0 版本，新增_集群擴縮容、以及binlog生態(tài)兼容_等特性，兼容 maxwell 和 debezium 增量日志訂閱，以及新增其他眾多新特性和修復若干問題。

• 2022年3月，正式發(fā)布 2.1.0 版本，全面提升 PolarDB-X 穩(wěn)定性和生態(tài)兼容性，其中包含_基于Paxos的三副本共識協(xié)議_。

• 2022年5月，正式發(fā)布2.1.1 版本，重點推出_冷熱數(shù)據(jù)_新特性，可以支持業(yè)務表的數(shù)據(jù)按照數(shù)據(jù)特性分別存儲在不同的存儲介質(zhì)上。

• 2022年10月，正式發(fā)布2.2.0版本，重點推出符合分布式數(shù)據(jù)庫金融標準下的_企業(yè)級和國產(chǎn)ARM適配_，共包括八大核心特性，全面提升 PolarDB-X 分布式數(shù)據(jù)庫在金融、通訊、政務等行業(yè)的普適性。

• 2023年3月， 正式發(fā)布2.2.1版本，在金融標準能力基礎(chǔ)上，重點加強了_生產(chǎn)級關(guān)鍵能力_，全面提升面向數(shù)據(jù)庫生產(chǎn)環(huán)境的易用性和安全性。

• 2023年10月份，正式發(fā)布 2.3.0版本，重點推出PolarDB-X標準版（集中式形態(tài)），將PolarDB-X分布式中的DN節(jié)點提供單獨服務，支持paxos協(xié)議的多副本模式、lizard分布式事務引擎，同時可以100%兼容MySQL。

• 2024年4月份，正式發(fā)布2.4.0版本，重點推出_列存節(jié)點Columnar_，可以提供持久化列存索引（Clustered Columnar Index，CCI），一張表可以同時具備行存和列存的數(shù)據(jù)，結(jié)合計算節(jié)點CN的向量化計算，可以滿足分布式下的查詢加速的訴求，實現(xiàn)HTAP一體化的體驗和效果。

開源PolarDB-X v2.4.1重要特性

云備份集轉(zhuǎn)儲恢復

PolarDB-X開源版本全面繼承了商業(yè)版本的生產(chǎn)級別的穩(wěn)定性驗證，同時開源和商業(yè)版在數(shù)據(jù)文件的物理格式上是互通的。因此，基于開源版本可以構(gòu)建商業(yè)版本的backup數(shù)據(jù)庫，參考文檔：基于商業(yè)備份集恢復（https://doc.polardbx.com/zh/operator/ops/backup-restore/restore-business-backupset.html）。

PolarDB-X發(fā)布Operator v1.7.0 版本，開始支持從阿里云PolarDB-X實例商業(yè)備份集中恢復出 PolarDB-X 集群。

基于商業(yè)備份集恢復主要為了滿足如下需求：

• 多云冗災。生產(chǎn)實例在阿里云上，但是希望自建該實例的從實例。
• 線下測試使用。雖然已經(jīng)在阿里云公有云上開通PolarDB-X實例，但是有些客戶仍然有一部分線下的自建機器可用于日常測試使用。

總體步驟分為兩部分： 導入備份集 和 發(fā)起恢復任務。比如：運行的導入備份集工具，需要三個配置文件放在工具的配置目錄下：

• 備份集元數(shù)據(jù)，可以通過商業(yè)備份集的OpenAPI DescribeOpenBackupSet，按要求輸入接口參數(shù) RegionId、DBInstanceName、RestoreTime，發(fā)起調(diào)用后可以獲得完整的配置文本，比如包含備份集的物理文件、增量文件各自的下載地址

• 備份存儲地址，目前可以支持SFTP/MinIO/S3/Aliyun OSS 等常見的備份存儲介質(zhì)，參考類似的備份元數(shù)據(jù)配置

運行備份轉(zhuǎn)儲的命令：

docker run  -d -v /root/config:/config --network=host  \
--name=polardbx-backupset-importer \
--entrypoint="/backupset-importer" 
polardbx-opensource-registry.cn-beijing.cr.aliyuncs.com/polardbx/backupset-importer:v1.7.0 \
-conf=/config

備份轉(zhuǎn)儲任務，會通過商業(yè)備份集的元數(shù)據(jù)自動完成下載，并上傳到指定的備份存儲介質(zhì)上。

另外，可以通過PolarDB-X Operator，基于k8s實現(xiàn)通過導入的備份集直接創(chuàng)建實例，參考基于導入的備份集做恢復。

通過備份集的轉(zhuǎn)儲、以及備份集的恢復能力，業(yè)務上可以在線下IDC自建、以及多云ECS環(huán)境，快

速創(chuàng)建PolarDB-X的備份容災環(huán)境。

DDL在線變更

在數(shù)據(jù)庫運維過程中，對字段類型做變更是令人非常頭痛的一件事，在傳統(tǒng)MySQL中，一般需要借助外部的Online DDL工具（比如pt-osc、gh-ost）來實現(xiàn)無鎖變更。

目前，有許多開源的無鎖變更工具為用戶提供了平滑進行列類型變更的解決方案，有效規(guī)避了鎖表問題。其中較為知名的工具包括 GitHub 開源項目 gh-ost 以及 Percona Toolkit 中的 pt-online-schema-change（簡稱 pt-osc）工具，它們的工作流程類似，都包含了以下幾個步驟：

1. 創(chuàng)建一張與原表結(jié)構(gòu)一樣的臨時表
2. 將具體變更操作應用到臨時表上
3. 將存量數(shù)據(jù)拷貝到臨時表中
4. 同步增量修改數(shù)據(jù)到臨時表中
5. 交換原表和臨時表，完成變更

在增量數(shù)據(jù)同步方面，gh-ost 與 pt-osc 實現(xiàn)的方式有所不同，gh-ost 采用 binlog 訂閱進行回放，而 pt-osc 采用的是利用觸發(fā)器進行增量雙寫，但兩種增量方案都并不完美。

比如：gh-ost增量回放和存量數(shù)據(jù)拷貝共用一個線程，速度慢，但侵入性小，在業(yè)務流量較大時會出現(xiàn)binlog追不上，導致永遠無法完成。

比如：pt-osc引入觸發(fā)器會增加死鎖風險，一旦遇到DDL執(zhí)行中斷退出，存在觸發(fā)器殘留，觸發(fā)器無法暫停等問題。

PolarDB-X v2.4.1版本，全面提供了內(nèi)核原生的無鎖變更能力，可以更好的支持類似字段類型變更的場景，重點在增量數(shù)據(jù)同步、智能限速、多版本元數(shù)據(jù)切換上，提供了更多不一樣的設(shè)計，更多可以參考 ??PolarDB-X 原生無鎖變更，比 gh-ost 更快、更穩(wěn)定??

PolarDB-X 新增DDL算法類型，OMC算法（全稱為：Online Modify Column，在線變更列類型）。

語法格式：

ALTER TABLE tbl_name
    alter_option [, alter_option] ...
    ALGORITHM = OMC

實際demo例子：

# 創(chuàng)建測試表
CREATE TABLE t1(a int primary key, b tinyint, c varchar(10)) partition by key(a);

# 修改t1表中b列和c列的列類型
ALTER TABLE t1 MODIFY COLUMN b int, MODIFY COLUMN c varchar(30), ALGORITHM=OMC;

# 修改t1表中b列的名稱和類型，并在該列后面增加一個bigint類型的e列
ALTER TABLE t1 CHANGE COLUMN b d int, ADD COLUMN e bigint AFTER d, ALGORITHM=OMC;

我們也為PolarDB-X OMC算法，與gh-ost/pt-osc做了完整的性能對比，比如：以sysbench oltp_read_write壓測為背景流量，執(zhí)行在線列變更

ALTER TABLE MODIFY COLUMN `sbtest1` MODIFY COLUMN k bigint;

對應的測試結(jié)果如下：

圖片

• 隨著背景流量并發(fā)量的攀升，使用 gh-ost 工具的變更耗時顯著增長，且當并發(fā)量達到 50 時，其增量回放已經(jīng)沒辦法追上流量的修改，無法順利完成變更；

• 即便在面臨 50 并發(fā)的背景流量，pt-osc 工具依舊能夠保證變更任務成功完成，但是變更時間會有所增加；

• PolarDB-X 對分區(qū)表執(zhí)行無鎖列類型變更操作時，展現(xiàn)出了較高的穩(wěn)定性與效率，其變更時長幾乎不受背景流量波動的影響，并且所耗費的時間僅為 pt-osc 工具所需時間的三分之一；

• PolarDB-X 對單表執(zhí)行無鎖列類型變更操作時，盡管其變更時長同樣會隨背景流量并發(fā)量的提升而有所增加，但相比與 pt-osc 與 gh-ost，依然展現(xiàn)出的較高的變更效率，耗時大幅縮減；

在變更操作期間，由于涉及一些資源的競爭，sysbench oltp_read_write 工作負載會受到一定的影響，導致 TPS 會有所下滑，具體下降比率詳情請參見下表：

在單表場景下，盡管 PolarDB-X 的無鎖列類型變更相較于 gh-ost 和 pt-osc 工具表現(xiàn)出更快的執(zhí)行速度，但它對背景流量的暫時性影響要略顯顯著，這也反映了單個 DN 高并發(fā)操作下的一定局限性。

而在分區(qū)表場景下，PolarDB-X 的無鎖列類型變更展現(xiàn)了極佳的性能：不僅變更過程迅速無比，而且其對背景流量的影響控制得與 gh-ost 工具相當，實現(xiàn)了速度與穩(wěn)定性兼顧的優(yōu)越成效。

物理擴縮容

分布式數(shù)據(jù)庫，其中一個重要能力就是水平線性擴展，通過增加分布式的節(jié)點來提升整體的性能，其中就會涉及到數(shù)據(jù)庫的擴容和縮容。

圖片

?

?

分布式數(shù)據(jù)庫擴縮容的本質(zhì)，就是數(shù)據(jù)分片的騰挪，整個過程涉及了全量+增量的組合。PolarDB-X v2.4.1版本，針對擴縮容能力做了全新的升級，數(shù)據(jù)騰挪的全量遷移方式，從原先默認的邏輯數(shù)據(jù)遷移演進到了基于物理文件遷移。

比如：邏輯數(shù)據(jù)的全量遷移，是通過TableScan的算子讀取需要騰挪分片的所有行記錄，然后通過新的Insert算子寫入到指定的新節(jié)點分片中，這種方式的弊端比較明顯：

• 需要讀取Leader節(jié)點，保證數(shù)據(jù)遷移的一致性，雖然僅是TableScan的讀操作，也會對原節(jié)點有一定的CPU開銷

• 寫入目標節(jié)點，采用了邏輯Insert的方式，雖然可以走Batch批量處理優(yōu)化提交，但本質(zhì)上還是需要邏輯迭代執(zhí)行，CPU開銷比較大，執(zhí)行的效率不夠快

• 邏輯遷移，在分布式下的整體并行度不夠大，沒有充分發(fā)揮分布式多節(jié)點的效果，比如50個節(jié)點，一次性擴容25個節(jié)點，容易出現(xiàn)擴容耗時過長的問題

PolarDB-X v2.4.1版本，引入新的物理文件的全量遷移，可以很大程度上改善以前邏輯遷移方案的弊端：

• 數(shù)據(jù)讀取，首先可以訪問Follower節(jié)點，不對在線業(yè)務有影響，同時通過直接訪問物理文件，不做邏輯解析，直接實現(xiàn)二進制的讀取

• 寫入目標節(jié)點，同樣采用物理寫入，將數(shù)據(jù)讀取的二進制流直接寫入目標節(jié)點，實現(xiàn)類似物理文件二進制拷貝的效果，CPU僅需要處理網(wǎng)絡(luò)轉(zhuǎn)發(fā)和IO落盤的操作，并不需要處理邏輯迭代

• 更大的并行度規(guī)劃，引入了更確定的物理復制任務，可以將分布式的擴縮容拆分為多個物理復制的拷貝子任務的組合，通過MPP并行計算調(diào)度到多個節(jié)點，實現(xiàn)分布式的并行擴縮容

?

我們針對不同場景，測試了物理復制遷移的效果，比如：大blob字段、寬表、sysbench、tpcc等多種場景，均有5~10倍左右的速度提升

# 開啟物理復制遷移
set global physical_backfill_enable=true;

# 關(guān)閉物理復制遷移
set global physical_backfill_enable=false;

同時，我們設(shè)計了分布式大規(guī)模的擴縮容實驗，實例規(guī)格：35個CN（8C32G） + 70個DN（8C32G），TPCC 50萬倉（總計約45TB）

• DN縮容，70節(jié)點縮容為40節(jié)點，涉及總數(shù)據(jù)量19.53TB，總耗時80分5秒，總的遷移速度4096MB/s，平均單節(jié)點135.6MB/s

• DN擴容，40節(jié)點擴容為70節(jié)點，涉及總數(shù)據(jù)量17.51TB，總耗時68分6秒，總的遷移速度4439.4MB/s，平均單節(jié)點149.8MB/s

整個擴縮容期間，核心的CN/DN組件的資源水位線均正常，無CPU/內(nèi)存/IOPS顯著高出預期的現(xiàn)象。

數(shù)據(jù)TTL

在實際生產(chǎn)中，有些業(yè)務只希望保留最近一段時間的數(shù)據(jù)（熱數(shù)據(jù)），并對于使用頻率很低且不斷積累的過期數(shù)據(jù)（冷數(shù)據(jù)）采用存儲成本更低的方式保存，同時又可以利用這些冷數(shù)據(jù)進行分析統(tǒng)計業(yè)務。

綜上所述，業(yè)務對處理冷數(shù)據(jù)，主要有以下需求：

• 可以定時清理冷數(shù)據(jù)。

• 更低的冷數(shù)據(jù)存儲成本。

• 歸檔后仍然可以供后臺業(yè)務進行分析統(tǒng)計。

PolarDB-X v2.4.1提供了全新的數(shù)據(jù)TTL能力，支持行級、分區(qū)級的數(shù)據(jù)過期清理、歸檔等，可以結(jié)合列存索引適配oss對象存儲，可以提供更靈活的數(shù)據(jù)TTL。整個TTL的使用可以分為三部分：

• 已有的數(shù)據(jù)表，配置TTL策略，比如：指定TTL的時間列及其數(shù)據(jù)的存活時間

• 定義TTL的清理任務，比如：主動清理或者定時自動清理，及關(guān)注清理任務的狀態(tài)

• 定義數(shù)據(jù)歸檔，比如：TTL默認可以只做數(shù)據(jù)清理，但也可以額外配置被清理的數(shù)據(jù)進行轉(zhuǎn)儲歸檔

配置TTL策略，操作例子：

# 針對已有的數(shù)據(jù)表，動態(tài)配置TTL
ALTER TABLE `orders_test`
MODIFY TTL
SET
TTL_EXPR = `date_field` EXPIRE AFTER 2 MONTH TIMEZONE '+08:00';

指定 orders_test表的??date_field??列為TTL定義的時間列，只保存最近兩個月的數(shù)據(jù)（數(shù)據(jù)過期時間為2個月），定時清理任務執(zhí)行的時區(qū)為東八區(qū)。

定義TTL的清理任務，操作例子：

• 手動執(zhí)行

# 手動執(zhí)行
ALTER TABLE `orders_test` CLEANUP EXPIRED DATA;

• 定時自動執(zhí)行

# 定時執(zhí)行，指定為每天的凌晨2點運行數(shù)據(jù)清理
ALTER TABLE `orders_test` MODIFY TTL \
SET TTL_JOB = CRON '0 0 2 */1 * ? *' TIMEZONE '+08:00';

定義數(shù)據(jù)歸檔，操作例子：

# 創(chuàng)建數(shù)據(jù)歸檔的數(shù)據(jù)空間
CREATE TABLE `orders_test_archive`
LIKE `orders_test`
ENGINE = 'Columnar' ARCHIVE_MODE = 'TTL';

注意：

• ENGINE的值必須為'Columnar'，不允許其他值，代表使用列存引擎

• 如果對原主庫執(zhí)行了DDL變更，比如加列，數(shù)據(jù)歸檔表也會自動執(zhí)行加列，可以確保后續(xù)的歸檔任務不中斷

更多使用和原理，請參考文檔：

• TTL原理概述（??https://help.aliyun.com/zh/polardb/polardb-for-xscale/principle-overview）??
• 
  
• TTL表的定義與創(chuàng)建（??https://help.aliyun.com/zh/polardb/polardb-for-xscale/definition-and-creation-of-ttl-table）??

• TTL表的過期數(shù)據(jù)清理（??https://help.aliyun.com/zh/polardb/polardb-for-xscale/ttl-table-expired-data-cleansing）??

• 歸檔表語法說明（??https://help.aliyun.com/zh/polardb/polardb-for-xscale/archive-table-syntax-description）??

PolarDB-X架構(gòu)簡介

PolarDB-X 采用 Shared-nothing 與存儲分離計算架構(gòu)進行設(shè)計，系統(tǒng)由5個核心組件組成，提供金融級高可用、透明分布式、HTAP一體化、集中式和分布式一體化體驗和功能特性。

圖片

● 計算節(jié)點（CN, Compute Node）

計算節(jié)點是系統(tǒng)的入口，采用無狀態(tài)設(shè)計，包括 SQL 解析器、優(yōu)化器、執(zhí)行器等模塊。負責數(shù)據(jù)分布式路由、計算及動態(tài)調(diào)度，負責分布式事務 2PC 協(xié)調(diào)、全局二級索引維護等，同時提供 SQL 限流、三權(quán)分立等企業(yè)級特性。

● 存儲節(jié)點（DN, Data Node）

存儲節(jié)點負責數(shù)據(jù)的持久化，基于多數(shù)派 Paxos 協(xié)議提供數(shù)據(jù)高可靠、強一致保障，同時通過 MVCC 維護分布式事務可見性。

● 元數(shù)據(jù)服務（GMS, Global Meta Service）

元數(shù)據(jù)服務負責維護全局強一致的 Table/Schema, Statistics 等系統(tǒng) Meta 信息，維護賬號、權(quán)限等安全信息，同時提供全局授時服務（即 TSO）。

● 日志節(jié)點（CDC, Change Data Capture）

日志節(jié)點提供完全兼容 MySQL Binlog 格式和協(xié)議的增量訂閱能力，提供兼容 MySQL Replication 協(xié)議的主從復制能力。

● 列存節(jié)點 (Columnar)

列存節(jié)點提供持久化列存索引，實時消費分布式事務的binlog日志，基于對象存儲介質(zhì)構(gòu)建列存索引，能滿足實時更新的需求、以及結(jié)合計算節(jié)點可提供列存的快照一致性查詢能力

開源生態(tài)

PolarDB-X支持多種形態(tài)的快速部署能力，可以結(jié)合各自需求進行選擇。（項目地址：??https://github.com/polardb/polardbx-sql）??

PolarDB-X Operator是基于K8S Operator架構(gòu)，正式發(fā)布1.7.0版本，提供了PolarDB-X 數(shù)據(jù)庫的部署和運維能力，生產(chǎn)環(huán)境優(yōu)先推薦，可參考 PolarDB-X Operator運維指南（???https://doc.polardbx.com/zh/operator/）。??

PolarDB-X Operator 1.7.0新版本，重點適配了多云的部署能力，比如支持阿里云PolarDB-X商業(yè)備份集恢復、備份適配aws S3協(xié)議，融合了商業(yè)、開源與多云之間的關(guān)系，詳見：ChangeLog??https://github.com/polardb/polardbxoperator/releases/tag/v1.7.0）。??

總結(jié)

PolarDB-X v2.4.1版本，重點增強企業(yè)級運維能力，面向DBA的數(shù)據(jù)庫運維和數(shù)據(jù)管理，提供了更多有價值的能力，可以查看更多詳細的 Changelog（??https://github.com/polardb/polardbx-operator/releases/tag/v1.7.0）。??

另外2024-09-30，中國信息安全測評中心發(fā)布安全可靠測評結(jié)果公告（2024年第2號），PolarDB-X【阿里云PolarDB數(shù)據(jù)庫管理軟件（分布式版）V2.0（簡稱：PolarDB 分布式版）】，首批通過分布式的安全可靠測

（??http://www.itsec.gov.cn/aqkkcp/cpgg/202409/t20240930_194299.html）。??

PolarDB-X 采用 Shared-nothing 與存儲分離計算架構(gòu)，支持集中式和分布式一體化形態(tài)，提供：標準版（集中式）和企業(yè)版（分布式），同時具備金融級數(shù)據(jù)高可用、分布式水平擴展、混合負載、低成本存儲和極致彈性等能力，堅定以兼容MySQL開源生態(tài)構(gòu)建分布式能力，為用戶提供高吞吐、大存儲、低延時、易擴展和超高可用的云時代數(shù)據(jù)庫服務。

參考資料：
PolarDB分布式V2.0 ：???安全可靠的國產(chǎn)自研分布式數(shù)據(jù)庫PolarDB??