データソースでレコードを追加または更新すると、その変更が検索結果としてユーザーに表示される前に、OpenSearch エンジンに反映される必要があります。OpenSearch では、リアルタイムな増分データを 3 段階のパイプラインを通じて同期します：データソースからオフラインアプリケーションへ、オフラインアプリケーションからワイドテーブルへ、およびオフラインアプリケーションから検索エンジンへ。各段階で設定されたレート制限により、エンジンが過負荷になるのを防ぎ、プライマリテーブルのレイテンシを低く保ちます。
データ取り込みパスの選択
増分データは、以下の 2 つのパスのいずれかを通じてパイプラインに入力されます：
| パス | 動作概要 | 使用するタイミング |
|---|---|---|
| DTS を使用したバイナリログのサブスクライブ | Data Transmission Service (DTS) がデータソースのバイナリログをサブスクライブし、変更内容を OpenSearch オフラインアプリケーションへストリーミングします。 | データソースがリレーショナルデータベースであり、アプリケーションコードの変更を伴わずに自動的かつ低レイテンシで変更をキャプチャしたい場合。 |
| API を使用したデータのプッシュ | アプリケーションが API 呼び出しを介して、データを直接 OpenSearch オフラインアプリケーションへ送信します。 | データがデータベース外で生成される場合、インデックス登録前にデータを前処理する場合、またはどのレコードをインデックス登録するかを細かくコントロールする必要がある場合。 |
両パスとも、同一の 3 段階パイプラインへと接続されます。
パイプラインの動作仕組み
ステージ 1：データソースからオフラインアプリケーションへ
DTS がデータソースのバイナリログをサブスクライブし、変更内容をオフラインアプリケーションへストリーミングします。API パスを利用する場合は、アプリケーションがデータを直接オフラインアプリケーションへプッシュします。いずれの場合も、プライマリテーブルおよびすべてのセカンダリテーブルを合わせた合計トランザクション数（TPS）は、1,500 TPS を超えてはなりません。
ステージ 2：オフラインアプリケーションからワイドテーブルへ
オフラインアプリケーションが受信した変更を既存のワイドテーブルへマージします。セカンダリテーブルの更新によってプライマリテーブルの更新がトリガーされ、そのトリガーによる更新が 1,000 TPS に達した場合、またはそれを超えた場合、システムはセカンダリテーブルの更新をスロットルします。これにより、プライマリテーブルの同期レイテンシを低く保つことができます。
複数テーブル結合が遅延に与える影響の詳細については、「複数テーブル結合によるデータ同期遅延」をご参照ください。
ステージ 3：オフラインアプリケーションからエンジンへ
オフラインアプリケーションがマージ済みのデータを OpenSearch エンジンへ書き込みます。この段階でメタデータが付与されるため、エンジンへ到達するデータ量は、元のソースデータの 2～3 倍となることがあります。エンジンを保護するため、書き込み速度は最大 10 MB/s に制限されます。
使用制限
| 項目 | 制限値 | 制限の理由 |
|---|---|---|
| データソースからオフラインアプリケーションへの合計 TPS（プライマリテーブルおよびセカンダリテーブルを含む、トリガー関係未設定時） | 1,500 TPS | オフラインアプリケーションのアップストリーム取り込み能力 |
| オフラインアプリケーションからエンジンへの書き込み速度 | 10 MB/s | メタデータの付与によりデータ量が 2～3 倍に拡大するため、エンジンの過負荷を防止するための制限 |
| セカンダリテーブルの更新によってトリガーされるプライマリテーブルの更新 | 1,000 TPS | このしきい値を超えると、プライマリテーブルのレイテンシを低く保つためにセカンダリテーブルの更新速度が低下する |
ワークロードがこれらの制限に近づくことが予想される場合は、本番環境に適用する前に TPS およびデータ量をモニターしてください。デフォルト値を超える要件がある場合は、Alibaba Cloud サポートまでお問い合わせください。