什麼是列存索引？ - PolarDB

本文介紹了PolarDB PostgreSQL版的列存索引特性，可以讓您更好地適應複雜查詢的需求。

簡介

PolarDB PostgreSQL版的列存索引（In-Memory Column Index，簡稱IMCI）功能，讓您可以在一套系統中同時處理高並發的線上交易（OLTP）和複雜的資料分析（OLAP）。您不再需要為了分析查詢，而維護一個獨立、昂貴且架構複雜的外部系統。這極大地簡化了您的資料架構，在降低營運成本的同時，實現對海量業務資料的即時分析。

相對於行存引擎，主要在兩個層面進行最佳化：儲存層面的列存索引和執行引擎層面的向量化運算元（即：向量化執行引擎），從而彌補行存引擎在複雜查詢情境的不足。以TPC-H 100GB為例，在32核256 GB叢集規格中，PolarDB PostgreSQL版的列存引擎比行存引擎效能提升60倍以上，詳細介紹請參見列存索引效能測試結果。

技術原理

架構最佳化

PolarDB PostgreSQL版列存索引在執行引擎和儲存層面進行了最佳化，以更好地適應複雜查詢的需求。

執行引擎層面
- 不同於行存引擎，向量化執行引擎利用CPU的SIMD指令批量化處理資料，即一條CPU指令可平行處理多條資料，從而減少函數調用耗時以及Cache Miss問題。
- 實現完整的向量化運算元。如Scan、Group By、Order By、Hash Join、Filter、Count、Sum等運算元的向量化，使其能夠接收批量化的資料輸入並利用SIMD指令進行處理。
儲存層面
- 採用更適合向量化運算元的列存格式，而非Heap行存結構。
- 列存格式目前以索引的形式存在，即列存索引。列存索引與B-tree索引、GiST索引具有相似性，僅在儲存結構和適用情境上存在差異。列存索引可被直接使用，而B-tree、GiST等索引則被行存引擎使用。一個表中可以同時存在列存索引和其他類型的索引來應對不同的查詢，PolarDB PostgreSQL版最佳化器會根據查詢計劃的代價來選擇不同的索引。

如下圖所示，您可以為表t的c2列建立B-tree索引來應對點查（SELECT * FROM t WHERE c2=10），為c4和c5列建立列存索引來應對統計類查詢（SELECT c4, SUM(c5) FROM t GROUP BY c4），查詢最佳化工具會根據查詢SQL的查詢代價選擇合適的索引。

行列資料即時同步

列存索引中的資料是以列式儲存在資料庫中的。資料會先寫入到行存表中，然後通過索引機制更新至列存索引，此過程被稱為行列資料的同步。PolarDB PostgreSQL版的列存索引提供高效、即時且自動化的行列資料同步機制，在使用時無需為此過程搭建額外鏈路，也無需手動重新整理列存資料。

行列資料同步機制的基本原理是通過解析WAL日誌來獲得變化的資料，進而將其非同步寫入到列存索引。該過程對行存資料的負載和效能幾乎沒有影響，對行存效能的影響保持在3%以下。由於PolarDB PostgreSQL版列存索引與行存引擎可以部署在同一個節點中，因此在解析WAL的過程中進行了大量最佳化。儘管行列轉換的過程為非同步，但依舊可以實現毫秒級至秒級的即時同步（取決於寫入負載）。行列資料即時同步效能調優請參見提升列存索引的即時性。

產品形態

PolarDB PostgreSQL版的列存索引將在所有節點上部署，因此叢集中的所有計算節點均同時具備行存引擎和列存索引。在這種模式下，一條SQL語句在執行時會面臨兩個選擇：

該語句將被分配到哪個節點執行，即選擇計算節點。
該語句由節點內的哪個引擎執行，即選擇執行引擎。

選擇計算節點

當PolarDB叢集存在多個節點，與列存索引相關的SQL語句將面臨由哪個計算節點執行的問題。

所有涉及資料更改的語句均由RW節點執行，如DDL和DML語句。在RW節點內部將進一步根據具體條件選擇執行引擎。
建立列存索引、列存索引即時同步都在RW節點執行。
所有隻讀SQL語句，可通過設定資料庫代理來決定使用哪個節點來執行。

