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

PolarDB:検索ビューとETLストアドプロシージャ

最終更新日:Jul 21, 2026

PolarDB for MySQL のビジネスデータに対して全文検索や複雑な分析を実行する必要がある場合、データベース上で直接操作すると、コアビジネスの安定性に影響を与える可能性があります。PolarDB は、AutoETL 機能を提供し、クラスター内の読み取り/書き込みノードから PolarSearch ノードへデータを自動的かつ継続的に同期します。検索ビューまたは ETL ストアドプロシージャを使用してデータ同期リンクを作成できます。このアプローチにより、個別の ETL ツールをデプロイして維持する必要がなくなり、検索および分析ワークロードをオンラインのトランザクション処理ワークロードから分離できます。

説明

AutoETL を使用してリンクを作成すると、デフォルトで AutoETL エンジンに PolarDB のデータへのアクセス権が付与され、同期が実行されます。

機能概要

AutoETL は、PolarDB for MySQL の組み込みデータ同期機能であり、クラスター内の異なるタイプのノード間でデータを自動的に同期します。現在のバージョンでは、高性能な検索と分析のために、同じクラスター内の PolarDB for MySQL から PolarSearch ノードへのデータ同期のみをサポートしています。

AutoETL は、データ同期リンクを作成するために次の 2 つの方法を提供しています。

  • 検索ビューCREATE SEARCH VIEW 構文を使用して、標準 SQL でデータ同期ロジックを定義します。この方法は、システムが自動的に内部の接続詳細を処理するため、ほとんどの単一テーブル同期および複数テーブルの集計シナリオに適しています。

  • ETL ストアドプロシージャ (dbms_etl.sync_by_sql):Flink SQL 互換構文のストアドプロシージャを使用して、データクレンジング、変換、集計のための複雑なロジックを定義します。

前提条件

AutoETL 機能を使用する前に、お使いの環境が次の要件を満たしていることを確認してください。

  • クラスターバージョン

    • 検索ビュー

      • MySQL 8.0.1、リビジョンバージョン 8.0.1.1.54 以降。

      • MySQL 8.0.2、リビジョンバージョン 8.0.2.2.34 以降。

    • ETL ストアドプロシージャ (sync_by_sql)

      • MySQL 8.0.1、リビジョンバージョン 8.0.1.1.52 以降。

      • MySQL 8.0.2、リビジョンバージョン 8.0.2.2.33 以降。

  • バイナリログ:クラスターでバイナリログが有効になっている必要があります。

  • 同期方向:同じクラスター内の PolarDB for MySQL から PolarSearch ノードへの同期のみが可能です。

  • DDL の制約:関連付けられた検索ビューまたは ETL ストアドプロシージャを持つソーステーブルで DDL 操作を実行する場合、同期の中断を避けるために特定のルールに従う必要があります。互換性のない変更によっては、検索ビューを再作成する必要があります。詳細については、「DDL 変更のルールとベストプラクティス」をご参照ください。

  • データ型:AutoETL は、BIT データ型や、GEOMETRYPOINTLINESTRINGPOLYGONMULTIPOINTMULTILINESTRINGMULTIPOLYGONGEOMETRYCOLLECTION などの空間データ型の同期をサポートしていません。

  • 検索ビューのクエリ制約:検索ビューは同期セマンティクスを定義するためにのみ使用でき、データクエリはサポートしていません。データをクエリするには、PolarSearch ノードに直接接続してください。

  • コンピューティングリソース:AutoETL は、コンピューティングユニットとして CU (コンピューティングユニット) を使用します。デフォルトでは、クラスターの CU クォータは、すべての PolarSearch ノードの CPU コア数の合計の 2 倍に相当します。コンソールで 設定と管理 > 検索管理 を選択し、[AutoETL] タブに移動して現在の CU 使用量を確認できます。

検索ビュー

検索ビューは、AutoETL が提供する宣言型のデータ同期メカニズムです。標準の SQL 構文を使用して検索ビューを作成でき、これによりソーステーブルから PolarSearch ノードへの継続的なデータ同期リンクが自動的に確立されます。

検索ビューの作成

構文

CREATE SEARCH VIEW view_name [(column_list, PRIMARY KEY (pk_column_list))] AS select_statement;

パラメータ

