Thema: schema
-
Protocol Buffers: Feldnummern, unbekannte Felder und die Regeln für die Weiterentwicklung einer Nachricht
In Protocol Buffers identifiziert die Feldnummer, nicht der Name, ein Feld auf der Leitung, weshalb Nummern nie geändert oder wiederverwendet werden dürfen; das Hinzufügen von Feldern ist unbedenklich, das Entfernen nur dann sicher, wenn die Nummer nie wiederverwendet wird (eine reserved-Anweisung erzwingt das), alte Leser behalten unbekannte Felder, und die Erweiterung von int32 zu int64 ist nur bedingt sicher. ProtoJSON hat eigene, davon abweichende Regeln.
-
Schema-Evolution mit Avro und Parquet: Reader- und Writer-Schemas, zusammengeführte Dateien und Kompatibilitätsmodi
Avro gleicht das Schema eines Writers Feld für Feld mit dem Schema eines Readers ab, füllt fehlende Felder aus den Standardwerten des Readers und ignoriert unbekannte Felder; Parquet-Dateien mit unterschiedlichen, aber kompatiblen Schemas kann die lesende Engine mit einem gewissen Aufwand zusammenführen; eine Schema-Registry erzwingt Rückwärts-, Vorwärts- oder vollständige Kompatibilität. Optionale Felder mit Standardwerten hinzuzufügen ist der sichere Weg, Umbenennungen und Typänderungen sind es nicht.
-
Schema-Registrys für Event-Streams: Subjects, Schema-IDs im Payload und Prüfungen bei der Registrierung
Eine Schema-Registry speichert versionierte Schemas pro Subject und erlaubt es Produzenten, statt des Schemas selbst nur eine kurze Schema-ID in jede Nachricht einzubetten; sie weist neue Versionen zurück, die den Kompatibilitätsmodus des Subjects verletzen, noch bevor eine Nachricht veröffentlicht wird. Die Subject-Namensstrategie und der Kompatibilitätsmodus ergeben sich daraus, wie Topics gemeinsam genutzt werden und in welcher Reihenfolge Clients ausgerollt werden.
Maschinenlesbar: JSON