4.4.6. イベント

MongoDB コネクターによって生成されたすべてのデータ変更イベントには、キーと値があります。

Debezium および Kafka Connect は、イベントメッセージの継続的なストリーム について設計されており、これらのイベントの構造は構造内で変更されたり、コネクターが変更したりした場合に、これらのイベントの構造が変わる可能性があります。これはコンシューマーによる対応が困難になる可能性があるため、Kafka Connect による各イベントの自己完結が非常に容易になります。各メッセージキーと値には、スキーマペイロード の 2 つの部分があります。スキーマはペイロードの構造を記述し、ペイロードには実際のデータが含まれます。

4.4.6.1. Change イベントのキー

指定のコレクションでは、変更イベントのキーに単一の id フィールドが含まれます。この値は、MongoDB 拡張 JSON シリアル化から派生する文字列として表されるドキュメントの識別子です。論理名を持つコネクター(例: ドキュメント fulfillmentを含む inventory データベースを含むレプリカセット)について customers 考えてみましょう。

{
  "_id": 1004,
  "first_name": "Anne",
  "last_name": "Kretchmar",
  "email": "annek@noanswer.org"
}

customers コレクションのすべての変更イベントには、JSON で使用する同じキー構造が含まれています。

{
  "schema": {
    "type": "struct",
    "name": "fulfillment.inventory.customers.Key"
    "optional": false,
    "fields": [
      {
        "field": "id",
        "type": "string",
        "optional": false
      }
    ]
  },
  "payload": {
    "id": "1004"
  }
}

キーの schema 一部には、ペイロード部分に含まれる Kafka Connect スキーマが含まれます。この場合、payload 値はオプションではなく、という名前のスキーマによって定義される構造で fulfillment.inventory.customers.Keyid type という名前の必須フィールドが 1 つあることを意味し stringます。キーの payload フィールドの値を確認すると、値が整数を含む文字列である 1 つの id フィールドを持つ構造であることがわかります(JSON のオブジェクトはオブジェクト内) 1004

この例では整数識別子を持つドキュメントを使用していましたが、有効な MongoDB ドキュメント識別子(ドキュメントを含む)は機能します。ペイロードの id フィールドの値は、元のドキュメントの _id フィールドの MongoDB 拡張 JSON シリアル化(厳密モード)を表す文字列になります。以下のサンプルで、異なるタイプの _id フィールドがイベントキーのペイロードとしてエンコードされる方法を示しています。

MongoDB の _idキーのペイロード

整数

1234

{ "id" : "1234" }

float

12.34

{ "id" : "12.34" }

文字列

"1234"

{ "id" : "\"1234\"" }

ドキュメント

{ "hi" : "kafka", "nums" : [10.0, 100.0, 1000.0] }

{ "id" : "{\"hi\" : \"kafka\", \"nums\" : [10.0, 100.0, 1000.0]}" }

ObjectId

ObjectId("596e275826f08b2730779e1f")

{ "id" : "{\"$oid\" : \"596e275826f08b2730779e1f\"}" }

バイナリー

BinData("a2Fma2E=",0)

{ "id" : "{\"$binary\" : \"a2Fma2E=\", \"$type\" : \"00\"}" }