Schemaevolution, Migrationen und Kompatibilität

Warum sich Schemas weiterentwickeln müssen, ohne die Welt anzuhalten

Alle gespeicherten oder übertragenen Daten haben ein Schema: die Tabellen und Spaltentypen einer Datenbank, die Felder einer JSON-API-Antwort, die Datensatzdefinition eines Events in einem Stream. Schemas ändern sich ständig, weil sich das Geschäft ändert: Die Bank führt einen zweiten Kontoinhaber ein, die Essenslieferplattform beginnt, Trinkgelder zu erfassen, eine Aufsichtsbehörde verlangt ein neues Feld. Die architektonische Frage lautet, wie man ein Schema ändert, während das System weiterläuft, obwohl die alte Form noch von Code, gespeicherten Daten und anderen Teams verwendet wird.

Drei Tatsachen machen das schwierig. Erstens laufen in jedem System, das ohne Ausfallzeit deployt wird, alte und neue Codeversionen nebeneinander: Ein Rolling Deployment ersetzt Instanzen nacheinander, ein Canary leitet einen kleinen Teil des Datenverkehrs an die neue Version, und ein Rollback holt die alte Version zurück. Jeder Schemazustand muss daher mit mindestens zwei Codeversionen funktionieren. Zweitens leben Daten länger als Code. Vor fünf Jahren geschriebene Zeilen, dauerhaft aufbewahrte Events in einem Log, in einer Queue wartende Nachrichten und Backups behalten alle die alte Form. Drittens werden Schemas gemeinsam genutzt: Eine Spalte wird von Berichten, Extraktionsjobs und manchmal anderen Services gelesen, und ein Event-Schema wird von Consumern gelesen, die der Producer vielleicht gar nicht kennt. Abschnitt 7.1 hat dafür plädiert, Daten hinter einer Schnittstelle zu besitzen; bei der Schemaevolution zahlt sich diese Disziplin aus, denn ein privates Schema lässt sich mit der Zustimmung eines einzigen Teams ändern.

Abwärts-, Aufwärts- und volle Kompatibilität

Kompatibilität wird über Leser und Schreiber definiert. Eine Änderung ist abwärtskompatibel, wenn Code mit dem neuen Schema Daten lesen kann, die mit dem alten geschrieben wurden. Ein optionales Feld mit Standardwert hinzuzufügen ist abwärtskompatibel: Der neue Leser setzt den Standardwert ein, wenn den alten Daten das Feld fehlt. Eine Änderung ist aufwärtskompatibel, wenn Code mit dem alten Schema Daten lesen kann, die mit dem neuen geschrieben wurden. Das setzt voraus, dass alte Leser Felder ignorieren, die sie nicht kennen; das ist die Disziplin des Tolerant Reader. Eine Änderung ist voll kompatibel, wenn sie beides ist; dann lassen sich Leser und Schreiber in beliebiger Reihenfolge aktualisieren.

Welche Richtung Sie brauchen, ergibt sich daraus, wer zuerst aktualisiert. Aktualisieren Consumer vor Producern (häufig, wenn ein Stream wenige Consumer hat, die Sie kontrollieren), brauchen Sie Abwärtskompatibilität. Aktualisieren Producer zuerst, was der übliche Fall bei einer Datenbank ist (neuer Code beginnt zu schreiben, bevor jeder Leser neu deployt wurde) und bei öffentlichen APIs, brauchen Sie Aufwärtskompatibilität. Wenn Sie die Reihenfolge nicht kontrollieren können oder beide Seiten zurückrollen müssen, streben Sie volle Kompatibilität an. Die Confluent Schema Registry prüft zum Beispiel standardmäßig Abwärtskompatibilität gegen die vorherige Version und bietet transitive Varianten, die gegen jede frühere Version prüfen; das ist wichtig, wenn Consumer alte Daten vom Anfang eines Logs erneut abspielen können.

