FlowingDev

UUIDs, erklärt: Die einzigartige ID, die niemandem auf die Füße tritt

Eine UUID ist eine 128-Bit-Zahl, die zur eindeutigen Identifizierung von Informationen in Computersystemen verwendet wird und praktisch garantiert, dass niemals zwei davon identisch sind.

Tool ausprobieren: UUID-Generator

In einem Satz

Eine UUID ist eine 128-Bit-Zahl, die als einzigartige Seriennummer für buchstäblich alles dient, was man sich in der Software vorstellen kann, mit einer lächerlich geringen Wahrscheinlichkeit, jemals doppelt erstellt zu werden.

Welches Problem es löst

In den Anfängen der Computerei war es einfach, den Überblick zu behalten. Dein erster User war die ID 1, dein zweiter die 2 und so weiter. Dieser „automatisch hochzählende Integer“ funktionierte super … solange du nur eine Datenbank und einen Server hattest, der alle Datensätze erstellte.

Und dann kam das Internet. Und verteilte Systeme. Und Microservices. Und Offline-First-Apps.

Plötzlich hatten mehrere Computer gleichzeitig das Bedürfnis, neue Dinge zu erstellen (User, Posts, Produkte, Log-Einträge), ohne miteinander zu reden. Wenn ein Server in Dublin und ein Server in Tokio beide versuchten, den „nächsten“ Datensatz zu erstellen, würden beide den Datensatz #5830 anlegen. Wenn ihre Datenbanken später synchronisiert würden, gäbe es eine Kollision. Welcher Datensatz ist der echte #5830? Das Chaos ist perfekt.

Das ist das Kernproblem, das UUIDs (Universally Unique Identifiers) lösen: dezentrale, unkoordinierte und einzigartige ID-Generierung. Ein Entwickler an einem Laptop in einem Café kann eine ID für ein neues To-do-Listenelement erstellen und statistisch sicher sein, dass niemand sonst, auf keinem anderen Computer, in der gesamten Geschichte und Zukunft des Universums, jemals genau dieselbe ID generieren wird. Dies ermöglicht es Systemen, unabhängig voneinander eindeutige Identifier zu erstellen und ebnet den Weg für die robuste, verteilte Software, auf die wir uns heute verlassen.

Wie es unter der Haube funktioniert

Im Grunde ist eine UUID nur eine große Zahl: 128 Bit lang. Das sind 2¹²⁸ mögliche Kombinationen, was ungefähr 340 Undezillionen entspricht (eine 3 gefolgt von 37 Nullen). Um das ins rechte Licht zu rücken: Wenn du eine Milliarde UUIDs pro Sekunde generieren würdest, bräuchtest du etwa 10 Milliarden Jahre, um alle Möglichkeiten auszuschöpfen. Die Chance, dass zwei zufällig generierte UUIDs jemals kollidieren, ist astronomisch klein.

Anatomie einer UUID

Obwohl es sich um einen 128-Bit-Integer handelt, sehen wir ihn nie so. Er wird fast immer als 32-stelliger hexadezimaler String dargestellt, der durch Bindestriche in fünf Gruppen unterteilt ist.

Eine typische UUID (Version 4) sieht so aus: 123e4567-e89b-42d3-a456-426614174000

Lass uns dieses Format mal auseinandernehmen:

  • Struktur: 8-4-4-4-12 (das sind 32 hexadezimale Zeichen, was insgesamt 36 Zeichen einschließlich der Bindestriche ergibt).
  • Daten: Jedes Hex-Zeichen repräsentiert 4 Bits (ein „Nibble“). 32 Zeichen * 4 Bits/Zeichen = 128 Bits.
  • Die magischen Zahlen: Siehst du die 4 am Anfang der dritten Gruppe (42d3)? Diese 4 ist nicht zufällig. Sie gibt die UUID-Version an (in diesem Fall Version 4). Das erste Zeichen der vierten Gruppe (a456) hat ebenfalls eine besondere Bedeutung; es identifiziert die Variante und stellt sicher, dass sie dem Standardlayout entspricht. Bei den meisten UUIDs, die du sehen wirst, ist es eine von 8, 9, A oder B.

Ein kleiner Rundgang durch die Versionen

Die Eingabeaufforderung für dieses Tool gibt Version 4 (v4) an, was der häufigste Typ ist. Aber es gibt mehrere Versionen, jede mit einer anderen Generierungsstrategie.

