Entwicklertools · UUID Generator
ULID, Snowflake, KSUID und UUIDv7: Sortierbare IDs im Vergleich
· Hintergrund
UUID Kryptographie Browser-APIs
Zufällige UUIDs werden nicht nach Erstellungszeit sortiert, daher setzen einige Formate zuerst einen Zeitstempel. In diesem Beitrag werden ULID, Snowflake, KSUID und UUIDv7 hinsichtlich Layout, Größe, Monotonie und Kompatibilität verglichen.
Zufällige IDs und der Index, der sie hasst – das Problem, das zeitlich geordnete Identifikatoren lösen
Zufällige v4-UUIDs verteilen Einfügepunkte über einen B-Tree-Primärschlüssel, wenn neue Datensätze eintreffen, was zu Seitenteilungen und Neuorganisationen führt. Einfügungen an zufälligen Positionen beeinträchtigen die Schreibleistung und erhöhen die Fragmentierung der Festplatte erheblich. Datenbanken mit hohem Durchsatz tolerieren diese Kosten – den Preis wirklich unabhängiger, unkoordinierter Identifikatoren –, aber die Kosten sind real. Wenn Sie UUIDs nach Erstellungszeit sortieren müssen, können Sie die Indexeigenschaften durch Hinzufügen eines Zeitstempelpräfixes erheblich verbessern. Es sind mehrere Formate entstanden: ULID, Snowflake, KSUID und RFC 9562 v7. Jeder geht unterschiedliche Kompromisse hinsichtlich der Größe (26 Zeichen bis 128 Bits), der Zeitstempelgenauigkeit (Sekunden bis Nanosekunden), der UUID-Kompatibilität und der Frage ein, ob die Koordination des ID-Generators eine Zentralisierung erfordert. Datenbank-Benchmarks zeigen, dass sich die Einfügungsleistung deutlich verbessert.
ULID – ein 48-Bit-Millisekunden-Zeitstempel plus 80 Zufallsbits in 26 Crockford-Base32-Zeichen, mit einer monotonen Option
ULID (Universally Unique Lexicographically Sortable Identifier) kodiert einen 48-Bit Millisekunden-Zeitstempel und 80-Bit zufällige Nutzlast in 26 Zeichen von Crockford base32. Die Textdarstellung wird korrekt in lexikografischer Reihenfolge sortiert, sodass ULIDs für Systeme geeignet sind, bei denen die Reihenfolge der Zeitstempel und die Lesbarkeit eine Rolle spielen – Protokollverarbeitung, verteilte Ablaufverfolgung, Mikrodienste, bei denen Bezeichner in der Ausgabe für Menschen leicht lesbar sein müssen. ULID bietet eine monotone Variante, bei der mehrere innerhalb derselben Millisekunde generierte Identifikatoren den Zufallsanteil erhöhen, anstatt sich zu wiederholen, wodurch sichergestellt wird, dass selbst schnelle ID-Bursts eine strenge Generierungsreihenfolge einhalten. Der Nachteil besteht darin, dass ULID keine UUID ist: Sie passt nicht in eine standardmäßige 128-Bit-UUID-Datenbankspalte ohne Codierungskonvertierung. Die ULID-Präzision deckt ungefähr 8925 Jahre ab.
Snowflake – 64-Bit-IDs aus einem Zeitstempel, einer Worker-ID und einer Sequenz sowie die dafür erforderliche Koordination
Snowflake ist ein 64-Bit-Identifikator, der ursprünglich von Twitter entwickelt wurde und als 41-Bit-Millisekunden-Zeitstempel, eine 10-Bit-Worker-ID und eine 12-Bit-Sequenznummer strukturiert ist. Der 41-Bit-Zeitstempel umfasst ungefähr 69 Jahre und läuft in 2106 über, was eine Epochenkoordinierung und Migrationsplanung erfordert. Die Worker-ID unterscheidet Bezeichner, die von verschiedenen Servern oder Prozessen generiert werden – jeder Snowflake-Generator muss seine eigene eindeutige Worker-ID kennen, ohne dass es zu Konflikten mit anderen kommt. Snowflake besteht aus 64 Bits statt 128, wodurch es halb so groß ist wie UUID, schneller zu indizieren ist und pro Kennung speichereffizienter ist. Die Sortierung erfolgt nach Zeit und Worker-ID, was nützlich ist, um Anfragen oder Protokolle nach Quelle weiterzuleiten. Der Nachteil ist betrieblicher Natur: Jedem Generator muss eine Worker-ID zugewiesen werden, und die Uhren müssen synchronisiert bleiben.
KSUID – ein Sekunden-Zeitstempel mit einer großen zufälligen Nutzlast, sortiert nach Bytes
KSUID (K-Sortable Unique Identifier) ist ein 128-Bit-Identifikator, der aus einem 32-Bit-Unix-Zweitzeitstempel und einer 96-Bit-Zufallsnutzlast besteht und normalerweise als 27 Base62-Zeichen codiert ist. Das Format ist in lexikografischer Reihenfolge sortierbar und der Zufallsanteil ist für seine Größe kryptografisch einwandfrei. KSUID ist weniger weit verbreitet als ULID oder Snowflake, bietet jedoch eine andere Semantik: Der Zeitstempel lässt sich leicht auf eine für Menschen lesbare Sekunde dekodieren (nützlich für Protokolle und Debugging), und der 96-Bit-Zufallsanteil ist groß genug, dass mehrere in derselben Sekunde generierte KSUIDs ohne Sequenzkoordinierung praktisch keine Duplikatwahrscheinlichkeit von Null haben. Im Gegensatz zu Snowflake erfordert KSUID keine Worker-ID-Koordinierung oder zentrale Zuweisung. KSUID arbeitet mit Sekunden statt mit Millisekunden, sodass mehrere IDs innerhalb einer Sekunde nach dem Zufallsprinzip sortiert werden, sofern Sie keine zusätzliche Logik implementieren.
UUIDv7 – die auf Standards basierende Antwort, die zu vorhandenen UUID-Spalten und Tools passt
RFC 9562 v7 ist ein 128-Bit-Bezeichner, der aus einem 48-Bit-Unix-Millisekunden-Zeitstempel, 12 Bits mit einer Genauigkeit unter einer Millisekunde (verwendbar als Sequenzzähler) und 62 Zufallsbits zusammen besteht. Es wird sowohl als lexikografische Zeichenfolge als auch als 128-Bit-Bytes in Datenbanken korrekt sortiert. Entscheidend ist, dass es sich um ein gültiges UUID handelt – es setzt das Versionsnibble auf 7 und die Variantenbits auf den RFC-9562-Standard, wodurch es mit jedem Tool, jeder Datenbankspalte und jeder API kompatibel ist, die UUIDs verarbeitet. Es ist keine Kodierungskonvertierung erforderlich und die vorhandene UUID-Infrastruktur erfordert keine Änderung. Wenn in derselben Millisekunde mehrere v7-Identifikatoren generiert werden, empfiehlt RFC 9562 die Verwendung des Submillisekundenfelds als monotonen Zähler anstelle von Zufallsbits. V7 stellt eine pragmatische Entscheidung dar, um die UUID-Kompatibilität aufrechtzuerhalten.
Monotonie innerhalb einer Millisekunde – wie jedes Format mit Bursts umgeht und warum es für die Bestellung von Garantien wichtig ist
Monotonie ist die Eigenschaft, dass, wenn zwei Ereignisse in beobachtbarer Reihenfolge auftreten, ihre IDs in derselben Reihenfolge verglichen werden. Bei einer Granularität auf Millisekundenebene treten auf moderner Hardware routinemäßig mehrere Ereignisse innerhalb desselben Takts auf, daher muss jedes sortierbare ID-Schema die Reihenfolge im Submillisekundenbereich korrekt verarbeiten. ULID bietet einen expliziten monotonen Modus, bei dem der Zufallsanteil inkrementiert statt randomisiert wird. Snowflake enthält eine 12-Bit-Sequenznummer, die innerhalb eines Millisekunden-Ticks erhöht wird. KSUID verfügt nicht über einen integrierten Mechanismus, sodass Ereignisse in Sekundenbruchteilen zufällig sortiert werden, sofern keine zusätzliche Logik hinzugefügt wird. RFC 9562 v7 empfiehlt die Verwendung des Submillisekundenfelds als monotonen Zähler. Wenn Ihr System Tausende von UUIDs pro Sekunde generiert, wirkt sich die Monotonie innerhalb einer Millisekunde erheblich auf die Abfragereihenfolge aus.
Was dies nicht abdeckt – Durchsatz-Benchmarks, die von Hardware und Sprache abhängen; Der Beitrag bleibt qualitativ
Durchsatz-Benchmarks und Leistungsdaten sind nicht enthalten, da sie stark von der Hardwarearchitektur, der Sprachimplementierung, der Datenbank-Engine und der Caching-Strategie abhängen. Die Leistungsmerkmale der Datenbank variieren erheblich, je nachdem, ob Sie zufällige Einfügungen, Bereichsabfragen, Index-Overhead oder den Gesamtdurchsatz unter realistischer Produktionslast messen. Der Beitrag bleibt qualitativ und vergleicht Formate konzeptionell anhand ihrer Designs, anstatt umgebungsspezifische Zahlen anzugeben, die irreführend sein könnten. Für eine Leistungsbewertung in der Praxis sind Tests in Ihrer eigenen Umgebung mit Ihrer eigenen Arbeitslast, Codebasis und betrieblichen Einschränkungen erforderlich. Das Benchmarking verschiedener ID-Formate ist eine wertvolle Übung.
Fazit: Kompatibilität entscheidet oft – der ToolAcre-Generator erzeugt zufällige UUIDs; Verwenden Sie die wohlgeformte Prüfung, um zu bestätigen, dass eine UUIDv7 aus Ihrer Bibliothek als UUID analysiert wird.
Die Kompatibilität entscheidet oft darüber, welches Format ausgewählt werden soll. Wenn Ihr Datenbankschema bereits UUID-Spalten erfordert, ist v7 die moderne Antwort auf Sortierbarkeit, ohne das UUID-Ökosystem zu verlassen. Beim Aufbau eines neuen Systems mit benutzerdefinierten ID-Typen bietet ULID kleinere Textdarstellungen und Vorteile bei der Präzision im Millisekundenbereich. Wenn Sie 64-Bit-Speicher benötigen und die Worker-ID-Koordination durch zentrale Zuweisung verwalten können, ist Snowflake eine bewährte Wahl für Systeme mit hohem Volumen. Der grundlegende Kompromiss besteht zwischen Standardkompatibilität (wählen Sie v7) und alternativen Eigenschaften wie kleinerer Größe (Snowflake) oder Base32-Lesbarkeit (ULID). Treffen Sie Entscheidungen basierend auf Systembeschränkungen und Ökosystementscheidungen.