Ein Wort der Warnung zur Begrifflichkeit. Im API-Design wird abwärtskompatibel oft locker im Sinne von bestehende Clients funktionieren weiter verwendet; in Begriffen von Lesern und Schreibern ist das Aufwärtskompatibilität für die Clients, die Ihre Antworten lesen, und Abwärtskompatibilität für die Anfragen, die Sie von ihnen lesen. Wenn eine Diskussion an dem Begriff hängt, fragen Sie, welche Seite sich ändert und welche Seite weiter funktionieren muss.

Expand and Contract: die zentrale Technik

Die meisten inkompatiblen Änderungen lassen sich in eine Folge kompatibler Änderungen zerlegen. Das Muster heißt Expand and Contract oder Parallel Change (Danilo Satos Beschreibung von 2014 auf martinfowler.com nennt die Phasen Expand, Migrate und Contract). Zuerst erweitern (Expand): die neue Struktur neben der alten hinzufügen, sodass alter und neuer Code funktionieren. Dann migrieren (Migrate): die Schreiber so ändern, dass sie beide pflegen, vorhandene Daten übertragen und die Leser nacheinander auf die neue Struktur umstellen. Schließlich zurückbauen (Contract): Sobald nichts mehr die alte Struktur nutzt, wird sie entfernt. Jeder Schritt wird separat deployt, jeder ist mit der Version davor kompatibel, und jeder lässt sich ohne Datenverlust zurückrollen.

Der Preis sind Zeit und vorübergehende Unordnung: Die Änderung erstreckt sich über mehrere Releases, und tage- oder wochenlang trägt das Schema beide Formen. Der Nutzen: Kein Release braucht jemals eine Ausfallzeit, kein Deployment muss teamübergreifend koordiniert werden, und jeder Schritt lässt sich anhalten. Scott Amblers und Pramod Sadalages Refactoring Databases (2006) katalogisiert Dutzende Datenbank-Refactorings, die auf derselben Idee beruhen, mit einer Übergangsphase, in der altes und neues Schema nebeneinander bestehen und von der Anwendung oder von Triggern synchron gehalten werden.

-- Migration V41 (expand): metadata-only change, no table rewrite in PostgreSQL 11+
SET lock_timeout = '3s';            -- fail fast rather than queue behind long queries
ALTER TABLE restaurants ADD COLUMN postal_code text;

-- Backfill job (run repeatedly by a script, not inside one big migration)
UPDATE restaurants
SET    postal_code = postcode
WHERE  id >= :from_id AND id < :from_id + 5000   -- one small batch per transaction
AND    postal_code IS DISTINCT FROM postcode;

-- Verify before switching reads
SELECT count(*) FROM restaurants WHERE postal_code IS DISTINCT FROM postcode;  -- expect 0

-- Migration V44: enforce NOT NULL without a long blocking scan
ALTER TABLE restaurants ADD CONSTRAINT postal_code_nn CHECK (postal_code IS NOT NULL) NOT VALID;
ALTER TABLE restaurants VALIDATE CONSTRAINT postal_code_nn;  -- scans, but allows writes
ALTER TABLE restaurants ALTER COLUMN postal_code SET NOT NULL;  -- PostgreSQL 12+: uses the check, skips scan
ALTER TABLE restaurants DROP CONSTRAINT postal_code_nn;

-- Migration V45 (contract), weeks later, once nothing reads postcode
ALTER TABLE restaurants DROP COLUMN postcode;

Migrationen als Code in der Delivery-Pipeline

