UUID v4 vs. v7: Welchen eindeutigen Bezeichner wählen?

Ein UUID ist ein eindeutiger 128-Bit-Bezeichner ohne zentrale Koordination. Version 4, vollständig zufällig, dominiert seit Jahren. Version 7, neuer (RFC 9562, 2024), bindet einen Zeitstempel am Anfang ein, um zeitlich geordnete Bezeichner zu erzeugen. Dieser scheinbar harmlose Unterschied verändert die Datenbankleistung grundlegend. So wählen Sie den richtigen.

Was ist ein UUID?

Ein UUID (Universally Unique Identifier) ist eine 128-Bit-Zahl, dargestellt durch 32 Hexadezimalzeichen, gruppiert in fünf Blöcke, zum Beispiel 550e8400-e29b-41d4-a716-446655440000. Sein Daseinszweck: einen eindeutigen Bezeichner erzeugen, ohne eine zentrale Instanz zu befragen, was ihn ideal für verteilte Systeme macht. Sie können welche mit unserem UUID-Generator erzeugen.

Es gibt mehrere Versionen; die heute relevantesten für Datensatzschlüssel sind v4 (zufällig) und v7 (zeitlich geordnet).

UUID v4 (zufällig)

Der UUID v4 besteht aus 122 zufälligen Bits (der Rest codiert Version und Variante). Die Kollisionswahrscheinlichkeit ist so gering, dass sie in der Praxis vernachlässigbar ist. Es ist die Standardversion in den meisten Sprachen und Bibliotheken.

• Unvorhersehbar: perfekt für Token oder öffentliche Bezeichner, die nicht erratbar sein sollen
• Kein Informationsleck: verrät weder Datum noch Reihenfolge der Erstellung
• Nachteil: völlig ungeordnet, was die Datenbankindizes belastet

UUID v7 (zeitlich geordnet)

Der UUID v7 platziert einen Unix-Zeitstempel in Millisekunden auf seinen ersten 48 Bits, gefolgt von zufälligen Bits. Zwei zu verschiedenen Zeitpunkten erzeugte UUID v7 sortieren sich daher in der Reihenfolge ihrer Erstellung, bleiben dabei eindeutig und praktisch unmöglich zu erraten.

• Sortierbar: Die lexikografische Reihenfolge entspricht der chronologischen Reihenfolge
• Indexfreundlich: Die Einfügungen erfolgen am Ende des Index, wie bei einem Auto-Increment
• Kehrseite: Er verrät den Erstellungszeitpunkt, was für einen öffentlichen Bezeichner unerwünscht sein kann

Vergleichstabelle

Auswirkung auf Datenbanken

Das ist der Kern der Sache. Relationale Datenbanken speichern ihre Indizes in B-Bäumen (B-tree). Das Einfügen zufälliger Schlüssel (v4) verstreut die Schreibvorgänge überall im Index, was Fragmentierung, Seitenaufspaltungen und einen weniger effizienten Cache verursacht. Bei großen Datenmengen verschlechtert sich die Einfügeleistung deutlich.

Geordnete Schlüssel (v7) fügen sich immer am Ende des Index ein, wie ein auto-inkrementierter Bezeichner. Man erhält wieder schnelle Einfügungen, eine bessere Lokalität und einen kompakteren Index. Das ist besonders deutlich bei einem Primärschlüssel in InnoDB (MySQL), wo der Primärschlüssel die physische Reihenfolge der Zeilen bestimmt.

Wann das eine, wann das andere wählen

UUID v4 wählen, wenn

• der Bezeichner öffentlich sichtbar ist und nichts verraten darf
• Sie Token, Freigabelinks oder Geheimnisse erzeugen
• die Reihenfolge und das Erstellungsdatum nicht erratbar sein dürfen
• Sie maximale Kompatibilität mit dem Bestehenden wollen

UUID v7 wählen, wenn

• der UUID als Primärschlüssel in einer Datenbank dient
• das Einfügevolumen hoch ist und die Indexleistung zählt
• Sie nach Erstellungsreihenfolge sortieren wollen, ohne eigene Spalte
• das Verraten des Erstellungszeitpunkts kein Problem ist

Empfehlung

Für einen Datenbank-Primärschlüssel bevorzugen Sie künftig UUID v7: Sie behalten die verteilte Eindeutigkeit des UUID und vermeiden zugleich die Indexstrafe der v4. Behalten Sie UUID v4 für öffentliche Bezeichner, Token und Geheimnisse, bei denen die völlige Unvorhersehbarkeit und das Fehlen eines zeitlichen Lecks im Vordergrund stehen.

Prüfen Sie dennoch die Unterstützung von v7 in Ihrer Sprache und Ihrem ORM: Die RFC ist neu, aber die Verbreitung schreitet schnell voran.

Häufige Fragen