パラメータ

必須

説明

view_name

はい

検索ビューの名前。これは、PolarSearch ノードのターゲットインデックス名でもあります。

column_list

いいえ

検索ビューの列を手動で定義します。複数の列はカンマ (,) で区切ります。

説明

単一テーブルの同期の場合、column_list を指定する必要はありません。デフォルトでは、ソーステーブルの元の列名が使用されます。

pk_column_list

いいえ

検索ビューのプライマリキー列を指定します。検索ビューの構造は PolarSearch ノードのインデックスマッピングに対応しており、pk_column_list を使用して PolarSearch ノードのインデックスドキュメント ID を指定します。

このパラメータが指定されていない場合、デフォルトで column_list の最初の列がドキュメント ID として使用されます。単一テーブルの同期の場合、デフォルトでソーステーブルのプライマリキーがドキュメント ID として使用されます。

select_statement

はい

データソースと同期ロジックを定義する SELECT ステートメント。このステートメントは、ソーステーブルからデータを取得し、その結果を PolarSearch に保存します。単一テーブルのクエリや、複数テーブルの JOINUNION ALLGROUP BY 句などの操作をサポートします。

使用上の注意と制約

  • ソーステーブルにはプライマリキーまたは一意キーが必要です。

  • 検索ビューで参照されるすべてのソーステーブルに対する ALTER 権限と、関連する列またはテーブル全体に対する SELECT 権限が必要です。

  • 検索ビューを作成した後、デフォルトではソーステーブルに追加された新しい列は同期されません。新しい列を同期するには、「検索ビューの変更」をご参照ください。

  • ターゲットインデックスにカスタム設定を使用したい場合は、まず PolarSearch ノードで手動でインデックスを作成し、その設定を定義してから、検索ビューを作成できます。検索ビューの作成時にターゲットインデックスが存在しない場合、システムは自動的にインデックスを作成します。

  • JSON フィールドの変換や、複数テーブルの集計または複雑なクエリのルーティングフィールドなど、高度な同期パラメータを設定するには、「AutoETL パラメータの設定と使用例」をご参照ください。

データの準備

以下の例のテストデータを準備するには、PolarDB for MySQL で次の SQL ステートメントを実行してください。

CREATE DATABASE IF NOT EXISTS db1;
CREATE DATABASE IF NOT EXISTS db2;

USE db1;
CREATE TABLE IF NOT EXISTS t1 (
    id INT PRIMARY KEY,
    c1 VARCHAR(100),
    c2 VARCHAR(100)
);
INSERT INTO t1(id, c1, c2) VALUES
(1, 'apple', 'red'),
(2, 'banana', 'yellow'),
(3, 'grape', 'purple');

USE db2;
CREATE TABLE IF NOT EXISTS t2 (id INT PRIMARY KEY, c2 INT);
INSERT INTO t2(id, c2) VALUES (1, 111), (2, 222), (4, 444);

  • テーブル全体の同期db1.t1 のすべてのデータを PolarSearch に同期します。ビュー名 view_test は、PolarSearch のターゲットインデックスの名前として機能します。

    CREATE SEARCH VIEW view_test AS SELECT * FROM db1.t1;
  • 特定の列の同期c1c2 の列のみを PolarSearch に同期します。

    CREATE SEARCH VIEW view_test1 AS SELECT c1, c2 FROM db1.t1;
  • 条件付きフィルタリングWHERE 条件を満たすデータのみを同期します。

    CREATE SEARCH VIEW view_test2 AS SELECT id, c1, c2 FROM db1.t1 WHERE c1 > 10;
  • 複数テーブルの JOINdb1.t1db2.t2id フィールドで結合し、結果を PolarSearch に同期します。

    CREATE SEARCH VIEW view_test3(id, c1, c2) AS SELECT t1.id, t1.c1, t2.c2 FROM db1.t1 AS t1 LEFT JOIN db2.t2 AS t2 ON t1.id = t2.id;
  • 複数テーブルの UNION:同じ構造を持つ複数のテーブルをマージして同期します。SELECT ステートメントは、同じ数と型の列を持つ必要があります。

    CREATE SEARCH VIEW view_test4(id, c2) AS SELECT id, c2 FROM db1.t1 UNION ALL SELECT id, c2 FROM db2.t2;
  • グループ化と集計:同期前にデータをグループ化して集計します。GROUP BY を使用する場合は、列とプライマリキーを手動で定義する必要があります。

    CREATE SEARCH VIEW view_test5 (id, max_c) AS SELECT t1.id, MAX(t1.c1) AS max_c FROM db1.t1 GROUP BY t1.id;