Datenbankänderungen gehören in die Versionsverwaltung neben den Anwendungscode, als geordnete Folge von Migrationen, jede ein kleines Skript, das das Schema von einer Version zur nächsten bringt. Pramod Sadalages und Martin Fowlers Evolutionary Database Design (erstmals 2003 veröffentlicht, 2016 neu geschrieben) hat die Praxis beschrieben, und die Werkzeuge sind ausgereift. Flyway führt versionierte SQL-Dateien wie V41__add_postal_code.sql der Reihe nach aus und verzeichnet jede in einer Tabelle flyway_schema_history. Liquibase beschreibt Änderungen als Changesets in SQL, XML, YAML oder JSON, erfasst in einer Tabelle DATABASECHANGELOG. Alembic für Python und SQLAlchemy erzeugt Revisionsskripte mit den Funktionen upgrade() und downgrade() und hält die aktuelle Revision in alembic_version fest. Flyway und Liquibase speichern außerdem eine Prüfsumme jeder angewendeten Migration und brechen mit einem Fehler ab, wenn eine davon nachträglich bearbeitet wurde; das schützt Umgebungen davor, unbemerkt auseinanderzulaufen.

In einer Continuous-Delivery-Pipeline laufen dieselben Migrationen in Tests gegen eine frische Datenbank, dann gegen Staging, dann gegen die Produktion, sodass die Produktion nie eine Änderung erhält, die nicht geprobt wurde. Gute Praxis ergänzt einige Regeln. Bearbeiten Sie nie eine Migration, die irgendwo angewendet wurde; schreiben Sie eine neue. Halten Sie Schemaänderungen und den davon abhängigen Code in getrennten Deployments, bei Erweiterungen die Schemaänderung zuerst, bei Rückbauten zuletzt. Testen Sie Migrationen gegen eine Kopie von Daten in Produktionsgröße, denn eine Anweisung, die auf einer Testdatenbank 50 ms dauert, kann eine große Tabelle eine Stunde lang sperren. Rollen Sie lieber mit einer neuen Migration vorwärts, statt Down-Migrationen zu nutzen, die Spalten und damit Daten löschen. Und lassen Sie sich von der Datenbank über Sperren informieren: In PostgreSQL blockiert ein ALTER TABLE, das auf seine Sperre wartet, jede danach eintreffende Abfrage; setzen Sie also ein kurzes lock_timeout und versuchen Sie es erneut, statt sich hinter einem lang laufenden Bericht einzureihen.

Große Backfills und Online-Schemaänderungen

Ein Backfill füllt eine neue Spalte oder Tabelle für bestehende Zeilen. Als ein einziges UPDATE über 400 Millionen Transaktionen hält er stundenlang Sperren, erzeugt riesige Mengen Write-Ahead-Log, die Replikate nachspielen müssen (was Replikationsverzögerung verursacht), und hinterlässt in PostgreSQL tote Zeilenversionen, die Vacuum aufräumen muss. Der professionelle Ansatz ist ein separater, neu startbarer Job, der kleine Batches nach Primärschlüsselbereich verarbeitet, jeden Batch committet, seinen Fortschritt festhält, sich drosselt, wenn Replikationsverzögerung oder Datenbanklast steigen, und idempotent ist, sodass ein erneut ausgeführter Batch keinen Schaden anrichtet. Führen Sie ihn außerhalb des Migrationswerkzeugs aus, damit ein Deployment nie auf ihn wartet.

Manche Änderungen lassen sich nicht ohne Sperren an Ort und Stelle vornehmen. PostgreSQL bietet CREATE INDEX CONCURRENTLY (das nicht innerhalb eines Transaktionsblocks laufen kann, was man Migrationswerkzeugen mitteilen muss) und die oben gezeigte Abfolge NOT VALID, dann VALIDATE CONSTRAINT. Für MySQL bauen Werkzeuge wie gh-ost und pt-online-schema-change eine Schattenkopie der Tabelle mit dem neuen Schema, halten sie mit laufenden Schreibvorgängen synchron und tauschen sie mit einer kurzen Umbenennung ein. Den Typ einer Spalte ändert man meist am besten per Expand and Contract auf eine neue Spalte statt mit einem ALTER an Ort und Stelle, das in den meisten Datenbanken die ganze Tabelle neu schreibt.

Schema Registries, Avro und Protocol Buffers

