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 テーブルについて考えてみましょう。
CREATE TABLE customers ( id INTEGER IDENTITY(1001,1) NOT NULL PRIMARY KEY, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE );
database.server.name 設定プロパティーの値が server1 の場合、この定義がある限り customers テーブルの変更イベントはすべて同じキー構造を特長とし、JSON では以下のようになります。
{
"schema": {
"type": "struct",
"fields": [
{
"type": "int32",
"optional": false,
"field": "id"
}
],
"optional": false,
"name": "server1.dbo.customers.Key"
},
"payload": {
"id": 1004
}
}
キーの スキーマ 部分には、キーの部分の内容を記述する Kafka Connect スキーマが含まれます。この場合、ペイロード 値はオプションではなく、server1.dbo.customers.Key という名前のスキーマによって定義された構造であり、タイプ int32 の id という名前の必須フィールドが 1 つあります。キーの payload フィールドの値を確認すると、id フィールドが 1 つあり、その値が 1004 である構造(JSON では単なるオブジェクト)になっていることがわかります。
そのため、このキーは、ID プライマリーキー列の値が 1004 である dbo.customers テーブルの行( server1という名前のコネクターからの出力)を記述するものとして解釈されます。
