すべてのプロダクト
Search
ドキュメントセンター

PolarDB:インメモリ列指向インデックス (IMCI)

最終更新日:Dec 17, 2025

このトピックでは、PolarDB for PostgreSQL のインメモリ列指向インデックス (IMCI) 機能について説明します。この機能は、複雑なクエリを高速化するために設計されています。

概要

PolarDB for PostgreSQL のインメモリ列指向インデックス (IMCI) 機能を使用すると、単一のシステムで、高同時実行性のオンライン トランザクショナル プロセッシング (OLTP) と複雑なデータ分析 (OLAP) の両方を処理できます。分析クエリのために、高価でアーキテクチャが複雑な外部システムを別途維持する必要はもうありません。これにより、データアーキテクチャが簡素化され、運用保守 (O&M) コストが削減され、大量のビジネスデータのリアルタイム分析が可能になります。

行ストアエンジンと比較して、IMCI は、ストレージレイヤーの列ストアインデックスと、実行エンジンレイヤーのベクトル化オペレーター (ベクトル化実行エンジンとも呼ばれます) という 2 つの主要な領域でクエリパフォーマンスを向上させます。これらの改善により、複雑なクエリを処理する際の行ストアエンジンの制限が克服されます。たとえば、32 コア、256 GB のクラスターで 100 GB のデータセットを使用する TPC-H パフォーマンステストでは、PolarDB for PostgreSQL の列ストアエンジンは、行ストアエンジンよりも 60 倍以上高いクエリパフォーマンスを実現します。詳細については、「IMCI パフォーマンステストの結果」をご参照ください。

仕組み

アーキテクチャの最適化

PolarDB for PostgreSQL の IMCI 機能は、実行エンジンとストレージレイヤーの両方を最適化して、複雑なクエリの処理を改善します。

  • 実行エンジンレイヤー

    • 行ストアエンジンとは異なり、ベクトル化実行エンジンは CPU SIMD 命令を使用してデータをバッチで処理します。単一の CPU 命令で複数のデータエントリを並列処理できます。これにより、関数呼び出しのオーバーヘッドとキャッシュミスが削減されます。

    • このエンジンは、完全にベクトル化されたオペレーターを実装しています。たとえば、ScanGroup ByOrder ByHash JoinFilterCountSum などのオペレーターをベクトル化します。これにより、エンジンはバッチデータ入力を受け入れ、SIMD 命令を使用してそれらを処理できます。

  • ストレージレイヤー

    • ヒープ行ストア構造よりもベクトル化オペレーターに適した列ストアフォーマットを使用します。

    • 列ストアフォーマットはインデックスとして実装されており、これがインメモリ列指向インデックス (IMCI) です。IMCI は B-tree インデックスや GiST インデックスに似ていますが、ストレージ構造と適用シナリオが異なります。ベクトル化実行エンジンは IMCI を直接使用できますが、行ストアエンジンは B-tree インデックスと GiST インデックスを使用します。テーブルには、さまざまなクエリを処理するために、IMCI と他の種類のインデックスの両方を含めることができます。PolarDB for PostgreSQL のクエリオプティマイザーは、クエリプランのコストに基づいて適切なインデックスを選択します。

次の図に示すように、テーブル t の列 c2 にポイントクエリ (SELECT * FROM t WHERE c2=10) 用の B-tree インデックスを作成し、列 c4 と c5 に統計クエリ (SELECT c4,  SUM(c5) FROM t GROUP BY c4) 用の IMCI を作成できます。クエリオプティマイザーは、SQL 文のコストに基づいて、使用する最も効率的なインデックスを決定します。

image

リアルタイムな行列表データ同期

IMCI のデータは、データベース内に列指向フォーマットで格納されます。データはまず行指向テーブルに書き込まれ、次にインデックス作成メカニズムを介して IMCI と同期されます。このプロセスは行列表データ同期と呼ばれます。PolarDB for PostgreSQL の IMCI 機能は、効率的でリアルタイム、かつ自動化された行列表同期メカニズムを提供します。このプロセスのために追加のパイプラインを構築したり、列ストアデータを手動でリフレッシュしたりする必要はありません。