Für Events und Nachrichten entspricht dem Migrationswerkzeug eine Schema Registry. Producer registrieren jede Schemaversion; die Registry prüft sie gegen die konfigurierte Kompatibilitätsregel und weist eine inkompatible Änderung beim Build oder Deployment zurück statt erst in der Produktion. Jede Nachricht trägt eine kurze Schemakennung, sodass Consumer genau das Schema abrufen können, mit dem sie geschrieben wurde.

Apache Avro macht das Schema des Schreibers explizit: Zum Dekodieren braucht man sowohl das Schema des Schreibers als auch das des Lesers, und Avros Auflösungsregeln ordnen Felder über den Namen zu, ignorieren Felder des Schreibers, die der Leser nicht kennt, und füllen Leserfelder, die in den Daten fehlen, mit ihren deklarierten Standardwerten. Daraus folgt die praktische Regel: Geben Sie jedem Feld, das Sie hinzufügen oder entfernen könnten, einen Standardwert. Im Beispiel unten wurden currency und tip_pence in späteren Versionen mit Standardwerten hinzugefügt, sodass alte Events mit neuen Consumern weiterhin dekodiert werden.

Protocol Buffers identifizieren Felder auf dem Übertragungsweg über ihre Nummer, nicht über den Namen. Felder hinzuzufügen ist sicher, und alte Leser behalten unbekannte Felder beim erneuten Serialisieren. Das Umbenennen eines Felds wirkt sich nicht auf die binäre Kodierung aus (wohl aber auf die JSON-Form). Die obersten Regeln lauten, eine Feldnummer nie zu ändern oder wiederzuverwenden und die Nummern und Namen gelöschter Felder als reserved zu markieren, damit niemand sie versehentlich wiederverwendet. Confluent empfiehlt für Protobuf rückwärts-transitive Kompatibilität (backward transitive), weil das Hinzufügen eines neuen Nachrichtentyps nicht aufwärtskompatibel ist. Auch JSON Schema lässt sich registrieren und prüfen, aber die Offenheit von JSON (ist eine unbekannte Eigenschaft erlaubt oder nicht?) macht die Kompatibilitätsregeln subtiler.

{
  "type": "record",
  "name": "OrderPlaced",
  "namespace": "food.orders.v1",
  "fields": [
    {"name": "order_id",       "type": "string"},
    {"name": "restaurant_id",  "type": "string"},
    {"name": "total_pence",    "type": "long"},
    {"name": "currency",       "type": "string", "default": "GBP"},
    {"name": "tip_pence",      "type": ["null", "long"], "default": null}
  ]
}

API- und Event-Schemas weiterentwickeln

APIs und Events folgen denselben Prinzipien mit anderen Werkzeugen. Bevorzugen Sie bei APIs additive Änderungen, verlangen Sie von Clients, dass sie Tolerant Reader sind, und heben Sie inkompatible Änderungen für eine neue Version auf, die neben der alten läuft, mit Nutzungsmonitoring, um zu sehen, wann die alte Version abgeschaltet werden kann (Abschnitt 6.5 behandelt Versionierungsansätze). Mit Consumer-Driven-Contract-Tests veröffentlicht jeder Consumer die Felder, auf die er sich tatsächlich verlässt, sodass der Provider weiß, welche Änderungen sicher sind.

Events sind schwieriger als APIs, weil sie gespeichert werden: Ein Consumer kann ein Topic von Anfang an erneut abspielen, und ein System mit Event-Sourcing (Abschnitt 7.5) baut seinen Zustand aus Events auf, die vor Jahren geschrieben wurden. Behandeln Sie ein veröffentlichtes Event-Schema als öffentlichen Vertrag, versionieren Sie es in der Registry, und wenn eine Änderung wirklich inkompatibel ist, veröffentlichen Sie für eine gewisse Zeit einen neuen Event-Typ oder ein neues Topic (OrderPlaced.v2) neben dem alten, statt das bestehende zu verändern. Abschnitt 6.4 behandelt das Event-Design allgemeiner.