全部產品
Search
文件中心

PolarDB:分布式列存索引

更新時間:Apr 21, 2026

PolarDB PostgreSQL分布式版的列存索引(IMCI)功能內建DuckDB分析引擎,可將分析查詢效能提升60倍以上。結合分布式架構的透明分區機制,查詢可下推至多個資料節點(DN)平行處理,分析效能隨節點數線性擴充。在TB/PB級巨量資料量情境下,分布式+IMCI的組合相較於行存,整體分析效能可實現近100倍的提升,滿足HTAP(混合事務與分析處理)情境需求。

架構

分布式+IMCI的架構包含以下核心角色:

  • CN(協調節點):負責處理請求、產生分布式執行計畫、下推查詢SQL到各個資料節點,並最終匯聚各DN的結果返回給用戶端。

  • DN(資料節點):負責儲存行存(Row-Store)和列存(IMCI)資料。行存資料通過邏輯複製機制非同步寫入到列存,確保分析加速與即時資料寫入相容。

以一個典型的分析型彙總查詢為例,整體流程如下:

  1. CN節點產生分布式計劃並下發SQL:業務SQL請求發送到CN節點,CN根據全域中繼資料產生分布式執行計畫,決定如何將查詢SQL拆分下發到各個資料節點。

  2. DN節點基於IMCI列存資料並行查詢:CN將查詢下推到各目標DN節點,DN基於本地的IMCI列存資料進行高效並行查詢和初步彙總,完成後返回中間結果給CN。

  3. CN節點進行二次彙總,返回最終結果:CN收集所有DN的查詢結果,並按需進行最終彙總、排序,最後將匯總結果返回給使用者或應用程式。

適用情境

該功能適用於多租戶資料庫情境,尤其是在需要對租戶資料進行高效匯總和全域彙總時,能夠顯著提升分析效能。具體適用兩種拆分情境:

水平分割(Sharding by tenant_id)

假設存在業務表orders,並以tenant_id作為分區鍵。

  • 單租戶資訊彙總:統計某一租戶的本地訂單總金額與平均金額。

    SELECT SUM(amount) AS total_amount, AVG(amount) AS avg_amount
    FROM orders
    WHERE tenant_id = 1001;
  • 全域租戶資訊統計:統計所有租戶的訂單總金額與平均金額,按租戶分組。

    SELECT tenant_id, SUM(amount) AS total_amount, AVG(amount) AS avg_amount
    FROM orders
    GROUP BY tenant_id;

垂直分割(Sharding by schema)

假設每個租戶的資料分布在單獨的Schema中,表名同為orders

  • 單個Schema資訊彙總:針對某個Schema的訂單總金額與平均金額彙總。

    SELECT SUM(amount) AS total_amount, AVG(amount) AS avg_amount
    FROM tenant_a.orders;
  • 全域租戶資訊統計:匯總所有租戶的訂單總金額與平均金額,通過UNION ALL實現。

    SELECT 'tenant_a' AS tenant, SUM(amount) AS total_amount, AVG(amount) AS avg_amount FROM tenant_a.orders
    UNION ALL
    SELECT 'tenant_b' AS tenant, SUM(amount) AS total_amount, AVG(amount) AS avg_amount FROM tenant_b.orders;

適用範圍

配置分布式列存索引

步驟一:開啟分布式IMCI功能

您可以在PolarDB控制台或在資料庫會話中進行修改:

參數

說明

polar_cluster_enable_imci

是否開啟分布式列存索引。

  • on:開啟

  • off(預設):關閉

polar_csi.enable_anyall_to_in

是否允許WHERE條件中的IN運算式執行分布式列存索引。

  • on:開啟

  • off(預設):關閉

pg_hint_plan.polar_enable_distributed_hint

是否開啟分布式hint功能。

  • on:開啟

  • off(預設):關閉

SET polar_cluster_enable_imci = on;
SET polar_csi.enable_anyall_to_in = on;
SET pg_hint_plan.polar_enable_distributed_hint = on;

步驟二:建立行列同步複製槽

用高許可權賬戶在主CN上執行以下命令,為所有節點建立行列同步複製槽:

SELECT run_command_on_all_nodes($$ SELECT polar_csi_start_sync() $$);
說明

此操作為等冪操作,可多次執行無副作用。

步驟三:建立並分區租戶表

水平分割

tenant_id作為分區鍵,建立分布式表:

說明

如果以tenant_id作為分區鍵,必須為主鍵或者主鍵的一部分

-- 建立初始業務表(以 tenant_id 作為主鍵一部分)
CREATE TABLE orders (
  order_id   bigint,
  tenant_id  int NOT NULL,
  amount     numeric(20,2),
  status     text,
  create_time timestamp,
  PRIMARY KEY (tenant_id, order_id)
);

-- 轉為分布式分區表
SELECT create_distributed_table('orders', 'tenant_id');

垂直分割

每個租戶的資料存放區在獨立的Schema中:

-- 建立租戶 schema
CREATE SCHEMA tenant1;

