PolarDB-X HTAP新特性 - 列存索引

簡介

隨着數據爆炸式的增長，傳統的OLTP和OLAP解決方案基於簡單的讀寫分離或ETL模型，將在線庫的數據以T+1的方式抽取到數據倉庫中進行計算，這種方案存在存儲成本高、實時性差、鏈路和維護成本高等缺陷。 爲應對數據爆炸式增長的挑戰，PolarDB分佈式版本基於對象存儲設計了一套列存索引（Clustered Columnar Index，CCI）功能，支持將行存數據實時同步到列存存儲上，並支持以下功能：

• 在線事務處理和實時數據分析的一體化能力，滿足OLTP和OLAP混合場景的需求。
• 結合PolarDB分佈式架構，列存索引支持智能路由和MPP查詢加速技術。計算層會精確識別出TP和AP的流量，並智能地將TP和AP流量分別路由到不同的存儲介質上，同時確保在AP鏈路上默認開啓MPP並行查詢技術掃描列存索引，從而提升查詢分析的能力。
• 採用Delta+Main模型，滿足秒級的實時更新，結合MVCC多版本技術，能確保在任何時刻都可以讀取到一致性的快照數據。

PolarDB分佈式版將給您提供低成本、實時性高，完全兼容MySQL的一體化透明的HTAP解決方案。

版本要求

• 僅企業版實例支持列存索引
• 實例版本需滿足 >= polarx-kernel_5.4.19-16989811_xcluster-20231019

技術架構

行列混存

核心組件

• 計算節點（Compute Node，CN），計算節點是系統的入口，採用無狀態設計，包括 SQL 解析器、優化器、執行器等模塊。負責數據分佈式路由、計算及動態調度，負責分佈式事務 2PC 協調、全局二級索引維護等，同時提供 SQL 限流、三權分立等企業級特性。
• 存儲節點 （Data Node，DN），存儲節點負責數據的持久化（面相行存數據），基於多數派 Paxos 協議提供數據高可靠、強一致保障，同時通過 MVCC 維護分佈式事務可見性，另外提供計算下推能力滿足分佈式的計算下推要求（比如Project/Filter/Join/Agg等下推計算）。
• 元數據服務（Global Meta Service，GMS），元數據服務負責維護全局強一致的 Table/Schema, Statistics 等系統 Meta 信息，維護賬號、權限等安全信息，同時提供全局授時服務（即 TSO）。
• 日誌節點（Change Data Capture，CDC），日誌節點提供完全兼容 MySQL Binlog 格式和協議的增量訂閱能力，提供兼容 MySQL Replication 協議的主從複製能力。
• 列存引擎 （Columnar），列存引擎提供持久化列存索引，實時消費分佈式事務的binlog日誌，基於對象存儲介質構建列存索引，能滿足實時更新的需求、以及結合計算節點可提供列存的快照一致性查詢能力。

列存架構

架構理念

隨着雲原生技術的不斷普及，以Snowflake爲代表的新一代雲原生數倉、以及數據庫HTAP架構不斷創新，可見在未來一段時間後行列混存HTAP會成爲一個數據庫的標配能力，需要在當前數據庫列存設計中面相未來的低成本、易用性、高性能上有更多的思考

PolarDB-X提供列存索引的形態（Clustered Columnar Index，CCI），行存表默認有主鍵索引和二級索引，列存索引是一份額外基於列式結構的二級索引（覆蓋行存所有列），一張表可以同時具備行存和列存的數據。

架構特點

1.雲原生架構（存計分離、低成本）

PolarDB-X 列存索引，採用雲原生對象存儲OSS作爲主要數據存儲（成本僅爲本地盤的1/6 ~ 1/10），同時結合列存數據本身的高壓縮性（3~5倍），可以提供非常有競爭力的低成本優勢。在構建HTAP行列混存的場景，額外的列存存儲成本，可以控制在行存的存儲成本5%~10%。

PolarDB-X 列存索引的存儲採用Delta+Main（類LSM結構）二層模型 + 標記刪除的技術，確保列存索引使用對象存儲OSS也具備高併發更新能力。同時，在列存讀取對象存儲OSS的鏈路上，採用多層數據Local Cache、以及多級統計信息機制，儘量減少不必要的遠端OSS存儲訪問。

2.分佈式 （線性擴展）

傳統分佈式數據庫，業界常見基於Paxos/Raft的多副本機制構建列存，但OLTP和OLAP各自的查詢場景會有不同的訴求，對資源的依賴程度也不同，不同副本之間強一致分區策略/擴縮容機制，使得TP和AP的線性擴容能力容易相互制約，影響性能。

PolarDB-X 列存索引，基於分佈式事務的binlog日誌實時同步，實現行轉列(M:N)的異構轉換，同時可以定義列存索引特有的分佈式分區鍵、排序鍵等，結合分佈式的並行技術，提供列存查詢的線性擴展能力。同時行存和列存存儲介質相互隔離，存儲和計算資源也更易彈性，在分佈式背景下列存查詢更易追求極致的線性擴展能力。