Version Generierungsmethode Anwendungsfall
v1 Zeitstempel + MAC-Adresse des erzeugenden Computers. Wenn du eine zeitbasierte Sortierung brauchst. (Wird heute selten verwendet, wegen Datenschutzbedenken durch die Offenlegung der MAC-Adresse).
v2 Wie v1, aber mit zusätzlichen POSIX UID/GID-Infos. Extrem selten. Eine Formalisierung von v1.
v3 MD5-Hash eines „Namespace“ und eines „Name“. Deterministisch. Bei gleichem Namespace und Name erhältst du immer dieselbe UUID. (Weniger verbreitet, da MD5 Schwächen hat).
v4 Reiner Zufall. Die Standardwahl. Wenn du einfach eine eindeutige ID brauchst und dich um nichts anderes scherst.
v5 SHA-1-Hash eines „Namespace“ und eines „Name“. Die moderne deterministische Wahl. Gleiche Idee wie v3, aber mit einer stärkeren Hash-Funktion.

Eine UUID der Version 4 generieren

Eine v4-UUID zu generieren ist konzeptionell einfach:

  1. Generiere 128 Bit an kryptografisch sicheren Zufallsdaten.
  2. Passe ein paar spezifische Bits an, um die Felder „Version“ und „Variante“ zu setzen, wie es der Standard vorschreibt.
  3. Formatiere die resultierenden 128 Bits als hexadezimalen String mit Bindestrichen.

Hier ist der Pseudocode für den „Anpassungs“-Schritt:

// Assuming `bits` is an array of 128 random bits (0s and 1s)

// Set the version to 4 (0100)
bits[48] = 0;
bits[49] = 1;
bits[50] = 0;
bits[51] = 0;

// Set the variant to '10x'
bits[64] = 1;
bits[65] = 0;

In der Praxis bieten die meisten Programmiersprachen eine Einzeiler-Funktion wie crypto.randomUUID(), die all dies für dich erledigt und sicherstellt, dass es korrekt und sicher geschieht. Das Wichtigste ist: Eine v4-UUID besteht aus 122 Bits reinem Zufall, verpackt in 6 Bits Metadaten.

Geschichten aus der Praxis

Der Albtraum bei der Datenbankfusion

Zwei Startups, „Acme“ und „WidgetCorp“, beschlossen zu fusionieren. Beide hatten erfolgreiche Produkte, jedes mit seiner eigenen Datenbank für User, Produkte und Bestellungen. Beim ersten Integrationsmeeting fragte ein Junior-Entwickler: „Wie sollen wir die User-Tabellen zusammenführen? Mein User mit der ID 101 ist ‚Alice‘, aber ihr User mit der ID 101 ist ‚Bob‘.“ Der Raum wurde still. Jede einzelne Tabelle in beiden Datenbanken verwendete einfache, automatisch hochzählende Integer-IDs. Sie zusammenzuführen wäre eine monumentale Aufgabe, bei der man Fremdschlüssel umschreiben, jeden Datensatz querverweisen und beten müsste, dass nichts übersehen wird. Es warf ihre Fusion um Monate zurück.

Lektion: Hätten sie von Anfang an UUIDs verwendet, wäre die Fusion trivial gewesen. Der User f47ac10b-58cc-4372-a567-0e02b2c3d479 von Acme könnte perfekt neben dem User 9c68a520-2a83-43a3-b45d-4c86518a28cc von WidgetCorp existieren. Keine Kollisionen, keine Albträume. UUIDs sind unerlässlich für Systeme, die eines Tages möglicherweise interagieren oder fusionieren müssen.

Der flotte Warenkorb

Ein Entwickler baute eine neue E-Commerce-Funktion zum schnellen Hinzufügen. Wenn ein User auf „In den Warenkorb“ bei einem Produkt klickte, erschien für 1–2 Sekunden ein Ladesymbol, während die App darauf wartete, dass der Server den Warenkorbartikel erstellte und seine neue ID zurückgab. Es fühlte sich träge an. Der Entwickler hatte einen Geistesblitz: Was, wenn die App nicht wartet? Er änderte den Code so, dass der Browser beim Klicken sofort eine v4-UUID für den neuen Warenkorbartikel generierte, ihn zum lokalen State hinzufügte und die Benutzeroberfläche augenblicklich aktualisierte. Die App fühlte sich blitzschnell an. Im Hintergrund schickte sie die Anfrage an den Server mit der Anweisung: „Bitte erstelle einen Warenkorbartikel mit genau dieser UUID.“ Wenn das Netzwerk ausfiel, konnte die App es einfach später erneut versuchen und dieselbe UUID verwenden, um doppelte Artikel zu vermeiden.

Lektion: Die clientseitige Generierung von UUIDs ermöglicht ein „Optimistic UI“, bei dem sich die Benutzeroberfläche sofort aktualisiert, in der Annahme, dass die Operation erfolgreich sein wird. Dies schafft eine viel schnellere, reaktionsfähigere User Experience und vereinfacht die Handhabung von Offline-Szenarien erheblich.

Die Microservice-Detektivgeschichte