行列表同期メカニズムは、先行書き込みログ (WAL) を解析して変更されたデータを取得し、それを非同期で IMCI に書き込みます。このプロセスが行ストアのパフォーマンスと負荷に与える影響は最小限で、通常は 3% 未満です。PolarDB for PostgreSQL の IMCI は同じノード上の行ストアエンジンと共存できるため、WAL ログの解析プロセスは高度に最適化されています。行から列への変換プロセスは非同期ですが、書き込み負荷に応じて、数ミリ秒から数秒のレイテンシーでほぼリアルタイムの同期を実現します。行列表同期パフォーマンスの最適化の詳細については、「IMCI のリアルタイムパフォーマンスの向上」をご参照ください。

製品形態

PolarDB for PostgreSQL の IMCI 機能はすべてのノードにデプロイされます。したがって、クラスター内のすべてのコンピューティングノードには、行ストアエンジンと IMCI の両方が備わっています。このモードでは、SQL 文が実行されるときに 2 つの決定が下されます。

  1. 文を実行するコンピューティングノードの選択。

  2. そのノード内の実行エンジンの選択。

コンピューティングノードの選択

PolarDB クラスターに複数のノードがある場合、システムは IMCI に関連する SQL 文をどのコンピューティングノードで実行するかを決定する必要があります。

  • DDL 文や DML 文などのすべてのデータ変更文は、RW ノードで実行されます。その後、RW ノードは特定の条件に基づいて適切な実行エンジンを選択します。

  • IMCI の作成とリアルタイムデータ同期は、RW ノードで実行されます。

  • すべての読み取り専用 SQL 文については、データベースプロキシを設定して、実行に使用するノードを決定できます。

実行エンジンの選択

コンピューティングノードでは、文を実行するために実行エンジンが選択されます。

  • DDL 文 (CREATE TABLEALTER TABLE など) の場合、通常は行ストアエンジンが使用されます。ただし、CREATE TABLE AS SELECT 文の場合、システムは SELECT サブクエリの複雑さに応じて IMCI を使用するかどうかを決定します。

  • DML 文 (INSERTUPDATEDELETE など) の場合、行ストアエンジンが使用されます。

  • DQL 文 (SELECT 文など) の場合、システムはクエリコストとパラメーターに基づいて IMCI を使用するかどうかを決定します。一般に、SELECT 文のクエリコストが高いほど、IMCI が使用される可能性が高くなります。IMCI が SELECT 文の実行に失敗した場合、システムはフォールバックして行ストアエンジンで実行します。

image

