UUID-Versionen erklärt – Stoppen Sie, v4 überall zu verwenden

Ihr Code enthält wahrscheinlich eine Zeile, die so aussieht: id = uuid.v4(). Es funktioniert. Ihre Tests bestehen. Ihre Benutzer machen nie etwas gegen. Und jedes Mal, wenn die DBA den Abfrageplan sieht, brodelt sie innerlich.

UUID v4 wurde die Standardwahl, weil es einfach ist, universell verfügbar ist und ausreichend kollisionssicher ist, sodass Sie niemals tatsächlich einen Konflikt haben werden. Aber „es funktioniert“ und „es ist das richtige Werkzeug“ sind nicht dasselbe – und für Primärschlüssel macht v4 Ihr System bei Skalierung aktiv langsamer.

Was UUID v4 tatsächlich für Ihre Datenbank tut

Relationale Datenbanken verwenden B-Baum-Indizes für Primärschlüssel. Ein B-Baum hält die Daten sortiert, sodass die Datenbank Zeilen in O(log n) Zeit finden kann. Wenn Sie eine neue Zeile einfügen, muss die Datenbank sie an der richtigen sortierten Position im Index platzieren.

Mit UUID v4 ist jede neue ID zufällig. 550e8400-e29b-41d4-a716-446655440000 könnte von f47ac10b-58cc-4372-a567-0e02b2c3d479 – es gibt keine Beziehung zwischen aufeinanderfolgenden Einfügungen. Die Datenbank muss jedes Mal einen zufälligen Blattknoten im B-Baum finden.

Dies führt bei Skalierung zu zwei Problemen:

• Seitenspalten: Wenn eine Blattseite des B-Baums voll ist, muss die Datenbank sie in zwei Seiten aufteilen und den Elternknoten aktualisieren. Bei zufälligen Einfügungen treten Spaltungen häufig über das gesamte Index-System auf – nicht nur am Ende.
• Cache-Misses: Der Datenbankpufferspeicher hält häufig verwendete Seiten im Speicher. Sequenzielle Einfügungen treffen immer wieder die gleichen „heißen“ Seiten. Zufällige Einfügungen verteilen die Lesen über das gesamte Index, was den Cache ausbläst und Zwangsläufig auf Festplatte zugreift.

Bei einer Tabelle mit Millionen von Zeilen und hohem Schreibdurchsatz führt diese Indexfragmentierung zu echter Latenz. Wenn Ihr EXPLAIN ANALYZE zeigt, dass Indexabfragen länger dauern als sie sollten, könnte es an zufälligen UUIDs liegen.

Die UUID-Familie

UUID v1: Zeitstempel, MAC-Adressen und warum wir es nicht verwenden

UUID v1 war ursprünglich das „sortierbare“ UUID. Es kodiert einen 60-Bit-Timestamp in 100-Nanosekunden-Intervallen seit dem 15. Oktober 1582, kombiniert mit einer Uhrzeitfolge und der MAC-Adresse Ihres Geräts. Das Ergebnis ist grob nach der Zeit sortierbar.

Der MAC-Adresse-Teil ist das, was v1 getötet hat. Es gibt die Netzwerkschnittstellen-ID Ihres Servers in jedes generierte ID – in jedem Benutzer- oder Bestell- oder Ereignis-Record. Sicherheitsforscher zeigten, dass v1-UUIDs aus demselben Gerät vorhersagbar sind, sobald Sie ein Beispiel haben. Organisationen begannen, es für alles benutzerseitig zu vermeiden, und die meisten UUID-Bibliotheken markieren es als veraltet.

UUID v4: Zufällig, sicher und schlecht geeignet für Primärschlüssel

UUID v4 besteht aus 122 Bit kryptografisch zufälligen Daten (die verbleibenden Bits kodieren die Version). Die Wahrscheinlichkeit eines Kollisions bei einer Milliarde UUIDs beträgt etwa 1 von 10^18. Praktisch ist das null.

Diese Zufälligkeit ist genau das, was Sie für Sicherheitstoken, Sitzungs-IDs, API-Schlüssel und Korrelations-IDs benötigen – alles, wo ein ID nicht erraten oder aufgezählt werden kann. Für diese Anwendungsfälle behalten Sie v4 weiter. Das Problem ist, dass „nicht erraten werden kann“ und „datenbankfreundlich“ entgegengesetzte Eigenschaften sind.

Möchten Sie mit UUID-Generierung experimentieren? Der UUID-Generator auf IO Tools erlaubt es Ihnen, v1, v4, v7 und andere Varianten nebeneinander zu generieren, um den Unterschied in der Struktur zu sehen.

UUID v7: Die neue Standardwahl, die Sie verwenden sollten

UUID v7 wurde im Mai 2023 durch die IETF in RFC 9562 standardisiert. Es legt einen Unix-Timestamp in Millisekunden in den 48 höchstwertigen Bits, gefolgt von einem 4-Bit-Versionsfeld, einem 12-Bit-Sequenzzähler und 62 Bit zufälligen Daten.

Was dies in der Praxis bedeutet: Generierte UUIDs sind später lexicografisch größer. Aufeinanderfolgende Einfügungen landen in benachbarten Positionen im B-Baum. Keine zufällige Verteilung, keine unnötigen Seitenspalten, kein Cache-Verlust. Es verhält sich wie eine automatisch inkrementierte Ganzzahl aus der Datenbankperspektive – während es dennoch global eindeutig ist ohne Koordination.

