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という名前のコネクターからの出力)を記述するものとして解釈されます。