選擇執行引擎

在計算節點內部，執行語句需要選擇使用的執行引擎。

對於DDL類型語句，如CREATE TABLE、ALTER TABLE等，一般使用行存引擎。但CREATE TABLE AS SELECT語句會根據SELECT子語句的複雜度來選擇是否使用列存索引。
對於DML類型語句，如INSERT、UPDATE、DELETE等，使用行存引擎。
對於DQL類型語句，如SELECT語句，將根據查詢代價和參數來決定是否使用列存索引。一般來說SELECT語句的查詢代價越大，使用列存索引的機率越大。如果列存索引執行SELECT語句失敗，將會使用行存引擎重新執行。

功能優勢

高效能
相比於行存引擎，列存索引能夠將SQL查詢效能普遍提升一個數量級，針對複雜查詢提供百倍以上的效能提升。
低成本
- 只需為查詢涉及列建立列存索引，無需將整個錶轉換為列存。
- 列存索引的儲存空間佔用較小。對於同一列，列存索引的空間佔用僅為行存的10%~50%（具體取決於資料類型）。
使用方式簡單
使用流程與原生PostgreSQL一致。
- 列存索引繼承原生PostgreSQL索引管理方式，支援CREATE INDEX、DROP INDEX等文法，無額外的使用文法，詳情請參見開啟和使用列存索引。
- 高度相容PostgreSQL資料類型和文法，無需修改現有SQL語句即可使用列存索引。
- 支援通過參數配置，精細化控制哪些SQL使用列存索引，包括全域使用列存索引、會話級使用列存索引，以及通過Hint等方式指定SQL使用列存索引，詳情請參見開啟和使用列存索引。
即時維護列存索引
- 自動維護行存資料與列存索引之間的一致性，無需額外構建行列資料轉換鏈路，無需手動重新整理同步列存索引等操作。
- 行存中新插入的資料可在毫秒/秒級同步到列存索引中，可根據不同的業務負載調整同步效能，詳情請參見開啟和使用列存索引。
一致性
為列存資料和行存資料提供兩種一致性層級，以滿足不同業務需求。
- 最終一致性（預設）：適用於寫入負載高，但對資料即時性要求低的查詢。
- 強一致性：在列存資料與行存資料完全一致後再返回查詢結果，詳情請參見開啟和使用列存索引。
相容多種使用方式
- 支援Prepared Statement文法。
- 支援事務塊中的SELECT語句加速。
  說明
  該SELECT語句必須為事務塊內的“寫前讀”SQL。
- 支援分區表和pg_pathman管理的分區表，並支援分區裁剪能力，詳情請參見分區表使用列存索引。
- 支援時空多模態查詢加速。

適用情境

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

HTAP情境：例如每天需要對大量的交易資料進行增刪改查，同時也需要即時統計出過去一小時的交易報表。PolarDB PostgreSQL版列存索引不僅能夠高效應對這兩類負載，還可以簡化系統架構，無需為即時統計部分OLAP查詢維護額外的系統。
各類慢SQL：在高並發事務情境中出現的慢SQL，如：
- 全表統計，如COUNT、SUM、AVERAGE等操作。
- 對列進行 GROUP BY和ORDER BY等操作。
- 對多個表做JOIN操作。
- 查詢時過濾的列較多且順序不定，複合索引不靈活且容易失效，使用列存索引更優。
多模類型與時空查詢：在嵌套JSON中提取KEY和VALUE、基於地理網格統計時空熱力圖等。
ETL資料加速計算情境：依託PolarDB基於列存索引提供的強大而靈活的計算能力，在PolarDB中使用SQL來實現ETL功能。

費用說明

列存索引可直接在行存節點或在添加的列存索引唯讀節點上執行。

在行存節點上使用列存索引：可免費使用。
添加列存索引唯讀節點：需收取相關的節點費用，列存索引唯讀節點按照普通計算節點收計費。同時，列存索引將佔用一定的儲存空間，因此也會產生相應的儲存空間費用。

說明

在行存節點上直接使用列存索引的能力可能會有業務影響。添加列存索引唯讀節點後，您可以實現TP（事務）與AP（分析）業務在不同節點上的相互隔離，確保彼此之間互不影響。