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

PolarDB:手順

最終更新日:May 01, 2025

インメモリ列インデックス (IMCI) は、ビジネスにおける複雑で時間のかかる SQL 文を高速化するためのシンプルなソリューションを提供します。クイックスタートを参照して、クラスターの HTAP 負荷処理機能を設定してください。さらに、高度な使用方法を参照して、特定のビジネス要件に合わせて IMCI をカスタマイズしてください。

クイックスタート

1. 読み取り専用 IMCI ノードを追加する

PolarDB コンソール にログオンし、クラスタが配置されているリージョンを選択して、[クラスタ] リストで対象のクラスタを見つけます。 [アクション] 列で、[ノードの追加/削除] を選択して、読み取り専用の IMCI ノードを追加します。image

説明
  • クラスターの購入時に既に読み取り専用 IMCI ノードを追加している場合は、この手順をスキップしてください。

  • クラスターは IMCI のバージョン要件を満たしている必要があります。詳細については、「読み取り専用 IMCI ノードを追加する」をご参照ください。

2. 行ストアノードと IMCI ノード間のリクエスト分散を設定する

IMCI を使用するために、自動または手動のリクエスト分散を選択できます。

  • 行ストアノードと IMCI ノード間の自動リクエスト分散: アプリケーションが OLAP サービスと OLTP サービスの両方にアクセスするリクエストを送信する場合、推定実行コスト (リクエストによってスキャンされる行数) に基づいて読み取りリクエストの自動分散を設定し、読み取り専用 IMCI ノードまたは読み取り専用行ストアノードのいずれかにルーティングできます。

  • 行ストアノードと IMCI ノード間の手動リクエスト分散: 異なるアプリケーションを使用して OLAP サービスと OLTP サービスのリクエストを送信する場合は、アプリケーションごとに異なるクラスターエンドポイントを設定し、行ストアノードと IMCI ノードを異なるクラスターエンドポイントに関連付けてリクエストを分散できます。

行ストアノードと IMCI ノード間の自動リクエスト分散

クラスタ詳細ページに移動し、[データベース接続] セクションで、[クラスターエンドポイント] のトランザクション/分析処理分割を [オン] に設定します。image

説明

行ストアノードと IMCI ノード間の手動リクエスト分散

クラスター詳細ページに移動し、[データベース接続] セクションで、カスタムエンドポイントを作成します。クラスターには、[サービスノード] として [読み取り専用 IMCI ノード] のみを含めることができます。image

3. IMCI を追加する

手動または自動の方法を使用して、IMCI をビジネステーブルに追加できます。

重要

クエリを高速化するには、SQL 文に含まれるすべての列が IMCI でカバーされている必要があります。

IMCI を手動で追加する

IMCI は、ビジネステーブルの IMCI の追加または削除をサポートする包括的な DDL 文を提供します。

DDL 構文

テーブルの作成時に IMCI を作成する

-- 特定の列に IMCI を追加する
CREATE TABLE <table_name>(
  <column_name_1> INT COMMENT 'COLUMNAR=1',
  <column_name_2> VARCHAR(100)
) ENGINE InnoDB;

-- テーブル全体に IMCI を追加する
CREATE TABLE <table_name>(
  <column_name_1> INT,
  <column_name_2> VARCHAR(100)
) ENGINE InnoDB COMMENT 'COLUMNAR=1';

DDL 文を実行して IMCI を動的に作成および削除する

-- 特定の列に IMCI を追加する
ALTER TABLE <table_name> MODIFY COLUMN <column_name_1> INT COMMENT 'COLUMNAR=1';
               
-- テーブル全体に IMCI を追加する
ALTER TABLE <table_name> COMMENT 'COLUMNAR=1';

DDL 文を使用してテーブルレベルの IMCI を管理する

-- テーブル全体に IMCI を追加する
CREATE COLUMNAR INDEX ON <db_name>.<table_name>;

-- データベース全体に IMCI を追加する
CREATE COLUMNAR INDEX FOR TABLES IN <db_name>;
説明
  • IMCI を追加する際は、元のコメントを保持できます。例: ALTER TABLE <table_name> COMMENT 'COLUMNAR=1 <元のコメント>';

  • デフォルトでは、データベース/テーブルレベルで IMCI をバッチで追加すると、テーブルのコメントは 'COLUMNAR=1 <元のコメント>' に変更されます。

IMCI を自動で追加する

