PolarDB MySQL版重磅推出了列存索引（IMCI）特性。
簡介
當前主要面向OLTP場景，廣泛應用于在線業務，日常產生大量的數據。但是，基于行存的查詢性能并不能滿足所有應用場景的需求。通常情況下，為了實現復雜分析型查詢，需要將數據從PolarDB MySQL版導出，然后導入到外部專用的OLAP系統中再進行分析查詢。這樣一來，需要使用兩套數據庫系統，架構復雜性、運維工作量和成本都會大大增加。
PolarDB MySQL版重磅推出的列存索引（In-Memory Column Index，簡稱IMCI）面向OLAP場景大數據量復雜查詢。通過列存索引，PolarDB MySQL版實現了一體化的實時事務處理和實時數據分析的能力，成為一站式HTAP數據庫產品解決方案。通過一套數據庫系統，即可滿足業務的OLTP及OLAP需求。
版本要求
企業版集群，集群版本需滿足以下條件之一：
PolarDB MySQL版8.0.1版本，且修訂版本為8.0.1.1.22及以上。
PolarDB MySQL版8.0.2版本，且修訂版本為8.0.2.2.12及以上。
標準版集群，CPU架構需為X86，集群版本需滿足以下條件之一：
PolarDB MySQL版8.0.1版本，且修訂版本為8.0.1.1.38及以上。
PolarDB MySQL版8.0.2版本，且修訂版本為8.0.2.2.19及以上。
實現形態
為了實現OLAP和OLTP的計算資源隔離，當前僅支持在只讀節點上實現列存索引，即OLAP查詢請求只發給只讀節點，而不會發給主節點。至于OLAP查詢請求是發給只讀行存節點，還是只讀列存節點，可根據行存/列存分流方案進行配置。
技術原理
列存索引特性在PolarDB MySQL版中的功能架構圖如下：
從以上架構圖可以看到，PolarDB MySQL版從存儲引擎、執行算子、優化器三個層面設計了列存索引的特性：
存儲引擎：支持實時事務級別一致性的行列混合存儲；
執行算子：面向列存的向量化并行執行算子，支持極速的單表和多表查詢；
SQL Parser/優化器：面向行列混合存儲的CBO優化器，可以根據代價自動選擇行存或者列存執行查詢請求；
在此架構下，PolarDB MySQL版實現了100%兼容MySQL協議的基礎上，同時獲得數個數量級的查詢加速效果。
核心優勢
PolarDB MySQL版依托列存索引特性，具備如下優勢：
100%兼容MySQL：列存具有與MySQL一致的數據類型系統，支持靈活的類型轉換，100%兼容MySQL協議；
優秀的HTAP性能：PolarDB在OLTP方面本身具備良好性能。列存索引使其OLAP性能也與專用的OLAP數據庫系統處于同一水平；
行列混合存儲，降低成本：同時支持行存儲和列存儲兩種格式，且實時保證行列的事務級一致。列存更具有低成本的優勢。
適用場景
PolarDB MySQL版的列存索引特性提供了一站式HTAP產品體驗，可以應用于多種業務場景：
對在線數據有實時數據分析需求的場景，如實時報表；
專用數據倉庫場景：依托PolarDB提供的海量數據存儲能力，匯聚多個上游數據源，將其作為專用數據倉庫使用；
ETL數據加速計算場景：依托PolarDB基于列存索引提供的強大而靈活的計算能力，在PolarDB中使用SQL來實現ETL功能。
性能提升情況
列存索引功能對SQL查詢操作有明顯的加速作用，查詢性能甚至可以提升百倍。接下來我們以標準TPC-H測試的數據表和SQL為例，體驗列存索引對查詢的加速效果。
測試方法：TPC-H是業界常用的一套基準，由TPC委員會制定發布，用于評測數據庫的分析型查詢能力。TPC-H查詢包含8張數據表、22條復雜的SQL查詢，大多數查詢包含若干表Join、子查詢和Group by聚合等。
本文的TPC-H的實現基于TPC-H的基準測試，并不能與已發布的TPC-H基準測試結果相比較，本文中的測試并不符合TPC-H基準測試的所有要求。
數據量：100 GB。
測試結果：
開啟列存索引前后性能對比
下圖展示了開啟列存索引前后分別執行TPC-H的22條查詢語句的查詢響應時間的對比。
開啟列存索引后與ClickHouse性能對比
下圖展示了開啟列存索引后，執行TPC-H的21條查詢語句（Q21除外，ClickHouse不支持）的查詢響應時間，與相同數據量和數據結構的ClickHouse數據庫的對比。
結論：
列存索引對大多數的復雜查詢操作都有加速作用，查詢性能提升非常明顯，甚至可達到百倍。
與傳統OLAP數據庫ClickHouse相比：PolarDB MySQL版開啟列存索引后，與ClickHouse性能相比各有優劣。其中在單表Scan/AGG、Join等場景中表現突出。未來的列存索引特性將在聚合加速、窗口函數等方面持續優化和突破。