Zusammenfassung

  • UUIDv7 legt Unix-Millisekunden in die ersten 48 Bits und verwendet die übrigen 74 nutzbaren Bits standardmäßig für Zufall oder optional für Zeitanteil und Zähler. Das macht eine Kennung sortierbar, nicht ein Geschehen beweisbar.
  • RFC 9562 erlaubt veränderte Zeitstempel und garantiert keine Nähe zur realen Zeit. Uhr-Rückläufe, Batch-Reihenfolge, Zählerzustand und Überlauf bleiben lokale Implementierungsaufgaben.
  • Eine belastbare Aussage verbindet die UUID mit Erzeugungs-, Zustandsübergangs-, Berechtigungs-, gegebenenfalls externen Zeit- und Wirkungsnachweisen.

Eine gute Indexeigenschaft ist keine Tatsachenfeststellung

RFC 9562 beschreibt UUIDv7 als 128-Bit-Kennung mit einem big-endian Unix-Zeitstempel in Millisekunden in den ersten 48 Bits. Nach Versions- und Variantenbits liegen rand_a und rand_b. Normalerweise liefern diese Felder Zufallsdaten. Falls innerhalb derselben Millisekunde zusätzliche Monotonie nötig ist, darf eine Implementierung dort in dieser Reihenfolge einen optionalen Submillisekundenanteil, einen sorgfältig gesetzten Zähler und verbleibende Zufallsdaten unterbringen.

Das ist eine sinnvolle Antwort auf ein Speicherproblem. UUIDv7 kann als Rohbytefolge oder Text lexikalisch sortiert werden; neue Schlüssel liegen dadurch oft nahe beieinander, statt wie vollständig zufällige Schlüssel über einen Index verteilt zu werden. RFC 9562 nennt genau diese Datenbanklokalität als Nutzen.

Aus der Lage eines Schlüssels im Index folgt jedoch nicht, dass die dazugehörige Handlung erfolgreich war. Ein Dienst kann eine UUID vor einer Validierung vergeben. Der anschließende Datenbankvorgang kann zurückrollen. Eine Outbox kann die Kennung erst später zustellen. Ein Empfänger kann sie erneut sehen und nur einmal anwenden. Die UUID verbindet diese Spuren hervorragend. Sie enthält nicht den Nachweis, welcher Übergang dauerhaft wurde, wer ihn autorisierte oder welches fremde System die Wirkung bestätigte.

Das sichtbare Millisekundenfeld trägt keine Uhrenhaftung

Die Spezifikation selbst setzt hier eine Grenze. Sie weist darauf hin, dass manuelle Anpassung oder Synchronisierungskorrekturen eine Systemuhr zurückstellen können und dass die Implementierung einen dazu passenden Umgang wählen muss. Ein gemeinsames Kennungsformat kann weder die Zeitquelle jedes Hosts noch dessen Überwachungs- und Korrekturpolitik entscheiden.

RFC 9562 geht weiter: Implementierungen dürfen den tatsächlichen Zeitstempel verändern. Als Gründe nennt der Text die Korrektur ungenauer Uhren, den Umgang mit Schaltsekunden und leistungsbezogene Umformungen. Für die Nähe des eingebetteten Werts zur realen Zeit gibt die RFC keine Anforderung und keine Garantie. Der Präfix einer UUIDv7 beschreibt folglich etwas über die Erzeugungspolitik, nicht unabhängig über den Zeitpunkt eines Sachverhalts.

Auch die Ordnung innerhalb einer Millisekunde ist keine Default-Zusage. Bei Zufallswerten ist die Byte-Reihenfolge nicht die Erzeugungsreihenfolge. Bei einem Zähler bestimmen dessen Länge, Initialisierung, Neustartzustand und Überlaufbehandlung das Ergebnis. RFC 9562 verlangt, dass Anwendungen einen Überlauf behandeln, um Sortierprobleme zu vermeiden, und empfiehlt Prüfungen, wenn eine neue zeitbasierte UUID nicht größer als die vorherige ist. Eine überzeugende Reihenfolge kann daher das Produkt sorgfältiger lokaler Arbeit sein; sie ist kein Grund, diese Arbeit aus dem Nachweis zu streichen.

Verteilte Erzeuger besitzen nicht automatisch ein gemeinsames Gedächtnis

Die Stärke einer UUID ist, dass sie nicht vor jeder Vergabe einen zentralen Dienst fragen muss. Zugleich hält RFC 9562 fest, dass echte globale Eindeutigkeit ohne ein Schema gemeinsamen Wissens nicht garantiert werden kann. Für viele Anwendungen reicht lokale Eindeutigkeit; UUID verlangt kein globales Register und keinen Sequencer.

Unabhängige Knoten können deshalb kompatible UUIDs aus unterschiedlichen Zeitquellen, Zählerzuständen und Wiederanlaufpfaden erzeugen. Der lexikalische Vergleich zweier Werte beweist nicht, dass ein Knoten den anderen beobachtet hat, dass eine Transaktion zuerst committed wurde oder dass eine Nachricht die spätere Wirkung verursachte. UUIDv7 ist weder eine Konsenslog-Position noch ein Kausalitätsbeweis über Hosts hinweg.

Die RFC rät zudem, UUIDs dort als opak zu behandeln, wo kein Parsing erforderlich ist. Das ist praktische Interoperabilitätsdisziplin. Ein auslesbarer Zeitanteil kann bei der Diagnose helfen. Ihm ohne weitere Unterlagen die Rolle eines revisionsfähigen Urteils zu geben, wäre eine zusätzliche, verantwortungspflichtige Entscheidung.

Die fünf Belege neben der UUID

UUIDv7 sollte als Verbindungsschlüssel dienen, während die maßgeblichen Behauptungen eigene Nachweise behalten.

  1. Erzeugungsnachweis: Generatorversion, Dienst oder Host, Zeitquelle, Präzision, Zählerpolitik, Neustart und Fehlerbehandlung.
  2. Übergangsnachweis: Validierung, dauerhafter Commit oder Rollback, Outbox-Veröffentlichung, Wiederholung, Idempotenz und Abgleich.
  3. Berechtigungsnachweis: menschliches oder technisches Principal, Delegation, Genehmigung, Regel und Reichweite.
  4. Externer Zeitnachweis: Wenn gegenüber Dritten gezeigt werden muss, dass Daten vor einem Zeitpunkt existierten, beschreibt RFC 3161 einen anderen Mechanismus. Eine Time-Stamp Authority signiert unter einer benannten Policy ein Token über den Datenabdruck; der Anforderer prüft Abdruck, Signatur, Zertifikat, Nonce oder Frische und die Eignung der Policy. Das belegt begrenzt die Existenz von Daten vor einer Zeit unter dieser Policy. Es belegt weder Autor, Berechtigung noch spätere Wirkung.
  5. Wirkungsnachweis: Das relevante Empfängersystem hält fest, ob es abgerechnet, konfiguriert, Zugriff gewährt, abgelehnt, kompensiert oder offen gelassen hat.

Als editorische Anwendung von Heng Lus Running-Code Primacy ist das keine Forderung nach einem großen Kontrollapparat. Die gemeinsame Spezifikation bleibt klein und transportabel. Der Code und Zustand, die tatsächlich erzeugt, committed, empfangen und angewandt haben, dürfen die attraktive Erzählung einer sortierten Spalte korrigieren. Wer die Bedeutung erweitert, muss den zusätzlichen Nachweis und das Risiko sichtbar übernehmen.

Quellen