IMCI が提供する 自動高速化 (AutoIndex) 機能は、低速の SQL 文に基づいて IMCI を自動的に作成できるため、低速の SQL 文の実行速度を大幅に向上させることができ、最適化のために各低速の SQL 文を深く理解する必要はありません。アプリケーションのワークロードの変化に応じて、自動 IMCI 高速化機能は IMCI 戦略を継続的に監視および調整し、PolarDB クラスターが最適なパフォーマンスを維持できるようにします。PolarDB

PolarDB クラスタの詳細ページで、[有効にする] を選択して IMCI ベースのクエリ高速化機能を自動的に有効にするだけです。

image

(オプション) 4. IMCI のビルド進捗状況を確認する

IMCI を手動で追加した後、IMCI の DDL 実行速度とビルド進捗状況を表示する必要があります。IMCI のビルドが完了すると、クエリが高速化されます。

SELECT * FROM INFORMATION_SCHEMA.IMCI_ASYNC_DDL_STATS;

たとえば、STATUSSafe 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 を使用しないのはなぜですか?

SQL クエリが高速化のために IMCI を使用するのは、次の条件がすべて満たされる場合のみです。読み取り専用の IMCI ノードがクラスタに追加されている。SQL クエリに関連するテーブルに IMCI が作成されている。[推定実行コスト] が指定されたしきい値を超えている。SQL クエリが読み取り専用の IMCI ノードに転送される。SQL クエリが IMCI を使用しない場合は、次の手順を実行して問題のトラブルシューティングを行うことができます。

  1. SQL クエリが読み取り専用 IMCI ノードに転送されているかどうかを確認します。

    • 読み取り専用 IMCI ノードがクラスターエンドポイントの [選択済みノード] に含まれているかどうかを確認します。

    • SQL エクスプローラー機能を使用して、SQL クエリが読み取り専用 IMCI ノードに転送されているかどうかを確認します。詳細については、「SQL エクスプローラー」をご参照ください。

    PolarProxy は、次の条件がすべて満たされた場合にのみ、読み取り専用の IMCI ノードに SQL クエリを転送します。SQL クエリが [クラスターエンドポイント] を使用してクラスターにアクセスしていること、[トランザクション/分析処理分割] がクラスターエンドポイントで有効になっていること、および SQL クエリの推定実行コストloose_imci_ap_threshold パラメーターまたは loose_cost_threshold_for_imci パラメーターで指定されたしきい値を超えていることです。/*FORCE_IMCI_NODES*/ ヒントを SQL 文の SELECT キーワードの前に追加することで、SQL 文を強制的に読み取り専用の IMCI ノードに転送できます。詳細については、「自動リクエスト分散のしきい値を指定する」をご参照ください。例:

    データベースエンジンのマイナーバージョンが 8.0.1.1.39 以降、または 8.0.2.2.23 以降の場合、loose_cost_threshold_for_imci パラメーターの代わりに loose_imci_ap_threshold パラメーターが使用されます。
    /*FORCE_IMCI_NODES*/EXPLAIN SELECT COUNT(*) FROM t1 WHERE t1.a > 1;
    カスタムエンドポイントを作成し、そのエンドポイントを読み取り専用 IMCI ノードに関連付けることができます。これにより、SQL クエリが読み取り専用 IMCI ノードに転送されて実行されることが保証されます。詳細については、「HTAP ベースの行ストアノードと IMCI ノード間のリクエスト分散」をご参照ください。
  2. 推定実行コストSQL クエリの推定実行コストが指定されたしきい値よりも高いかどうかを確認します。

    IMCI ノードでは、オプティマイザーは SQL クエリの推定実行コストを計算します。SQL クエリの推定実行コストが、loose_imci_ap_threshold パラメーターまたは cost_threshold_for_imci パラメーターで指定されたしきい値よりも高い場合、オプティマイザーはクエリで IMCI を使用します。それ以外の場合、オプティマイザーはクエリで元の行インデックスを使用します。

    EXPLAIN 文で、SQL クエリが読み取り専用 IMCI ノードに転送された後も実行計画で IMCI が使用されていないことが示されている場合は、推定実行コスト を指定されたしきい値と比較して、推定実行コスト が小さすぎるために IMCI が使用されていないかどうかを判断します。Last_query_cost 値をクエリして、前の SQL 文の 推定実行コスト を取得できます。例:

    -- EXPLAIN 文を実行して、SQL クエリの実行プランを表示します。
    EXPLAIN SELECT * FROM t1;
    -- 前の SQL クエリの推定実行コストを取得します。
    SHOW STATUS LIKE 'Last_query_cost';
    クラスターエンドポイントを使用してクラスターに接続する場合は、/*ROUTE_TO_LAST_USED*/ ヒントを SHOW STATUS LIKE 'Last_query_cost' 文の前に追加することをお勧めします。これにより、前の文の推定実行コストが正しいノードで見つかるようになります。例: /*ROUTE_TO_LAST_USED*/SHOW STATUS LIKE 'Last_query_cost';

    SQL クエリの 推定実行コスト が指定されたしきい値未満の場合、loose_imci_ap_threshold または loose_cost_threshold_for_imci の値を調整できます。HINT を使用して、単一の SQL クエリの実行コストしきい値を調整することもできます。例:

    /*FORCE_IMCI_NODES*/EXPLAIN SELECT /*+ SET_VAR(cost_threshold_for_imci=0) */ COUNT(*) FROM t1 WHERE t1.a > 1;
  3. SQL クエリに含まれるテーブルまたは列が IMCI に完全に含まれているかどうかを確認します。

    組み込みストアドプロシージャ dbms_imci.check_columnar_index('<query_string>') を呼び出して、SQL 文のテーブルまたは列に IMCI が作成されているかどうかを確認できます。詳細については、「SQL 文のテーブルに IMCI が作成されているかどうかを確認する」をご参照ください。例:

    CALL dbms_imci.check_columnar_index('SELECT COUNT(*) FROM t1 WHERE t1.a > 1');

    SQL クエリに含まれるテーブルまたは列が IMCI に完全に含まれていない場合、ストアドプロシージャは IMCI に含まれていないテーブルと列を返します。この場合、返されたテーブルと列に対して IMCI を作成する必要があります。 SQL クエリに含まれるテーブルまたは列が IMCI に完全に含まれている場合、ストアドプロシージャは空の結果セットを返します。

  4. SQL クエリが IMCI をサポートしているかどうかを確認します。

    IMCI の使用制限を表示して、SQL クエリが IMCI をサポートしているかどうかを確認します。詳細については、「IMCI の使用制限」をご参照ください。