-- 轉為分布式管理
SELECT polar_cluster_schema_distribute('tenant1');

-- 建立業務表
SET search_path TO tenant1;

CREATE TABLE orders (
  order_id   bigint,
  tenant_id  int NOT NULL,
  amount     numeric(20,2),
  status     text,
  create_time timestamp,
  PRIMARY KEY (tenant_id, order_id)
);

步驟四:建立列存索引

為表建立CSI列存索引:

-- 對所有列建立列存索引
CREATE INDEX csi_orders ON orders USING CSI;

-- 僅對部分列建立列存索引(如僅查詢 tenant_id, amount)
CREATE INDEX csi_orders_part ON orders1 USING CSI(tenant_id, order_id, amount);

-- 支援不鎖表建立列存索引(推薦)
CREATE INDEX CONCURRENTLY csi_orders ON orders USING CSI;
說明

推薦為所有列建立CSI索引,避免因列缺失造成列存查詢失效。

步驟五:使用列存索引執行查詢

有兩個參數控制是否執行列存查詢:

參數

說明

polar_csi.enable_query

是否允許查詢語句使用列存索引。

  • on:開啟

  • off(預設):關閉

polar_csi.cost_threshold

查詢代價閾值。如果查詢代價小於當前設定閾值,使用行存引擎,反之使用列存引擎。

  • 取值範圍:0-1000000000

  • 預設值:50000

推薦通過HINT控制某次查詢強制使用列存索引:

/*+SET (polar_csi.enable_query on) SET(polar_csi.cost_threshold 0)*/
SELECT tenant_id, SUM(amount) AS total_amount, AVG(amount) AS avg_amount
FROM orders
GROUP BY tenant_id;

也可以全域或按帳號設定參數。全域設定參數需要在控制台修改,按帳號設定參數需要在主CN上執行以下語句:

-- 以 test 使用者優先啟用列存索引
ALTER ROLE test SET polar_csi.enable_query = ON;
ALTER ROLE test SET polar_csi.cost_threshold = 0;

步驟六:確認查詢是否使用列存索引

可用EXPLAIN分析,若計劃中出現CSI Executor字樣說明已成功使用列存索引:

/*+SET (polar_csi.enable_query on) SET(polar_csi.cost_threshold 0)*/
EXPLAIN (COSTS OFF) SELECT tenant_id, SUM(amount) AS total_amount, AVG(amount) AS avg_amount
FROM orders
GROUP BY tenant_id;

樣本輸出片段(含有CSI Executor說明使用了列存查詢):

                       QUERY PLAN
---------------------------------------------------------
 Custom Scan (PolarCluster Adaptive)
   Task Count: 32
   Tasks Shown: One of 32
   ->  Task
         Node: host=127.0.0.1 port=45719 dbname=postgres
         ->  CSI Executor:
             ┌───────────────────────────┐
             │       HASH_GROUP_BY       │
             │    ────────────────────   │
             │        Aggregates:        │
             │          sum(#1)          │
             │          avg(#2)          │
             └─────────────┬─────────────┘
             ┌─────────────┴─────────────┐
             │         SEQ_SCAN          │
             │    ────────────────────   │
             │    Table: orders_102008   │
             │   Type: Sequential Scan   │
             └───────────────────────────┘

效能表現

以下測試展示分布式+IMCI組合在不同資料處理情境下的橫向擴充能力和效能表現。測試環境中每個DN規格為16核64 GB。

  • Sysbench OLTP(聯機交易處理)測試:主要用於評估資料庫在高並發插入、更新和刪除等事務型操作下的效能。通過增加資料節點(DN)的數量,系統的寫入能力實現接近線性擴充,以滿足不斷增長的業務流量需求。

  • TPC-H OLAP(線上分析處理)測試:重點關注大規模資料彙總和複雜查詢分析的效能表現。IMCI顯著提升了單節點的分析能力,而分布式架構則進一步將查詢下推至多個DN節點進行平行處理,從而使總體查詢效能隨節點數量線性提升,適用于海量資料的分析與洞察。

TPC-H效能測試

使用1 TB TPC-H資料集,分別測試1、2、4、8、12個DN下的查詢時延。

image

測試結果表明:

  • 分布式列存的查詢時延相較於分布式行存可以提升100倍以上,並且可以做到線性擴充。

  • 相較於單節點列存查詢,分布式+IMCI也可隨DN節點數做到線性倍數提升,12 DN相較於單節點能提升數10倍

Sysbench OLTP_INSERT測試

分別在1、2、4、8、12個DN的配置下,測量分布式叢集的寫入QPS。image

測試結果表明:

  • 寫入QPS隨DN數量線性擴充:隨著DN節點從1增加到12,寫入QPS實現近乎線性增長,12個DN下最高QPS可達160萬。

  • 分布式架構橫向擴充行列同步能力:多DN並行架構不僅提升寫入效能,同時也顯著增強邏輯複製回放能力,使行存到列存(IMCI)的資料同步時延接近即時。