主な特徴

  • 高性能

    行ストアエンジンと比較して、IMCI は SQL クエリのパフォーマンスを桁違いに向上させます。複雑なクエリの場合、100 倍以上のパフォーマンス向上を実現します。

  • コスト効率

    • クエリに関係する列に対してのみ IMCI を作成できます。テーブル全体を列ストアに変換する必要はありません。

    • IMCI は使用するストレージ容量が少なくなります。同じ列の場合、IMCI が使用するストレージ容量は、データ型に応じて、行ストアが使用するストレージ容量の 10% から 50% にすぎません。

  • 使いやすさ

    使用方法はネイティブの PostgreSQL と同じです。

    • IMCI はネイティブの PostgreSQL のインデックス管理方法を継承し、CREATE INDEXDROP INDEX などの構文をサポートします。追加の構文は必要ありません。詳細については、「IMCI の有効化と使用」をご参照ください。

    • IMCI は PostgreSQL のデータ型と構文との互換性が高く、IMCI を使用するために既存の SQL 文を変更する必要はありません。

    • パラメーター設定を使用して、どの SQL 文が IMCI を使用するかを詳細に制御できます。これには、グローバルな使用、セッションレベルでの使用、ヒントを使用した特定の SQL 文に対する IMCI の使用の指定が含まれます。詳細については、「IMCI の有効化と使用」をご参照ください。

  • リアルタイムな IMCI のメンテナンス

    • 行ストアデータと IMCI の間の整合性は自動的に維持されます。追加のデータ変換パイプラインを構築したり、手動でリフレッシュや同期操作を実行したりする必要はありません。

    • 行ストアに挿入された新しいデータは、ミリ秒または秒単位で IMCI に同期されます。さまざまなビジネス負荷に応じて同期パフォーマンスを調整できます。詳細については、「IMCI の有効化と使用」をご参照ください。

  • 整合性

    列ストアデータと行ストアデータには、さまざまなビジネスニーズを満たすために 2 つの整合性レベルが提供されています。

    • 結果整合性 (デフォルト):書き込み負荷は高いが、データのリアルタイム性に対する要件がそれほど厳しくないクエリに適しています。

    • 強整合性:列ストアデータが行ストアデータと完全に整合性が取れた後にのみクエリ結果を返します。詳細については、「IMCI の有効化と使用」をご参照ください。

  • さまざまな使用方法との互換性

    • Prepared Statement 構文をサポートします。

    • トランザクションブロック内の SELECT 文の高速化をサポートします。

      説明

      SELECT 文は、トランザクションブロック内の「書き込み前読み取り」SQL 文である必要があります。

    • パーティションテーブルと pg_pathman で管理されるパーティションテーブルをサポートします。パーティションプルーニングもサポートされています。詳細については、「パーティションテーブルでの IMCI の使用」をご参照ください。

    • 時空間マルチモーダルクエリの高速化をサポートします。

利用シーン

PolarDB for PostgreSQL の IMCI 機能は、ワンストップのハイブリッドトランザクション/分析処理 (HTAP) エクスペリエンスを提供し、さまざまなビジネスシナリオで使用できます。

  • HTAP シナリオ:たとえば、毎日トランザクションデータに対して多くの CRUD 操作を実行し、過去 1 時間のリアルタイム統計レポートを生成する必要がある場合などです。PolarDB for PostgreSQL の IMCI は、これら 2 種類の負荷を効率的に処理するだけでなく、システムアーキテクチャも簡素化します。リアルタイム統計 OLAP クエリのために追加のシステムを維持する必要はありません。

  • さまざまな種類の低速 SQL 文:これには、高同時実行トランザクションシナリオにおける次のような文が含まれます。

    • COUNTSUMAVERAGE などのテーブル全体の集約操作。

    • 列に対する GROUP BY および ORDER BY 操作。

    • 複数のテーブルに対する JOIN 操作。

    • 予測不可能な順序で多くの列をフィルタリングするクエリ。この場合、複合インデックスは柔軟性に欠け、簡単に効果がなくなってしまう可能性があります。IMCI を使用する方が良い選択です。

  • マルチモーダルおよび時空間クエリ: ネストされた JSON から KEYVALUE を抽出するか、地理的グリッドに基づいて時空間ヒートマップを生成します。

  • ETL データ高速化シナリオPolarDB の SQL を使用して ETL 機能を実装し、PolarDB が IMCI に基づいて提供する強力で柔軟なコンピューティング機能を活用できます。

課金

IMCI は、行ストアノードで直接実行することも、追加された IMCI 読み取り専用ノードで実行することもできます。

  • 行ストアノードでの IMCI の使用:無料です。

  • IMCI 読み取り専用ノードの追加:このオプションではノード料金が発生します。IMCI 読み取り専用ノードは、標準コンピューティングノードとして課金されます。さらに、IMCI はストレージ容量を占有するため、対応するストレージ容量料金が発生します。

説明

行ストアノードで直接 IMCI 機能を使用すると、ビジネスに影響を与える可能性があります。IMCI 読み取り専用ノードを追加すると、トランザクション処理 (TP) と分析処理 (AP) のワークロードを異なるノードに分離できます。これにより、互いに影響を与えないようにすることができます。詳細については、「ビジネスへの影響」をご参照ください。