3.讀寫分離（serverless，按讀的使用付費）

PolarDB-X 列存索引，採用組件寫和讀分離的架構設計，分爲列存寫和列存讀。列存的寫節點（Columnar節點），屬於有狀態的節點，並不直接對外提供寫請求，通過Group Commit技術批量更列存索引數據。列存的讀節點（CN節點），繼承CN節點無狀態的設計，通過GMS節點獲取列存的元數據，直接訪問OSS對象存儲上的列存索引數據。

PolarDB-X 實例創建，系統會默認提供列存寫的組件（Columnar節點，長期運行並同步列存索引），用戶只需通過DDL語法創建列存索引後，列存索引數據就會自動構建並保持實時更新。業務可以通過主實例、或者購買新的只讀實例（CN節點），就可以正常訪問行存和列存索引，同時無狀態的CN節點特別適合serverless模式，用戶只需爲列存讀的使用付費。

4.行列混合 （易用性，一體化向量化SQL引擎）

PolarDB-X 複用CN節點自研的SQL引擎，提供了列存讀的完整能力。構建面向行列混合場景的代價優化器，根據代價智能識別路由，將OLTP類查詢轉發給行存查詢鏈路、以及將OLAP類查詢轉發列存查詢鏈路，同時支持在SQL算子級別訪問不同的行存和列存，全面落實HTAP的行列混合能力，支持一套SQL引擎的統一訪問。

PolarDB-X 全面擁抱向量化，針對列存的TableScan讀取，採用列式chunk的數據結構，後續中間的算子計算也全面繼承chunk的內存列式結構，基於全鏈路的向量化提升查詢性能。同時針對行存的TableScan也會動態轉化爲列式chunk，基於統一的數據結構實現行列混合查詢。

5.庫倉一站式（Zero-ETL）

傳統數據倉庫，會通過數據ETL方式同步數據，採用MPP/BSP等並行計算架構可以很好解決OLAP複雜查詢，但面相高併發的數據在線查詢（Serving場景）會有明顯的資源併發瓶頸，會通過數據迴流到OLTP數據庫提供在線查詢。

PolarDB-X結合ADB提供了庫倉一站式的能力，基於“Zero-ETL”的設計理念，採用共享同一份列存索引的數據，基於ADB的數據倉庫能力可以滿足多方的數據彙總和數據關聯查詢，提供傳統意義上的數倉和湖的分析。同時，針對在線數據的併發查詢可以使用PolarDB-X的HTAP行列混合架構，整個過程可以避免傳統的數據ETL。

技術原理

使用語法

PolarDB-X對MySQL DDL語法進行了擴展，增加定義CCI的語法，使用方式與在MySQL上創建索引一致，可以參考列存索引的語法文檔

• CLUSTERED COLUMNAR：關鍵字，用於指定添加的索引類型爲CCI。
• 索引名：索引表的名稱，用於在SQL語句中指定該索引。
• 排序鍵：索引的排序鍵，即數據在索引文件中按照該列有序存儲。
• 索引分區子句：索引的分區算法，與CREATE TABLE中分區子句的語法一致。

實際例子：

