UUID v7 – Aufbau und Funktionsweise
UUID v7 ist kein weiterer generischer Bezeichner, sondern ein spezifisches, standardisiertes Format (vorgesehen in RFC 9562), das einen 48‑Bit Unix‑Millisekunden‑Zeitstempel an den Anfang der ID setzt, gefolgt von kryptografisch starken Zufallsbits. Insgesamt ergibt das 128 Bit, die als 36‑Zeichen‑String dargestellt werden – zum Beispiel 018f3a6e‑d1c2‑7a3b‑8c4d‑5e6f7a8b9c0d. Die ersten 12 Zeichen (nach der üblichen Darstellung mit Bindestrichen) kodieren den Zeitstempel, die restlichen 24 Zeichen sind Zufall. Weil die Zeitinformation am Anfang steht, sind UUID‑v7‑IDs chronologisch sortierbar. Das unterscheidet sie fundamental von UUID v4, deren Bytes komplett zufällig verteilt sind.
Der Generator auf dieser Seite verwendet die browserinterne crypto.getRandomValues()‑Funktion, um den Zufallsanteil zu erzeugen. Kein Teil der ID verlässt den Rechner; alles wird lokal berechnet. Die Ausgabe kann in Grossbuchstaben (z. B. 018F3A6E‑D1C2‑7A3B‑8C4D‑5E6F7A8B9C0D) oder mit oder ohne Bindestriche (018f3a6ed1c27a3b8c4d5e6f7a8b9c0d) erfolgen. Die Standardform mit Bindestrichen und Kleinbuchstaben ist die maschinenlesbare Variante, während Grossbuchstaben manchmal in Logs oder für visuelle Lesbarkeit bevorzugt werden.
Warum zeitbasierte Sortierung die Datenbankindexierung verbessert
Datenbanksysteme speichern Primärschlüssel typischerweise in B‑Bäumen (B‑Trees). Wenn die Schlüssel zufällig über den gesamten Wertebereich verteilt sind – wie bei UUID v4 – führt das Einfügen eines neuen Datensatzes fast immer zu einem Seitensplit an einer beliebigen Stelle im Index. Das Fragmentiert den Index, erhöht die Anzahl der Festplattenzugriffe und verschlechtert die Performance von sequenziellen Scans.
UUID v7 löst dieses Problem, indem die ersten 48 Bit monoton mit der Zeit steigen. Neue IDs werden am rechten Rand des B‑Baums eingefügt – vergleichbar mit einem Auto‑Increment‑Integer, aber ohne die zentralisierte Serialisierung. Die räumliche Lokalität der Einfügungen verbessert die Cache‑Effizienz und reduziert die Indexfragmentierung drastisch. Messungen in Produktionssystemen zeigen, dass die Schreibrate bei Verwendung von UUID v7 um das Zwei‑ bis Fünffache steigen kann, je nach Datenbank und Workload.
Der Nachteil: IDs, die in derselben Millisekunde erzeugt werden, sind nicht strikt geordnet. Die Zufallsbits entscheiden über die relative Reihenfolge. Für Anwendungen, die eine garantiert streng chronologische Abfolge auch innerhalb einer Millisekunde benötigen, ist UUID v7 nicht geeignet – hier müsste man auf ULID (das einen sekundären Zähler einbaut) oder auf sequenzielle IDs setzen.
UUID v7 im Vergleich zu UUID v4, ULID und NanoID
| Eigenschaft | UUID v7 | UUID v4 | ULID | NanoID |
|---|---|---|---|---|
| Länge (String) | 36 Zeichen | 36 Zeichen | 26 Zeichen | 21 Zeichen (Standard) |
| Zeitstempel | 48 Bit (ms) | Keiner | 48 Bit (ms) + Zufall | Keiner (optional) |
| Sortierbar nach Zeit | Ja (ms‑genau) | Nein | Ja (ms‑genau) | Nein |
| Kryptografisch zufällig | Ja (122 Bit Zufall) | Ja (122 Bit Zufall) | Nein (nur 80 Bit Zufall) | Ja (abhängig von Parameter) |
| Standardkonform | RFC 9562 | RFC 4122 | Kein RFC | Kein RFC |
| Kollisionswahrscheinlichkeit | Sehr gering (< 10⁻¹⁸ bei 1 Mio. IDs) | Sehr gering (< 10⁻¹⁸ bei 1 Mio. IDs) | Gering (< 10⁻¹⁸ bei 1 Mio. IDs) | Abhängig von Länge, meist ausreichend |
Der entscheidende Unterschied zu UUID v4 ist die Zeitkomponente. Während v4 komplett zufällig ist, kombiniert v7 Zeit und Zufall – daher die bessere Indexlokalität. ULID wiederum ist kürzer und für eine bessere Lesbarkeit konzipiert (Crockford‑Base32), aber nicht RFC‑konform. NanoID ist extrem kurz, aber nicht sortierbar und benötigt eigene Implementierungen für zeitbasierte Varianten.
Der Generator auf dieser Seite bietet nur UUID v7 an – keinen Wechsel zu anderen Formaten. Das ist eine bewusste Entscheidung: Die Seite konzentriert sich auf einen einzigen, klar definierten Anwendungsfall.
Eingaben, Ausgaben und Verhalten des Generators im Detail
Der Generator bietet drei einstellbare Parameter:
- Anzahl (Count): Ganzzahl zwischen 1 und 100. Bei Änderung werden sofort neue IDs generiert.
- Grossbuchstaben (Uppercase): Schaltet zwischen Klein‑ und Grossbuchstaben um. Der Standard in RFC ist Kleinbuchstaben; Grossbuchstaben werden oft für manuelle Lesevorgänge verwendet.
- Bindestriche (Include hyphens): Schaltet die 4 Trennstriche in der Standarddarstellung ein oder aus. Ohne Bindestriche entsteht ein 32‑Zeichen‑Hex‑String, der weniger Platz beansprucht, aber die maschinelle Verarbeitung erschwert.
Jede Änderung an einem der drei Parameter löst eine sofortige Neuberechnung aus. Es gibt keinen „Generieren“‑Button – der Generator arbeitet reaktiv. Nach der Generierung erscheint der Status „Generated.“; beim Kopieren aller IDs wird „Copied all!“ angezeigt. Einzelne IDs lassen sich durch Anklicken in die Zwischenablage kopieren.
Der Status „Ready.“ zeigt an, dass das Tool geladen und bereit ist. Der Generator liefert immer eine konsistente Liste – nie teilweise Ergebnisse. Wenn die Anzahl 0 oder grösser 100 eingegeben wird, greift vermutlich eine clientseitige Validierung (das Fact Sheet erwähnt keine Fehlerbehandlung, aber 1‑100 ist der gültige Bereich).
Grenzen: Gleiche Millisekunde und Parallelität
UUID v7 garantiert keine strikte Ordnung für IDs, die innerhalb derselben Millisekunde erzeugt werden. Das liegt am Design: Die 48‑Bit‑Zeitstempel haben eine Auflösung von einer Millisekunde; danach folgen 74 weitere Zufallsbits (die für die Zufälligkeit reserviert sind). Wenn mehrere IDs in derselben Millisekunde generiert werden, bestimmt der Zufall die position. In einem verteilten System können zwei Knoten zur selben Millisekunde IDs erzeugen, deren Zeitstempel identisch sind, aber die Zufallsbits unterscheiden sich – die Sortierung nach dem vollständigen String ist dann nicht mehr chronologisch, sondern zufällig.
Für die meisten Anwendungen ist das akzeptabel. Wenn man aber z. B. Event‑Sourcing betreibt, bei dem die exakte Reihenfolge von Ereignissen innerhalb einer Millisekunde wichtig ist, muss man UUID v7 durch einen Zähler oder eine sequenzielle Nummer ergänzen. Alternativ verwenden manche Entwickler ULID, das einen 16‑Bit‑Zähler am Ende einbaut, der für monotone Ordnung innerhalb einer Millisekunde sorgt – allerdings auf Kosten von 16 weniger Zufallsbits und ohne RFC‑Standard.
Der Generator erzeugt alle IDs in demselben Browser‑Thread. Praktisch bedeutet das: Wenn man 100 IDs auf einmal anfordert, werden sie alle innerhalb einer Millisekunde generiert – sie haben denselben Zeitstempel und sind nur durch die Zufallsbits unterscheidbar. Das ist korrekt und beabsichtigt.
Lokale Generierung und Datenschutz
Alle Berechnungen laufen im Browser des Nutzers ab. Der crypto.getRandomValues()‑Aufruf erzeugt echte kryptografische Zufallszahlen, die von der Betriebssystem‑Entropiequelle gespeist werden. Es gibt keinen Netzwerkverkehr zum Server BroBroGo oder zu Dritten. Das ist besonders relevant für sicherheitskritische Anwendungen: Angreifer können keine IDs abfangen, und es entsteht kein Seitenkanal durch Serverlogs.
Die Anzahl der generierten IDs, die Grossbuchstaben‑Einstellung oder die Bindestrich‑Option werden lokal im JavaScript‑Zustand gehalten. Ein Seitenneuladen setzt alles zurück. Der Generator speichert keine Historie und kein Cookie.
Für Entwickler, die in air‑gapped Umgebungen arbeiten oder sensible Daten verarbeiten, ist dieser Ansatz ideal. Man kann die Seite als statische HTML‑Datei speichern und offline verwenden – die Generierung funktioniert dann weiter, da nur Browser‑APIs benötigt werden.
Typische Anwendungsfälle und Zielgruppen
UUID v7 eignet sich besonders für:
- Primärschlüssel in verteilten Datenbanken (z. B. CockroachDB, YugabyteDB, PostgreSQL mit UUID‑Spalten). Die zeitliche Ordnung verbessert die Schreibleistung und reduziert Vakuum‑ oder Optimierungsaufwand.
- Event‑Sourcing und Audit‑Trails: Ereignisse können nach Erstellungszeit sortiert werden, ohne dass ein separater Zeitstempel nötig ist.
- Messaging‑Systeme (z. B. Kafka‑Nachrichten‑IDs): Chronologische Ordnung hilft bei der Partitionierungslogik.
- APIs, die idempotente Schlüssel benötigen: Zeitbasierte IDs erlauben eine grobe Schätzung des Erstellungszeitpunkts – nützlich für Debugging.
- Sicherheits‑Tokenizer: Die 122‑Bit‑Zufallsanteil sind kryptografisch stark und praktisch nicht zu erraten.
Die Zielgruppe sind Entwickler, die bisher UUID v4 verwendet haben und wegen Indexfragmentierung auf eine zeitbasierte Variante umsteigen wollen, sowie Administratoren, die Datenbankmigrationen planen. Auch Ingenieure aus der Blockchain‑ oder IoT‑Welt, die eine Kombination aus Zeitordnung und Kollisionsresistenz brauchen, profitieren von UUID v7.
FAQ
1. Was ist der Unterschied zwischen UUID v7 und UUID v4?
UUID v4 ist vollständig zufällig – alle 128 Bit sind zufällig. UUID v7 setzt einen 48‑Bit‑Unix‑Millisekunden‑Zeitstempel an den Anfang; die restlichen Bits sind zufällig. Das macht v7 sortierbar nach Erstellungszeit und verbessert die Datenbankindex‑Performance.
2. Kann ich die Reihenfolge von UUIDs garantieren, die in derselben Millisekunde erstellt wurden?
Nein. UUID v7 hat keine Millisekunden‑interne Sortierung. IDs mit identischem Zeitstempel werden zufällig sortiert. Für streng monotone Ordnung innerhalb einer Millisekunde verwenden Sie ULID oder erweitern Sie UUID v7 um einen eigenen Zähler.
3. Ist die Generierung sicher? Werden meine Daten auf Ihren Server übertragen?
Die Generierung erfolgt ausschließlich im Browser mit crypto.getRandomValues(). Es werden keine Daten an BroBroGo oder andere Server gesendet. Sie können die Seite sogar offline nutzen.
4. Warum werden Grossbuchstaben und Bindestriche angeboten?
Grossbuchstaben sind für manuelle Lesevorgänge lesbarer. Auf manchen Systemen (z. B. Dateinamen) wird standardmässig Grossschreibung erwartet. Bindestriche gehören zum Standard‑UUID‑Format (8‑4‑4‑4‑12), können aber bei Speicher‑ oder Übertragungsoptimierung weggelassen werden.
5. Wie viele IDs kann ich auf einmal generieren?
Zwischen 1 und 100. Bei Änderung eines beliebigen Parameters werden sofort neue IDs generiert. Es gibt keinen „Generieren“‑Button; der Generator arbeitet reaktiv.
6. Ist UUID v7 ein offizieller Standard?
Ja. UUID v7 ist Teil des IETF‑Entwurfs RFC 9562 (New UUID Formats), der v7 als zeitbasierte Variante beschreibt. Der Standard ist noch nicht final, aber bereits weit verbreitet und implementiert (z. B. in Go, Python, Rust, Java).