Zusammenfassung

  • UUIDv7 beginnt mit einem 48-Bit-Unix-Zeitwert in Millisekunden. Die übrigen 74 verfügbaren Bits sind standardmäßig zufällig oder können optionale Submillisekundenpräzision und Zähler enthalten.
  • Reihenfolge innerhalb einer Millisekunde, Uhrenrücklauf, Zählerüberlauf und persistenter Zustand sind Entscheidungen des Generators. Ein Sortieren unabhängiger Knoten belegt keine Kausal- oder Commit-Reihenfolge.
  • Eine UUID identifiziert, authentifiziert und autorisiert aber nicht. Belastbare Systeme speichern Ereigniszeit, Generator, Kausalbezug, Commit-Position und prüfbare Quittung getrennt.

Der praktische Gewinn liegt im Index

UUIDv4 verteilt neue Schlüssel zufällig. Das unterstützt dezentrale Erzeugung, führt auf Datenbankindizes aber zu weit auseinanderliegenden Einfügepositionen. RFC 9562 führt zeitgeordnete Layouts ein, um Lokalität zu verbessern und eine Sortierung als undurchsichtige Bytefolge zu ermöglichen.

Bei UUIDv7 stehen die Millisekunden seit der Unix-Epoche ohne Schaltsekunden in den höchstwertigen 48 Bits. Danach folgen Version und Variante. 74 Bits bleiben für Zufall oder eine erlaubte Kombination aus Submillisekundenanteil, Zähler und Zufall. Der RFC empfiehlt v7 nach Möglichkeit anstelle von v1 oder v6.

Ein Wert aus einer späteren Millisekunde sortiert normalerweise hinter einem früheren. Zeitnahe Einfügungen landen näher beieinander. Das ist eine klare, überprüfbare Leistung.

Die Zeit stammt jedoch von Uhr und Richtlinie des Generators. Sie stammt weder von einem gemeinsamen Transaktionssequencer noch von einer Zeitstempelstelle oder einem Kausalgraphen. Sortierbarkeit erweitert die Autorität der Uhr nicht.

Eine Millisekunde hat mehrere zulässige Ordnungen

Ein schneller Dienst erzeugt viele UUIDs mit demselben Zeitpräfix. Gute Zufallsendungen machen Kollisionen unwahrscheinlich, bewahren aber nicht automatisch die Erzeugungsreihenfolge.

RFC 9562 beschreibt drei optionale Monotonieverfahren: einen festen Zähler in den höherwertigen Bits, einen zufällig gestarteten monotonen Zähler oder bis zu zwölf Bits zusätzliche Zeitpräzision. Weitere Bits können zufällig bleiben.

Zwei konforme Bibliotheken dürfen unterschiedlich wählen. Zwei Prozesse auf demselben Host können getrennte Zähler führen. Nach dem Zusammenführen entsteht durch Bytevergleich eine totale Ordnung; sie muss nicht der Start-, Abschluss-, Commit- oder Sichtbarkeitsreihenfolge der Vorgänge entsprechen.

Eindeutigkeit und Reihenfolge sind unterschiedliche Eigenschaften. Entropie begrenzt Kollisionen, ein Zähler ordnet einen Generator. Beides erzeugt keine Kausalität zwischen unabhängigen Schreibern.

Wenn die Uhr rückwärts springt

Manuelle Korrektur, Zeitsynchronisation, Wiederaufnahme einer virtuellen Maschine und Fehler können die Uhr zurückstellen. RFC 9562 überlässt dem Implementierer eine Reaktion passend zu seinen Anforderungen.

Wer Monotonie benötigt, soll jede neue UUID mit der vorherigen vergleichen. Ist sie nicht größer, kann der Generator den bisherigen Zeitwert behalten und den Zähler erhöhen, auf die Uhr warten, den eingebetteten Wert vorziehen oder einen Fehler melden.

Jede Wahl verändert die Aussage. Der alte Wert schützt lokale Ordnung, entfernt sich aber von der Gegenwart. Warten kostet Verfügbarkeit. Vorziehen schreibt absichtlich Zukunft. Ein Fehler verweigert die Kennung.

Der Standard gestattet außerdem Veränderung, Unschärfe und Glättung des Zeitwerts und garantiert keine Nähe zur tatsächlichen Zeit. Ausgelesene Millisekunden verraten daher nicht die angewandte Richtlinie.

Der Zustandsraum begrenzt die Garantie

Letzten Zeitwert, Zähler und Zufallszustand kann ein Generator stabil speichern. Nach einem Neustart hilft dies, oberhalb früherer Werte fortzufahren. Persistenz ist optional; ein Start wie bei einem neuen Batch bleibt zulässig, erhöht aber Kollisions- und Entropierisiko.

