4.3.5. イベント
SQL Server コネクターによって生成されたすべてのデータ変更イベントにはキーと値がありますが、キーと値の構造は変更イベントの発生元となるテーブルによって異なります( Topic namesを参照)。
SQL Server コネクターは、すべての Kafka Connect スキーマ名が 有効な Avro スキーマ名 になるようにします。つまり、論理サーバー名はラテン文字またはアンダースコア(例:[a-z,A-Z,_])で開始し、スキーマおよびテーブル名の残りの文字(例:[a-z,A-Z,0-9,\_])で始まり、ラテン文字、数字、またはアンダースコア(例:[a-z,A-Z,0-9,\_])で始まる必要があります。そうでない場合は、すべての無効な文字が自動的にアンダースコア文字に置き換えられます。
これにより、論理サーバー名、スキーマ名、およびテーブル名に他の文字が含まれ、テーブルのフルネームを区別する唯一の文字が無効になり、アンダースコアに置き換えられたため、予期せぬ競合が発生する可能性があります。
Debezium および Kafka Connect はイベント メッセージの継続的なストリームに基づいて設計されており、これらのイベント の構造は時間の経過とともに変更される可能性があります。これは、コンシューマーが処理するのが困難な場合があるため、Kafka Connect を容易にすることで、各イベントを自己完結させることができます。すべてのメッセージキーと値には、スキーマ と ペイロード の 2 つの部分で設定されます。スキーマはペイロードの構造を記述しますが、ペイロードには実際のデータが含まれます。
4.3.5.1. イベントキーの変更 リンクのコピーリンクがクリップボードにコピーされました!
特定のテーブルでは、変更イベントのキーの構造には、イベントの作成時にテーブルのプライマリーキー(または一意のキー制約)の各列のフィールドが含まれます。
inventory データベースのスキーマ dbo で定義された customers テーブルについて考えてみましょう。
database.server.name 設定プロパティーの値が server1 の場合、この定義がある限り customers テーブルの変更イベントはすべて同じキー構造を特長とし、JSON では以下のようになります。
キーの スキーマ 部分には、キーの部分の内容を記述する Kafka Connect スキーマが含まれます。この場合、ペイロード 値はオプションではなく、server1.dbo.customers.Key という名前のスキーマによって定義された構造であり、タイプ int32 の id という名前の必須フィールドが 1 つあります。キーの payload フィールドの値を確認すると、id フィールドが 1 つあり、その値が 1004 である構造(JSON では単なるオブジェクト)になっていることがわかります。
そのため、このキーは、ID プライマリーキー列の値が 1004 である dbo.customers テーブルの行( server1という名前のコネクターからの出力)を記述するものとして解釈されます。