SQL クエリで依然として IMCI が使用されていない場合は、手順を参照するか、またはお問い合わせください。

詳細については、「IMCI に関するよくある質問」をご参照ください。

高度な使用方法

IMCI の使用を最適化するには、次の機能を使用します。

機能

説明

IMCI のソートキーを設定する

IMCI データの基本的な組織単位は行グループです。各行グループでは、各列が列データブロックにパックされます。列データブロックは、行の生データのプライマリキーの順序に基づいて並列に構築されるため、全体としては順序付けられていない状態になります。クエリのパフォーマンスを向上させるために、ソートキーを設定して列データブロックのデータをソートできます。

JSON 形式のデータを効率的に分析する

IMCI は、JSON 形式データの列指向ストレージ仮想列インスタント DDLテーブルの列の最大数の拡張など、一連の関連機能を統合して、大量の構造化データおよび半構造化データの分析シナリオを処理します。

IMCI を使用して ETL を高速化する

ETL (Extract Transform Load) 機能を使用すると、読み取り/書き込み (RW) ノードで IMCI を使用できます。読み取り/書き込み (RW) ノードの SQL 文における SELECT リクエストは、読み取り専用 IMCI ノードに送信され、IMCI を使用して高速化されます。データの読み取り後、システムは内部ネットワークを介して読み取り/書き込み (RW) ノードにデータを転送し、ターゲットテーブルに書き込みます。

読み取り専用 IMCI ノードでサーバーレス機能を有効にする

サーバーレス 機能は、ビジネスワークロードに基づいてクラスターを自動的にスケーリングします。ピーク時には、トラフィックの急増に対応するためにクラスターが自動的にスケールアップされます。オフピーク時には、コストを削減するためにクラスターが自動的にスケールダウンされます。

ハイブリッドプランを使用してワイドテーブルクエリを高速化する

ハイブリッドプラン とは、同じクエリ文で列インデックスと行インデックスの両方を使用するクエリメソッドのことです。ハイブリッドプラン は、ワイドテーブルクエリの実行速度を大幅に向上させます。実行計画では、IMCI に適した文が IMCI を介して実行され、プライマリキー情報のみを含む中間結果が取得されます。最終的に必要な列情報は、プライマリキーと InnoDB プライマリインデックスを組み合わせてクエリされ、出力されます。

マルチノード MPP を使用して大量データ分析を高速化する

大量データに対する複雑なクエリの場合、単一の読み取り専用 IMCI ノードではパフォーマンス要件を満たせなくなる可能性があります。クエリを高速化するために、マルチノード並列処理を使用できます。

高度な使用方法

IMCI のしくみについて関心がある場合は、次のドキュメントを参照して理解を深めることができます。