データの検証

検索ビューの同期ステータスを確認します。

SHOW SEARCH VIEW STATUS;

ステータスが active の場合、検索ビューは期待どおりにデータを同期しています。PolarSearch ノードに接続し、Elasticsearch 互換の REST API を使用してデータを検証します。

# : を PolarSearch ノードの認証情報に、 を PolarSearch ノードの接続エンドポイントとポートに置き換えます。
curl -u : -X GET "http:///view_test/_search"

検索ビューの管理

次のコマンドを使用して、検索ビューを表示できます。

  • すべての検索ビューのステータスを表示します。

    SHOW SEARCH VIEW STATUS;

    次の結果が返されます。ステータスが active の場合、検索ビューは期待どおりにデータを同期していることを示します。

    +------------+--------+----------+---------+---------------------+---------------------+
    | View Name  | Type   | Status   | Message | Created_at          | Updated_at          |
    +------------+--------+----------+---------+---------------------+---------------------+
    | view_test  | search | active   |         | 2026-03-18 18:44:12 | 2026-03-18 18:51:37 |
    +------------+--------+----------+---------+---------------------+---------------------+
  • 特定の検索ビューの作成ステートメントを表示します。

    SHOW CREATE SEARCH VIEW view_test;

    次の結果が返されます。

    +-----------+------------------------------------------------------+
    | View Name | Create Search View                                   |
    +-----------+------------------------------------------------------+
    | view_test | CREATE SEARCH VIEW view_test AS SELECT * FROM db1.t1 |
    +-----------+------------------------------------------------------+

検索ビューの削除

重要

検索ビューの削除は高リスク操作です。注意して実行してください。この操作は、検索ビューのデータ同期を停止し、関連リソースをクリーンアップしますが、PolarSearch のインデックスデータは削除しません

DROP SEARCH VIEW view_name;

検索ビューを削除するときのシステムの動作は、そのステータスによって異なります。

  • active 状態の検索ビューの場合、ステータスはまず dropping に変わります。システムが同期リソースのクリーンアップを完了すると、ステータスは dropped に変わります。

  • dropped 状態の検索ビューを削除すると、システムはその検索ビューに関するすべての情報を完全に削除します。

  • 他の状態にある検索ビューは削除できません。

検索ビューの変更

同期フィールドの追加やクエリ条件の変更など、検索ビューの同期ロジックを変更する必要がある場合は、「新しいインデックス + 新しい検索ビュー」というアプローチを使用して再作成します。この方法は、ビジネスのクエリに影響を与えません。

  1. 新しい PolarSearch インデックスにデータを同期する新しい検索ビューを作成します。

  2. SHOW SEARCH VIEW STATUS を実行して、新しい検索ビューのステータスを確認します。同期のレイテンシーが 0〜1 秒に低下したら、ビジネスのクエリロジックを古いインデックスから新しいインデックスに切り替えます。

  3. 古い検索ビューを削除します。

ソーステーブルの DDL 変更が検索ビューに与える影響と変更のベストプラクティスについては、「DDL 変更のルールとベストプラクティス」をご参照ください。

ETL ストアドプロシージャ (sync_by_sql)

複雑な変換、集計、または計算が必要なシナリオでは、CALL dbms_etl.sync_by_sql ストアドプロシージャを使用して、Flink SQL 互換の構文でデータ同期ロジックを定義できます。

同期リンクの作成

構文

CALL dbms_etl.sync_by_sql("search", "");

説明

システムは、ホストアドレス、ポート、認証情報など、ソーステーブルとターゲットテーブルの接続情報を自動的に設定します。WITH 句で指定する必要はありません。

