インメモリ列インデックス (IMCI) は、ビジネスにおける複雑で時間のかかる SQL 文を高速化するためのシンプルなソリューションを提供します。クイックスタートを参照して、クラスターの HTAP 負荷処理機能を設定してください。さらに、高度な使用方法を参照して、特定のビジネス要件に合わせて IMCI をカスタマイズしてください。
クイックスタート
1. 読み取り専用 IMCI ノードを追加する
PolarDB コンソール にログオンし、クラスタが配置されているリージョンを選択して、[クラスタ] リストで対象のクラスタを見つけます。 [アクション] 列で、[ノードの追加/削除] を選択して、読み取り専用の IMCI ノードを追加します。
クラスターの購入時に既に読み取り専用 IMCI ノードを追加している場合は、この手順をスキップしてください。
クラスターは IMCI のバージョン要件を満たしている必要があります。詳細については、「読み取り専用 IMCI ノードを追加する」をご参照ください。
2. 行ストアノードと IMCI ノード間のリクエスト分散を設定する
IMCI を使用するために、自動または手動のリクエスト分散を選択できます。
行ストアノードと IMCI ノード間の自動リクエスト分散: アプリケーションが OLAP サービスと OLTP サービスの両方にアクセスするリクエストを送信する場合、推定実行コスト (リクエストによってスキャンされる行数) に基づいて読み取りリクエストの自動分散を設定し、読み取り専用 IMCI ノードまたは読み取り専用行ストアノードのいずれかにルーティングできます。
行ストアノードと IMCI ノード間の手動リクエスト分散: 異なるアプリケーションを使用して OLAP サービスと OLTP サービスのリクエストを送信する場合は、アプリケーションごとに異なるクラスターエンドポイントを設定し、行ストアノードと IMCI ノードを異なるクラスターエンドポイントに関連付けてリクエストを分散できます。
行ストアノードと IMCI ノード間の自動リクエスト分散
クラスタ詳細ページに移動し、[データベース接続] セクションで、[クラスターエンドポイント] のトランザクション/分析処理分割を [オン] に設定します。
この機能をオンにした後、新しい接続で有効になります。機能を有効にした後、クラスターに再接続してください。
DMS はデフォルトで [プライマリエンドポイント] を使用します。DMS を使用してクラスターに接続する場合は、接続方法をクラスターエンドポイントの使用に変更する必要があります。
自動リクエスト分散の推定実行コスト (スキャンされる行数) のデフォルト値は 50,000 です。実際のビジネス要件に基づいて、このパラメーターを調整できます。
行ストアノードと IMCI ノード間の手動リクエスト分散
クラスター詳細ページに移動し、[データベース接続] セクションで、カスタムエンドポイントを作成します。クラスターには、[サービスノード] として [読み取り専用 IMCI ノード] のみを含めることができます。
3. IMCI を追加する
手動または自動の方法を使用して、IMCI をビジネステーブルに追加できます。
クエリを高速化するには、SQL 文に含まれるすべての列が IMCI でカバーされている必要があります。
IMCI を手動で追加する
IMCI は、ビジネステーブルの IMCI の追加または削除をサポートする包括的な DDL 文を提供します。
DDL 構文 | 例 |
| |
| |
|
IMCI を追加する際は、元のコメントを保持できます。例:
ALTER TABLE <table_name> COMMENT 'COLUMNAR=1 <元のコメント>';。デフォルトでは、データベース/テーブルレベルで IMCI をバッチで追加すると、テーブルのコメントは
'COLUMNAR=1 <元のコメント>'に変更されます。
IMCI を自動で追加する
IMCI が提供する 自動高速化 (AutoIndex) 機能は、低速の SQL 文に基づいて IMCI を自動的に作成できるため、低速の SQL 文の実行速度を大幅に向上させることができ、最適化のために各低速の SQL 文を深く理解する必要はありません。アプリケーションのワークロードの変化に応じて、自動 IMCI 高速化機能は IMCI 戦略を継続的に監視および調整し、PolarDB クラスターが最適なパフォーマンスを維持できるようにします。PolarDB
PolarDB クラスタの詳細ページで、[有効にする] を選択して IMCI ベースのクエリ高速化機能を自動的に有効にするだけです。

