Kafka パーティション同期戦略 - Data Transmission Service - Alibaba Cloud ドキュメントセンター

Kafka へのデータ同期ジョブを設定する際、パフォーマンスを向上させるために Kafka パーティション同期戦略を調整できます。たとえば、ハッシュ結果に基づいてデータを異なるパーティションに同期できます。

ハッシュアルゴリズム

DTS は、ハッシュ値を計算するために Java のデフォルトハッシュコードアルゴリズムを使用します。

設定方法

データ同期ジョブの オブジェクト設定 ステップで、Kafka パーティションへのデータ転送ポリシー を設定します。

警告

データ同期ジョブを開始した後、宛先 Topic のパーティション数を変更しないでください。変更すると、同期タスクが失敗したり、ダウンストリームコンシューマーでデータ不整合が発生したりする可能性があります。

戦略の詳細

ソースデータベースは Kafka

ポリシー名	説明	利点と欠点
すべてのデータをパーティション 0 に転送	このポリシーは、すべてのデータと DDL 情報を宛先 Topic のパーティション 0 に配信します。	利点: すべてのオブジェクトの作成および変更順序は、ソースデータベースと一貫しています。欠点: パフォーマンスは平均的です。
データベース名とテーブル名のハッシュ値に基づいて、データを個別のパーティションに転送	このポリシーは、データベース名とテーブル名を結合してパーティションキーとしてハッシュ計算に使用します。その後、各テーブルのデータと DDL 情報を宛先 Topic の異なるパーティションに配信します。説明同じテーブルのデータと DDL 情報は、同じパーティションに配信されます。 CREATE DATABASE のようなテーブルに関連しない DDL 情報は、パーティション 0 に配信されます。	利点: 単一テーブルの作成および変更順序はソースと一貫しています。パフォーマンスは良好です。欠点: テーブルが異なるパーティションに配信されるため、異なるテーブル間の操作順序は保証されません。
完全データおよび増分 Redis データを異なるパーティションに配信	このポリシーは、Redis インスタンスからの完全データと増分データを宛先 Topic の異なるパーティションに配信します。	利点: Redis インスタンスからのデータを異なるパーティションに配信できます。欠点: 同じキーのデータが異なるパーティションに現れる可能性があります。パフォーマンスは平均的です。
主キーのハッシュ値に基づいて、データを個別のパーティションに転送	このポリシーは、テーブルのカラムをパーティションキーとして使用してハッシュ値を計算します。デフォルトでは、プライマリキーが使用されます。テーブルにプライマリキーがない場合は、ユニークキーが使用されます。その後、このポリシーは異なる行を宛先 Topic のさまざまなパーティションに配信します。単一または複数のカラムをパーティションキーとして指定することもできます。説明このポリシーでは、DDL 情報はデフォルトで宛先 Topic のパーティション 0 に配信されます。テーブルにプライマリキーまたはユニークキーがない場合、DTS はそのデータと DDL 情報を宛先 Topic のパーティション 0 に配信します。	利点: このポリシーは最高のパフォーマンスを提供します。欠点: このポリシーは単一レコードの変更順序のみを保証します。プライマリキーのないテーブルや複数のテーブル間の操作順序は保証されません。
[Redis キーのハッシュに基づいてパーティションに配信]	このポリシーは、Redis インスタンスのキーをパーティションキーとして使用してハッシュ値を計算します。その後、完全データと増分データを宛先 Topic の異なるパーティションに配信します。	利点: Redis インスタンスからのデータを異なるパーティションに配信できます。欠点: 同じキーのデータが異なるパーティションに現れる可能性があります。パフォーマンスは平均的です。

ソースデータベースが Tair/Redis の場合

ポリシー名	説明	利点と欠点
すべてのデータをパーティション 0 に転送	すべてのデータと DDL 情報を宛先 Topic のパーティション 0 に配信します。	利点: オブジェクトの作成および変更順序は、ソースデータベースと一致します。欠点: パフォーマンスは平均的です。
完全な Redis データと増分データを異なるパーティションに配信する	Redis インスタンスからの完全データと増分データを宛先 Topic の異なるパーティションに配信します。	利点: Redis インスタンスからのデータは複数のパーティションに分散されます。欠点: 同じキーのデータが異なるパーティションに現れる可能性があります。パフォーマンスは平均的です。
Redis キーのハッシュ値に基づいて異なるパーティションに配信する	Redis キーをパーティションキーとして使用してハッシュ値を計算します。その後、完全データと増分データの両方を宛先 Topic の異なるパーティションに配信します。	利点: Redis インスタンスからのデータは複数のパーティションに分散されます。欠点: 同じキーのデータが異なるパーティションに現れる可能性があります。パフォーマンスは平均的です。

ソースデータベースが別のデータベースの場合

ポリシー名	説明	利点と欠点
すべてのデータをパーティション 0 に転送	すべてのデータと DDL 情報を宛先 Topic のパーティション 0 に配信します。	利点: オブジェクトの作成および変更順序は、ソースデータベースと一致します。欠点: パフォーマンスは平均的です。
データベース名とテーブル名のハッシュ値に基づいて、データを個別のパーティションに転送	データベース名とテーブル名をパーティションキーとして結合し、ハッシュ値を計算します。その後、各テーブルのデータと DDL 情報を宛先 Topic の異なるパーティションに配信します。説明同じテーブルのデータと DDL 情報は、同じパーティションに送られます。テーブルに関連しない DDL ステートメント (例: CREATE DATABASE) は、パーティション 0 に送られます。	利点: 単一テーブルの作成および変更順序はソースと一致します。パフォーマンスは良好です。欠点: 異なるテーブル間の相対順序は保証できません。
主キーのハッシュ値に基づいて、データを個別のパーティションに転送	テーブルカラム (デフォルトではプライマリキー。プライマリキーが存在しない場合はユニークキー) をパーティションキーとして使用してハッシュ値を計算します。その後、異なる行を宛先 Topic の異なるパーティションに配信します。単一または複数のカラムをパーティションキーとして指定することもできます。説明このポリシーでは、DDL 情報はデフォルトでパーティション 0 に配信されます。テーブルにプライマリキーもユニークキーもない場合、DTS はそのデータと DDL 情報の両方をパーティション 0 に配信します。	利点: このポリシーは最高のパフォーマンスを提供します。欠点: 単一レコードの変更順序のみが保証されます。プライマリキーのないテーブルや複数のテーブル間では順序は保証できません。