CALL dbms_etl.sync_by_sql("search", "

-- ステップ 1: PolarDB ソーステーブルの定義
CREATE TEMPORARY TABLE `db1`.`t1` (
  `id`   BIGINT,
  `c1`   STRING,
  PRIMARY KEY (`id`) NOT ENFORCED
) WITH (
  'connector' = 'mysql',
  'database-name' = 'db1',
  'table-name' = 't1'
);

-- ステップ 2: PolarSearch ターゲットテーブルの定義
CREATE TEMPORARY TABLE `dest` (
  `id`  BIGINT,
  `max_c` STRING,
  PRIMARY KEY (`id`) NOT ENFORCED
) WITH (
  'connector' = 'opensearch',
  'index' = 'dest'
);

-- ステップ 3: 計算および挿入ロジックの定義
INSERT INTO `dest`
SELECT
    `t1`.`id`,
    MAX(`t1`.`c1`)
FROM `db1`.`t1` AS `t1`
GROUP BY `t1`.`id`;
");

データの検証

PolarSearch ノードに接続し、Elasticsearch 互換の REST API を使用してクエリを実行し、データが同期されたことを確認します。

#  を PolarSearch ノードの接続エンドポイントに置き換えます。
curl -u : -X GET "http:///dest/_search"

同期リンクの管理

次のコマンドを使用して、データ同期リンクを表示できます。

  • すべてのリンクを表示するには、次のコマンドを使用します。

    CALL dbms_etl.show_sync_link();
  • ID で特定のリンクを表示するには、<sync_id> をリンク作成時に返された ID に置き換えます。

    CALL dbms_etl.show_sync_link_by_id('<sync_id>')\G

    返されるパラメータの説明は次のとおりです。

    *************************** 1. row ***************************
            SYNC_ID: crb5rmv8rttsg
               NAME: crb5rmv8rttsg
             SYSTEM: search
    SYNC_DEFINITION: db1.t1 -> dest
      SOURCE_TABLES: db1.t1
        SINK_TABLES: dest
             STATUS: active  -- リンクのステータス。`active` はリンクが正常に実行されていることを示します。
            MESSAGE:         -- エラーが発生した場合、エラーメッセージがここに表示されます。
         CREATED_AT: 2024-05-20 11:55:06
         UPDATED_AT: 2024-05-20 17:28:04
            OPTIONS: ...

同期リンクの削除

この操作は、データ同期を停止し、関連リソースをクリーンアップします。

重要

データ同期リンクの削除は高リスク操作です。注意して実行してください。この操作は、リンクのデータ同期を停止し、関連リソースをクリーンアップしますが、PolarSearch のインデックスデータは削除しません

CALL dbms_etl.drop_sync_link('<sync_id>');

drop_sync_link を実行してリンクを削除するときのシステムの動作は、そのステータスによって異なります。

  • active 状態のリンクの場合、ステータスはまず dropping に変わります。システムがリンクのリソースのクリーンアップを完了すると、ステータスは dropped に変わります。

  • dropped 状態のリンクを削除すると、システムはそのリンクに関するすべての情報を完全に削除します。

  • 他の状態にあるリンクは削除できません。

同期リンクの変更

データ同期リンクを変更する必要がある場合は、検索ビューと同じ「新しいインデックス + 新しいリンク」という方法を使用して再作成します。

  1. 新しい PolarSearch インデックスにデータを同期する新しいデータ同期リンクを作成します。

  2. CALL dbms_etl.show_sync_link_by_id('<sync_id>') を実行して、新しい同期リンクのステータスを確認します。同期のレイテンシーが 0〜1 秒に低下したら、ビジネスのクエリを古いインデックスから新しいインデックスに切り替えます。

  3. 古いデータ同期リンクを削除します。

よくある質問

検索ビューと ETL ストアドプロシージャ (sync_by_sql) の違いは何ですか?

主な違いは、ユースケースと複雑さです。

  • 検索ビュー:標準の SQL 構文 (CREATE SEARCH VIEW) を使用します。システムは、Flink SQL を記述する必要なく、内部の接続と同期の詳細を自動的に処理します。ほとんどの単一テーブル同期および複数テーブルの集計シナリオに適しています。

  • ETL ストアドプロシージャ:Flink SQL 互換の構文 (CALL dbms_etl.sync_by_sql) を使用します。複雑なデータクレンジング、変換、集計が必要なシナリオに適しており、Flink SQL による完全な制御を提供します。システムは、ソーステーブルとターゲットテーブルの接続設定を自動的に処理します。