OpenSearch は、複数テーブルに対する JOIN 操作をサポートしています。
ApsaraDB RDS for MySQL または PolarDB for MySQL データソースが複数のテーブルに対して構成され、データ伝送サービス (DTS) を使用して自動インクリメンタルデータ同期が有効になっている場合、プライマリテーブルとセカンダリテーブルのデータを OpenSearch に同期できます。データ同期の低レイテンシを確保するために、次の制限が課せられます。
プライマリテーブルとセカンダリテーブルの更新は、1 秒あたり 1,500 トランザクション (TPS) を超えることはできません。超えると、プライマリテーブルとセカンダリテーブルのデータがリアルタイムで同期されない可能性があります。
セカンダリテーブルの更新によってトリガーされるプライマリテーブルの更新は、1,000 TPS を超えることはできません。超えると、プライマリテーブルとセカンダリテーブルからのデータ同期が遅延する可能性があります。
プライマリテーブルのレコードとセカンダリテーブルのレコードの比率が N:1 の場合、N の値は 10 以下にすることをお勧めします。
プライマリテーブルとセカンダリテーブルの JOIN 操作
次の図は、プライマリテーブルとセカンダリテーブルがどのように結合されるかを示しています。
セカンダリテーブルの更新操作
次の図は、プライマリテーブルとセカンダリテーブルを示しています。プライマリテーブルのレコードとセカンダリテーブルのレコードの比率は N:1 です。
前の図に示すように:
プライマリテーブルとセカンダリテーブルで JOIN 操作が実行されると、ワイドテーブルが生成されます。すべての更新操作はワイドテーブルに対して実行されます。
プライマリテーブルのプライマリキーは一意です。プライマリキー ID に対応するデータレコードがプライマリテーブルで更新されると、ワイドテーブルの対応するデータレコードも更新されます。
プライマリテーブルのレコードとセカンダリテーブルのレコードの比率は N:1 です。プライマリテーブルの複数のデータレコードが、セカンダリテーブルの 1 つのプライマリキー ID に対応する場合があります。
セカンダリテーブルでプライマリキー ID に対応するデータレコードが更新されると、
ワイドテーブルの複数のデータレコードも更新される可能性があります。
結論:
セカンダリテーブルの大量のデータが更新されると、プライマリテーブルの更新が遅延する可能性があります。プライマリテーブルを低レイテンシで更新できるようにするには、セカンダリテーブルの更新によってトリガーされるプライマリテーブルの更新は 1,500 TPS を超えないようにする必要があります。
セカンダリテーブルの更新によってトリガーされるプライマリテーブルの更新が 1,500 TPS を超える場合、セカンダリテーブルの更新速度が制限されます。これにより、セカンダリテーブルの更新に高いレイテンシが発生する可能性があります。セカンダリテーブルで大量のデータが更新される場合、更新レイテンシは高くなります。
プライマリテーブルのレコードとセカンダリテーブルのレコードの比率が N:1 の場合、N の値は 10 以下にすることをお勧めします。
関連する提案
プライマリテーブルの更新のレイテンシを許容できる場合は、チケットを送信してセカンダリテーブルの更新の最大 TPS を増やすことができます。
セカンダリテーブルの更新のレイテンシを許容でき、セカンダリテーブルの更新によってトリガーされるプライマリテーブルの更新のレイテンシが高い場合は、チケットを送信してセカンダリテーブルの更新の最大 TPS に制限を設定することができます。