DDLおよびスキーマの進化の処理

予想される順序

表定義の変更およびDDL取得が有効な場合、ストリームは、新しい定義を使用する後続のレコードの前に、DDLレコードを配信し、オブジェクト・メタデータおよび表固有のDMLスキーマを更新できます。WebSocketメッセージ間の正確なバッチ処理および順序は実装の詳細です。コンシューマは、スキーマまたはメタデータ・レコードが出現するたびに処理する必要があります。

• 表名のみでなく、スキーマをidでキャッシュします。

• オブジェクト・メタデータをqual_tableでキャッシュし、新しいレコードが到着したときに置換します。

• 接続時に受信したスキーマは、接続の存続期間中有効なままであると想定しないでください。

• 必要なスキーマが不明で、ダウンストリーム・システムがスキーマレス・データを受け入れることができない場合、DMLレコードを一時停止またはデッドレターします。

• ポリシーで許可される場所に互換性のある変更を自動的に適用し、互換性のない変更を制御された移行ワークフローにルーティングします。

互換性のある互換性のない変更

変更	一般的な消費者行動
NULL値可能列の追加	新しいフィールドを受け入れて、ダウンストリーム・スキーマを非同期または動的に更新します。
NULL以外の列の追加	レコードを適用する前に、デフォルト/バックフィル動作を確認します。
列の削除	フィールドの書込みを停止し、保存ポリシーに従って履歴ダウンストリーム・データを保持します。
列名の変更	それ以外の場合、制御されたマッピング状態でないかぎり、drop plus addとして扱います。
JSONプリミティブ型またはソース精度の変更	変換、精度およびダウンストリームの互換性を検証してから続行してください。
キー列の変更	新しいキーでレコードを使用する前に、べき等性、マージおよび削除ロジックを再構築します。

DDL処理ポリシー

• DDL pos、オブジェクト・アイデンティティ、文および操作のタイムスタンプを監査ログに記録します。

• その動作が明示的に承認され、保護されていないかぎり、レビューされていないソースDDLをダウンストリーム・システムに対して直接実行しないでください。

• 組織のDDLに十分な大きさのmaxDDLTextSizeを使用し、切捨てが検出または疑われる場合にアラートを使用します。

• 時間の経過とともに、同じ表に対して複数のスキーマ・バージョンが必要です。アーカイブされたイベントを含むスキーマ識別子を保持します。

スキーマ・レジストリの統合

コンシューマは、帯域内JSONスキーマ・レコードをエンタープライズ・スキーマ・レジストリに公開できます。元のidを保持し、履歴スキーマ定義を上書きするのではなく、データ・ストリームおよびデプロイメントとバージョン変更を関連付けます。レジストリはランタイム・スキーマを補完し、チェックポイントまたはソース・トレイルのリカバリは置き換えません。