# 先創建表
CREATE TABLE t_order (
  `id` bigint(11) NOT NULL AUTO_INCREMENT,
  `order_id` varchar(20) DEFAULT NULL,
  `buyer_id` varchar(20) DEFAULT NULL,
  `seller_id` varchar(20) DEFAULT NULL,
  `order_snapshot` longtext DEFAULT NULL,
  `order_detail` longtext DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `l_i_order` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 partition by hash(`order_id`) partitions 16;

# 再創建列存索引
CREATE CLUSTERED COLUMNAR INDEX `cc_i_seller` ON t_order (`seller_id`) partition by hash(`order_id`) partitions 16;

• 主表："t_order" 是分區表，分區的拆分方式爲按照 "order_id" 列進行哈希。
• 列存索引："cc_i_seller" 按照 "seller_id" 列進行排序，按照 "order_id" 列進行哈希。
• 索引定義子句：CLUSTERED COLUMNAR INDEX cc_i_seller ON t_order (seller_id) partition by hash(order_id) partitions 16。

列存索引的構建

列存索引是由列存引擎節點來構造的，構建的數據最終會以CSV+ORC兩種數據格式，存儲在共享對象上。其中CSV往往存儲的是實時的增量數據，過多的增量數據會及時做compaction，轉儲成ORC格式。不管是CSV還是ORC格式，PolarDB分佈式版本對兩種存儲格式都做了增強，既繼承了原生格式的開源開放的特徵，又確保了這兩類格式可以完全表達MySQL的數據協議。

從數據同步去看，構建過程往往是由全量快照讀取+增量同步兩條並行的同步鏈路共同完成的。先建列存索引，再導數據，這個場景下只有增量數據同步，Columnar節點會同時消費Binlog數據，構建索引；先導入部分數據，再建列存索引，繼續導數據，這個場景除了有增量同步鏈路，Columnar節點會同時消費已有的全量數據，增量和全量並行消費，提速列存構建的效率。

從層次結構去看，列存引擎節點採用Delta+Main(類LSM結構)二層模型，採用了標記刪除的技術，確保了行存和列存之間實現低延時的數據同步，可以保證秒級的實時更新。數據實時寫入到MemTable，在一個group commit的週期內，會將數據存儲到一個本地csv文件，並追加到OSS上對應csv文件的尾部，這個文件稱爲delta文件。OSS對象存儲上的.csv文件不會長期存在，而是由compaction線程不定期地轉換成.orc文件。

查詢加速技術

PolarDB分佈式版本的流量是由計算節點(CN)承擔，做查詢分析。

從上圖可以看整個查詢加速鏈條分爲優化器、執行器、存儲引擎三個層面。 從優化器看，PolarDB分佈式版本提供了面向行列混合場景的代價優化器，根據代價智能識別路由，將TP類查詢轉發給行存查詢鏈路；將AP類查詢轉發列存查詢鏈路。

從執行器看，PolarDB分佈式提供的是面向行列混合場景的一體化執行器，一套執行器同時支持HTAP場景。同時算子層做了向量化改造，支持了MPP加速加速技術，在複雜查詢場景中，可以充分利用多節點資源並行計算，保證了高吞吐的複雜查詢需求。

爲了抵消存儲計算分離架構帶來的網絡延遲，執行器層也引入了本地緩存技術，將熱數據實時加載到本地磁盤，保證了低延遲的查詢需求。 從存儲引擎看，列存索引的構建保證了事務提交的原子性，確保查詢上可以查詢到事務級別一致性的數據。

產品形態

在引入了列存引擎後，PolarDB分佈式版本在原有的主實例和只讀實例產品規格之外，增加了列存只讀實例產品規格。

• 主實例：默認只能查詢行存數據，配合只讀實例，其提供的主實例集羣地址，可以提供透明強一致性的讀寫分離能力。主實例上保留了直接查詢列存數據的能力，後面也會逐步放開智能路由、以及行列混合查詢能力。
• 只讀實例：支持查詢行存只讀、以及列存索引的數據，提供了獨立的只讀連接地址，可以由應用單獨連接，由應用側自主做讀寫分離。
• 列存只讀實例：僅能查詢列存索引的數據，提供了獨立的只讀連接地址，由應用單獨連接。列存只讀實例僅包含CN計算節點，有更好的價格優勢，可以參考列存只讀實例產品定價。

適用場景

PolarDB 分佈式版的列存索引特性提供了一站式HTAP產品體驗，可以應用於多種業務場景：

對在線數據有秒級的實時數據分析需求的場景，如實時報表業務；
專用數據倉庫場景：依託PolarDB分佈式提供的海量數據存儲能力，匯聚多個上游數據源，將其作爲專用數據倉庫使用；
ETL計算場景：依託PolarDB分佈式基於列存索引提供的強大而靈活的計算能力。
PolarDB分佈式版本結合列存索引特性，其優勢不僅僅在於一套數據庫產品可以同時解決TP和AP的混合場景需求，同時基於雲原生的對象存儲和智能路由技術，給用戶提供的是透明的低成本的HTAP解決方案。

• 性能數據

測試集：TPC-H 100GB 硬件環境

• CPU：Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz

軟件

• OS版本：Linux version 5.10.134-15.al8.x86_64

涉及TPC-H的表，在線增加列存索引，整個測試操作可以參考列存索引TPC-H性能白皮書

create clustered columnar index `nation_col_index` on nation(`n_nationkey`) partition by hash(`n_nationkey`) partitions 1;

create clustered columnar index `region_col_index` on region(`r_regionkey`) partition by hash(`r_regionkey`) partitions 1;

create clustered columnar index `customer_col_index` on customer(`c_custkey`) partition by hash(`c_custkey`) partitions 24;

create clustered columnar index `part_col_index` on part(`p_size`) partition by hash(`p_partkey`) partitions 24;

create clustered columnar index `partsupp_col_index` on partsupp(`ps_partkey`) partition by hash(`ps_partkey`) partitions 24;

create clustered columnar index `supplier_col_index` on supplier(`s_suppkey`) partition by hash(`s_suppkey`) partitions 24;

create clustered columnar index `orders_col_index` on orders(`o_orderdate`,`o_orderkey`) partition by hash(`o_orderkey`) partitions 24;

create clustered columnar index `lineitem_col_index` on lineitem(`l_shipdate`,`l_orderkey`) partition by hash(`l_orderkey`) partitions 24;

基於列存索引的TPC-H運行，以下結果的時間單位爲：秒（s）

 

 

上表展示了列存索引 TPC-H 100G 的性能隨着規格等比變化的提升比例，體現了分佈式的線性擴展能力。

數據庫PolarDB-X新人入門一站式頁面，快速體驗集中分佈式一體化新特性！

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。