Ein Kunde meldete einen Fehler: Seine Bestellung war fehlgeschlagen, aber seine Karte wurde trotzdem belastet. Das System war ein komplexes Netz aus Microservices: Auth, Gateway, Orders, Payments, Shipping. Eine einzige Anfrage konnte zwischen fünf oder sechs dieser Dienste hin- und herspringen. Den genauen Fehlerpunkt zu finden, war wie die Suche nach der Nadel im Heuhaufen bei einer Million Log-Einträgen pro Minute. Der leitende Architekt ordnete eine Änderung an: Jede einzelne eingehende Anfrage an das Gateway würde eine UUID erhalten, eine sogenannte „Correlation ID“. Diese ID würde an jeden Microservice weitergegeben, der die Anfrage bearbeitete, und jede einzelne Log-Nachricht würde sie enthalten. Als das nächste Mal ein Fehler auftrat, suchte das Support-Team einfach im Logging-System nach dieser einen UUID. Sofort hatten sie eine vollständige, chronologische Geschichte der Reise der Anfrage durch das gesamte System und konnten den genauen Dienst lokalisieren, der versagt hatte.

Lektion: UUIDs sind von unschätzbarem Wert als Korrelations-IDs, um Anfragen nachzuverfolgen und Fehler in verteilten und microservice-basierten Architekturen zu debuggen.

Häufige Fehler und Fallstricke

  • UUIDs als Primärschlüssel für Datenbanken verwenden … aber unvorsichtig. Obwohl sie für Einzigartigkeit großartig sind, sind UUIDs groß (16 Bytes im Vergleich zu 4 oder 8 für einen Integer) und zufällig. Zufälligkeit kann für die Performance von Datenbankindizes furchtbar sein und zu Fragmentierung und langsameren Schreibvorgängen führen, da die Datenbank sich abmüht, neue Zeilen mitten in einen Index-B-Tree einzufügen. Moderne Datenbanken und neuere UUID-Versionen (wie die vorgeschlagene v7, die zeitlich geordnet ist) können dies abmildern, aber es ist ein entscheidender Kompromiss, dessen man sich bewusst sein muss.
  • Annehmen, dass alle UUIDs zufällig sind. Ein Entwickler könnte eine UUID in einem Altsystem sehen und Logik darauf aufbauen, dass sie unvorhersehbar ist. Er oder sie realisiert vielleicht nicht, dass es sich um eine v1-UUID handelt, die einen Zeitstempel und die MAC-Adresse der Maschine enthält, die sie generiert hat, was potenziell sensible Informationen preisgeben kann.
  • Sie als irgendeinen String behandeln. Manche Entwickler denken vielleicht, jeder einzigartige String sei eine „UUID“. Sie könnten "product-123" verwenden oder eine ID mit einem schwachen Zufallszahlengenerator erzeugen. Echte UUIDs halten sich an ein strenges Format und sollten für v4 mit einer kryptografisch sicheren Zufallsquelle generiert werden, um Einzigartigkeit zu garantieren.
  • Die falsche Version für den Job verwenden. Ein häufiger Fehler ist die Verwendung einer v4 (zufälligen) UUID, wenn eine deterministische benötigt wird. Wenn du zum Beispiel eine eindeutige ID für eine Datei basierend auf ihrem Inhalt generieren musst, solltest du eine v5-UUID mit dem Hash der Datei als „Name“ verwenden. Dies stellt sicher, dass du, wenn du dieselbe Datei erneut antriffst, genau dieselbe UUID generierst, was eine einfache Deduplizierung ermöglicht.

Warum du das auf dem Schirm haben solltest

Du solltest immer dann zu einem UUID-Generator greifen, wenn du in einer Situation bist, in der:

  • du einen einzigartigen Identifier erstellen musst, dich aber nicht auf eine zentrale Instanz (wie eine einzelne Datenbanksequenz) verlassen kannst.
  • du ein verteiltes System, einen Microservice oder eine Anwendung baust, bei der mehrere Instanzen unabhängig voneinander Daten erstellen müssen.
  • du einzigartige IDs clientseitig (in einem Browser oder einer mobilen App) für Optimistic UI-Updates oder Offline-Fähigkeiten generieren möchtest.
  • du Korrelations-IDs erstellen musst, um Anfragen zu verfolgen, während sie durch mehrere Systeme fließen.
  • du einen Primärschlüssel für eine Datenbanktabelle wählst und globale Einzigartigkeit über die reine Einfüge-Performance stellst (und die Kompromisse bedacht hast).

In der modernen Softwareentwicklung sind diese Szenarien die Regel, nicht die Ausnahme. Zu wissen, wann und wie man UUIDs verwendet, ist eine grundlegende Fähigkeit.

Tauche tiefer ein

Theorie erledigt. Zeit, loszulegen — 100 % in deinem Browser.

Tool ausprobieren: UUID-Generator