6.2. Debezium Oracle コネクターのデータ変更イベントの説明
Oracle コネクターが出力するデータ変更イベントはすべてキーと値を持ちます。キーと値の構造は、変更イベントの起点となるテーブルによって異なります。Debezium のトピック名を構築する方法は、トピック名を参照してください。
Debezium Oracle コネクターは、すべての Kafka Connect スキーマ名 が 有効な Avro スキーマ名 になるようにします。つまり、論理サーバー名はアルファベットまたはアンダースコア ([a-z、A-Z、_]) で始まり、論理サーバー名の残りの文字ならびにスキーマおよびテーブル名のすべての文字は英数字またはアンダースコア ([a-z、A-Z、0-9、_]) でなければなりません。コネクターは無効な文字をアンダースコア文字に自動的に置き換えます。
複数の論理サーバー名、スキーマ名、またはテーブル名を唯一区別する文字が無効な文字の場合、それらの文字がアンダースコアと置き換えられ、予期せぬ名前の競合が生じる場合があります。
Debezium および Kafka Connect は、イベントメッセージの継続的なストリーム を中心として設計されています。ただし、これらのイベントの構造は時間の経過とともに変化する可能性があり、トピックコンシューマーによる処理が困難になることがあります。ミュータブルなイベント構造の処理を容易にするために、Kafka Connect の各イベントが自己完結型になります。すべてのメッセージキーと値には、スキーマ と ペイロード の 2 つの部分があります。スキーマはペイロードの構造を記述しますが、ペイロードには実際のデータが含まれます。
SYS、SYSTEM、またはコネクターユーザーアカウント によって実行される変更は、コネクターによってキャプチャーされません。
以下のトピックでは、データ変更イベントの詳細を示しています。
6.2.1. Debezium Oracle コネクターの変更イベントのキー
変更されたそれぞれのテーブルについて、変更イベントキーは、イベントの作成時にテーブルのプライマリーキー (または一意なキー制約) の各列にフィールドが存在するように構成されます。
たとえば、インベントリー データベーススキーマに定義されている 顧客 テーブルには、以下の変更イベントキーが含まれる場合があります。
CREATE TABLE customers ( id NUMBER(9) GENERATED BY DEFAULT ON NULL AS IDENTITY (START WITH 1001) NOT NULL PRIMARY KEY, first_name VARCHAR2(255) NOT NULL, last_name VARCHAR2(255) NOT NULL, email VARCHAR2(255) NOT NULL UNIQUE );
database.server.name 設定プロパティーの値が server1 に設定されている場合は、データベースの お客様が 発生するすべての変更イベントの JSON 表現に以下のキー構造を特長としています。
{
"schema": {
"type": "struct",
"fields": [
{
"type": "int32",
"optional": false,
"field": "ID"
}
],
"optional": false,
"name": "server1.INVENTORY.CUSTOMERS.Key"
},
"payload": {
"ID": 1004
}
}
キー のスキーマ 部分には、キーの部分の内容を記述する Kafka Connect スキーマが含まれます。上記の例では、payload 値はオプションではありません。構造は server1.DEBEZIUM.CUSTOMERS.Key という名前のスキーマで定義され、タイプ int32 の id という名前の必須フィールドが 1 つあります。キーの payload フィールドの値は、1 つの id フィールドを持つ構造（JSON はオブジェクト）で、値が 1004 であることを示しています。
そのため、このキーを inventory.customers テーブル（id プライマリーキー列の値が 1004 である server 1） の行の説明のように解釈できます。