(オプション) 4. IMCI のビルド進捗状況を確認する
IMCI を手動で追加した後、IMCI の DDL 実行速度とビルド進捗状況を表示する必要があります。IMCI のビルドが完了すると、クエリが高速化されます。
SELECT * FROM INFORMATION_SCHEMA.IMCI_ASYNC_DDL_STATS;たとえば、STATUS が Safe to read であるかどうかを確認することで、IMCI がビルドされたかどうかを確認できます。
+-------------+------------+---------------------+---------------------+---------------------+--------------+------------------+-----------------+-------------+-------------+-------------+------------+--------------+-----------+-------------------+-----------------+
| SCHEMA_NAME | TABLE_NAME | CREATED_AT | STARTED_AT | FINISHED_AT | STATUS | APPROXIMATE_ROWS | SCANNED_ROWS | SCAN_SECOND | SORT_ROUNDS | SORT_SECOND | BUILD_ROWS | BUILD_SECOND | AVG_SPEED | SPEED_LAST_SECOND | ESTIMATE_SECOND |
+-------------+------------+---------------------+---------------------+---------------------+--------------+------------------+-----------------+-------------+-------------+-------------+------------+--------------+-----------+-------------------+-----------------+
| tpch | lineitem | 2024-10-21 13:44:02 | 2024-10-21 13:44:02 | 2024-10-21 13:50:11 | Safe to read | 590446240 | 600037902(100%) | 369 | 0 | 0 | 0(0%) | 0 | 1625058 | 0 | 0 |
+-------------+------------+---------------------+---------------------+---------------------+--------------+------------------+-----------------+-------------+-------------+-------------+------------+--------------+-----------+-------------------+-----------------+
1 row in set, 1 warning (0.00 sec)(オプション) 5. SQL 文が IMCI を使用しているかどうかを確認する
IMCI 実行プランは水平ツリー形式で出力されます。これは、行ストア実行プランの出力形式とは大きく異なります。EXPLAIN 文を使用して、IMCI を使用して SQL クエリを高速化するかどうかを判断できます。次の例を参照してください。
IMCI 実行プラン (水平ツリー形式)
+----+----------------------------+----------+--------+--------+-----------------------------------------------------------------------------+
| ID | Operator | Name | E-Rows | E-Cost | Extra Info |
+----+----------------------------+----------+--------+--------+-----------------------------------------------------------------------------+
| 1 | Select Statement | | | | IMCI Execution Plan (max_dop = 4, max_query_mem = 858993459) |
| 2 | └─Sort | | | | Sort Key: revenue DESC,o_orderdate ASC |
| 3 | └─Hash Groupby | | | | Group Key: (lineitem.L_ORDERKEY, orders.O_ORDERDATE, orders.O_SHIPPRIORITY) |
| 4 | └─Hash Join | | | | Join Cond: orders.O_ORDERKEY = lineitem.L_ORDERKEY |
| 5 | ├─Hash Join | | | | Join Cond: customer.C_CUSTKEY = orders.O_CUSTKEY |
| 6 | │ ├─Table Scan | customer | | | Cond: (C_MKTSEGMENT = "BUILDING") |
| 7 | │ └─Table Scan | orders | | | Cond: (O_ORDERDATE < 03/24/1995) |
| 8 | └─Table Scan | lineitem | | | Cond: (L_SHIPDATE > 03/24/1995) |
+----+----------------------------+----------+--------+--------+-----------------------------------------------------------------------------+
8 rows in set (0.01 sec)行ストア実行プラン
+----+-------------+----------+------------+------+--------------------+------------+---------+-----------------------------+--------+----------+----------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------+------------+------+--------------------+------------+---------+-----------------------------+--------+----------+----------------------------------------------+
| 1 | SIMPLE | customer | NULL | ALL | PRIMARY | NULL | NULL | NULL | 147630 | 10.00 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | orders | NULL | ref | PRIMARY,ORDERS_FK1 | ORDERS_FK1 | 4 | tpch100g.customer.C_CUSTKEY | 14 | 33.33 | Using where |
| 1 | SIMPLE | lineitem | NULL | ref | PRIMARY | PRIMARY | 4 | tpch100g.orders.O_ORDERKEY | 4 | 33.33 | Using where |
+----+-------------+----------+------------+------+--------------------+------------+---------+-----------------------------+--------+----------+----------------------------------------------+
3 rows in set, 1 warning (0.00 sec)補助ツール
IMCI を使用して複雑な SQL 文をクエリする場合、SQL 文のすべての列が IMCI でカバーされているかどうかを確認する必要があります。IMCI でカバーされていない列が見つかった場合は、IMCI を作成するために使用された DDL 文を取得するか、IMCI を作成するために使用された DDL 文をバッチで取得できます。取得した DDL 文を実行した後、SQL 文のすべての列が IMCI でカバーされていることを確認して、クエリを高速化します。
PolarDB クラスタの組み込みストアドプロシージャは次のとおりです。
SQL 文のテーブルに IMCI が作成されているかどうかを確認するためのストアドプロシージャ:
dbms_imci.check_columnar_index('<query_string>');。IMCI を作成するために使用された DDL 文を取得するためのストアドプロシージャ:
dbms_imci.columnar_advise('<query_string>');およびdbms_imci.columnar_advise_by_columns('<query_string>');。IMCI を作成するために使用された DDL 文をバッチで取得するためのストアドプロシージャ:
dbms_imci.columnar_advise_begin();、dbms_imci.columnar_advise_show();、およびdbms_imci.columnar_advise_end();。
よくある質問
詳細については、「IMCI に関するよくある質問」をご参照ください。
高度な使用方法
IMCI の使用を最適化するには、次の機能を使用します。
機能 | 説明 |
IMCI データの基本的な組織単位は行グループです。各行グループでは、各列が列データブロックにパックされます。列データブロックは、行の生データのプライマリキーの順序に基づいて並列に構築されるため、全体としては順序付けられていない状態になります。クエリのパフォーマンスを向上させるために、ソートキーを設定して列データブロックのデータをソートできます。 | |
IMCI は、JSON 形式データの列指向ストレージ、仮想列、インスタント DDL、テーブルの列の最大数の拡張など、一連の関連機能を統合して、大量の構造化データおよび半構造化データの分析シナリオを処理します。 | |
ETL (Extract Transform Load) 機能を使用すると、読み取り/書き込み (RW) ノードで IMCI を使用できます。読み取り/書き込み (RW) ノードの SQL 文における | |
サーバーレス 機能は、ビジネスワークロードに基づいてクラスターを自動的にスケーリングします。ピーク時には、トラフィックの急増に対応するためにクラスターが自動的にスケールアップされます。オフピーク時には、コストを削減するためにクラスターが自動的にスケールダウンされます。 | |
ハイブリッドプラン とは、同じクエリ文で列インデックスと行インデックスの両方を使用するクエリメソッドのことです。ハイブリッドプラン は、ワイドテーブルクエリの実行速度を大幅に向上させます。実行計画では、IMCI に適した文が IMCI を介して実行され、プライマリキー情報のみを含む中間結果が取得されます。最終的に必要な列情報は、プライマリキーと InnoDB プライマリインデックスを組み合わせてクエリされ、出力されます。 | |
大量データに対する複雑なクエリの場合、単一の読み取り専用 IMCI ノードではパフォーマンス要件を満たせなくなる可能性があります。クエリを高速化するために、マルチノード並列処理を使用できます。 |
高度な使用方法
IMCI のしくみについて関心がある場合は、次のドキュメントを参照して理解を深めることができます。