Der Sequenzzähler innerhalb derselben Millisekunde sorgt für monotonen Aufbau selbst bei hochfrequenten Generatoren. Wenn Sie 10.000 UUIDs in einer Millisekunde generieren, werden sie immer noch korrekt sortiert. Der zufällige Nachteil behält genügend Entropie bei, sodass Kollisionen zwischen verteilten Systemen astronomisch unwahrscheinlich bleiben.

Für jedes neue System, das PostgreSQL, MySQL oder eine andere relationale Datenbank verwendet, sollte UUID v7 die Standardwahl für Primärschlüssel sein.

ULID: Die Alternative, die zuerst existierte

ULID (Universally Unique Lexicographically Sortable Identifier) löste das gleiche Problem vor der Existenz von UUID v7. Es verwendet 48 Bit für den Unix-Timestamp in Millisekunden und 80 Bit zufällige Daten, codiert in Crockfords Base32.

Das Ergebnis ist eine 26-Zeichen-String, der so aussieht: 01ARZ3NDEKTSV4RRFFQ69G5FAV anstatt der 36-Zeichen-hyphenierten UUID-Format. Es ist URL-sicher ohne Codierung, sortiert korrekt als String und ist fallunabhängig.

ULID hat keine IETF-RFC – es hat eine Community-Spezifikation auf ulid.github.io. Das reicht für die meisten Teams aus, aber wenn Sie in einem regulierten Umfeld sind, das formell standardisierte Identifikatoren erfordert, ist UUID v7 die sicherere Wahl. ULID hat starke Bibliothekenunterstützung in JavaScript- und Go-Ökosystemen, und wenn Ihr Team bereits auf ULID setzt, gibt es keinen dringenden Grund, zu wechseln.

Nebeneinander-Vergleich

Eigentum	UUID v1	Universally Unique Identifier (Version 4)	UUID v7	ULID
Sortierbar	Teilweise	NEIN	Ja	Ja
Kollisionssicher	Ja	Ja	Ja	Ja
Datenbankfreundlich	Teilweise	NEIN	Ja	Ja
Datenschutzsicher	Nein (MAC-Adresse)	Ja	Ja	Ja
Standardorganisation	IETF RFC 4122	IETF RFC 4122	IETF RFC 9562	Community-Spezifikation
Typische Länge	36 Zeichen	36 Zeichen	36 Zeichen	26 Zeichen
Entropiequelle	MAC + Uhrzeit	Zufällig	Timestamp + zufällig	Timestamp + zufällig

Wann jede Variante verwenden

UUID v7 – verwenden Sie dies für Primärschlüssel in jedem neuen System. Es ist eine IETF-Standard, hat wachsende Bibliothekenunterstützung (native in PostgreSQL 17, verfügbar über Bibliotheken in jeder Hauptsprache) und bietet Ihnen B-Baum-freundliche Ordnung ohne Koordination.

Universally Unique Identifier (Version 4) – behalten Sie dies für alles, wo Zufälligkeit wichtig ist: Sitzungs-Tokens, Passwort-Reset-Tokens, API-Schlüssel, OAuth-Statusparameter, Korrelations-IDs in Protokollen. Die Unvorhersehbarkeit ist hier ein Feature, nicht ein Bug.

ULID – verwenden Sie es, wenn Ihr Team bereits auf es setzt, besonders in JavaScript- oder Go-Projekten. Die kürzere Format ist tatsächlich besser in URLs und Protokollen. Wenn Sie von Grund auf neu beginnen, ist UUID v7 die sicherere langfristige Wahl, einfach weil es IETF-Unterstützung hat.

UUID v1 – nicht. Es gibt keine Situation, in der v1 die richtige Wahl für neues Code ist.

Übergangsbetrachtungen

Wenn Sie ein bestehendes System mit UUID v4-Primärschlüsseln laufen, brauchen Sie nicht sofort zu migrieren – und sollten es nicht ohne Vorsicht tun. Fremdschlüsselbeziehungen, Anwendungskode und möglicherweise abgespeicherte Werte beziehen sich auf diese IDs. Eine Migration erfordert sorgfältige Planung und wird wahrscheinlich ein Wartungsintervall benötigen.

Für die meisten Teams ist die pragmatische Herangehensweise: Verwenden Sie UUID v7 (oder ULID) für alle neuen Tabellen und Dienste. Akzeptieren Sie, dass Ihre Legacy-Tabellen v4 haben und die Fragmentierung mit periodischen Indexrebuilds verwalten, wenn die Leistung beeinträchtigt wird. Lassen Sie nicht perfekt das Gegenteil von gut sein.

Wenn Sie grün sind – neues Projekt, neues Datenbank, neue Tabellen – gibt es keinen Grund, v4 für Primärschlüssel zu wählen. Die Werkzeuge stehen zur Verfügung. Erzeugen Sie einige UUID v7-Proben und sehen Sie, worauf Sie arbeiten.

Das Fazit

UUID v4 ist nicht falsch – es wird nur häufig falsch angewendet. Ihre Zufälligkeit ist eine Sicherheitseigenschaft, und Sie sollten sie dort erhalten, wo Sicherheit wichtig ist. Für Primärschlüssel wird diese Zufälligkeit bei Skalierung zu einer Leistungsbelastung.

UUID v7 löst das Problem sauber: monoton wachsend, global eindeutig, standardisiert und bereits in den Datenbanken und ORMs, die Sie verwenden, unterstützt. Wenn Sie heute neue Datenbank-Schemata schreiben, machen Sie v7 Ihre Standardwahl. Zukunft-Ihre und Ihre DBA werden den Unterschied bemerken.

Das könnte Ihnen auch gefallen