Eine Monotoniezusage braucht ihren Umfang: Thread, Prozess, Host, Cluster oder Region. Ein Containerzähler ordnet keinen Nachbarcontainer. Für eine monolithische Datenbank kann die Erzeugung durch die Datenbank selbst die beste Monotonie liefern.

Verteilte Knoten dürfen unabhängig generieren. Zufallsbits ersetzen keinen gemeinsamen Sequencer. Späteres Sortieren ist für Pagination und zeitliche Eingrenzung nützlich, schafft aber keine nachträgliche Commit-Reihenfolge.

NTP ist kein Kausalitätsprotokoll

NTP und die Empfehlungen aus RFC 8633 verbessern Zeitdienste. Sie versprechen weder perfekte Gleichheit aller Anwendungsuhren in jedem Moment noch drücken sie die Abhängigkeit zweier Aktionen aus.

Schreibt A einen Datensatz und sendet dann eine Nachricht an B, kann Uhrversatz Bs UUID vor As Wert platzieren. Ein Retry kann in einer anderen Lebenszyklusphase eine Kennung erhalten. Innerhalb derselben Millisekunde teilen die Knoten nicht zwingend dieselbe Endungsregel.

Stärkere Belege kommen aus der Anwendung: Bs Nachricht verweist auf A, eine Datenbank vergibt Commit-Positionen oder ein Journal stellt nach Annahme eine Quittung aus. UUIDv7 kann daneben als Schlüssel und Zeitindiz dienen.

Diese Grenze ist kein Mangelbericht. RFC 9562 standardisiert Kennungen und Erzeugungspraxis, nicht verteilten Konsens oder eine Weltuhr.

Aus Sortierkomfort wird schnell falsches Zeugnis

Ein Warehouse sortiert nach UUID und nennt die Ansicht „Ereignisreihenfolge“. Damit unterstellt es vergleichbare Uhren, gleiche Rücklaufpolitik, kompatible Millisekundenmethoden, Erzeugung am maßgeblichen Geschäftsschritt und das Fehlen von Vorab-Erzeugung, Retry oder historischem Import.

Eine UUID kann vollständig konform bleiben, obwohl eine Annahme falsch ist. Sie kann vor einer später zurückgerollten Transaktion, vor der Zustellung oder heute für ein altes Ereignis entstehen. Erlaubte Zeitunschärfe verändert ebenfalls ihre Nähe zur Realität.

Ein revisionsfähiges Modell trennt unveränderliche Kennung, Ereigniszeit und Quelle, Aufnahmezeit, Generator und Richtlinienversion, Kausalvorgänger sowie Commit- oder Quittungssequenz. Nicht jedes System braucht alle Felder, muss aber seine Behauptung benennen.

Bleibt nur UUIDv7, ist „ungefähre Reihenfolge nach Generatoruhr“ eine vertretbare Beschreibung. Einen Streit über das erste Handeln entscheidet sie nicht.

Eine Kennung ist kein Zutrittsrecht

RFC 9562 warnt davor, UUIDs für schwer erratbar zu halten, und verbietet ihren Einsatz als Sicherheitsfähigkeiten, deren Besitz Zugriff gewährt. Gute Zufallsbits in v7 ändern diese Grenze nicht.

Kollisionsresistenz, Unvorhersagbarkeit und Autorität sind verschieden. Entropie und CSPRNG helfen bei den ersten beiden; sie authentifizieren den Vorleger nicht und autorisieren keine Handlung.

Der Zeitwert kann Erzeugungsreihenfolge verraten, ein Zähler die Rate. RFC 4086 und RFC 8937 erklären, weshalb zufälliges Aussehen nicht automatisch Sicherheit ist.

Eine API muss den Akteur authentifizieren, die Aktion autorisieren und Integrität separat schützen. Eine formal richtige UUID beweist kein Eigentum.

Die konkrete Zusage prüfen

Für Indexlokalität wird die echte Datenbank gemessen. Für lokale monotone Pagination werden Generatorumfang, Millisekundenverfahren, persistenter Zustand und Rücklaufbehandlung dokumentiert.

Für verteiltes Audit gehören Ausgabestelle, Uhrquelle, Richtlinienversion und Lebenszyklusphase in den Datensatz. Kausalbezug und Commit-Position sind eigene Felder. Müssen Dritte vertrauen, braucht es eine prüfbare Quittung.

Tests umfassen Millisekunden-Bursts, Zählerende, Neustart, Zustandsverlust, Uhrsprünge, regionale Partition und Stream-Zusammenführung. Damit wird die wirkliche Zusage geprüft, nicht eine vermeintliche Magie der Versionszahl.

Quellen