UUIDv4 ist eine gute Standardwahl, wenn Sie eindeutige Identifikatoren benötigen, die unabhängig über verschiedene Dienste hinweg generiert werden können.
Das Problem ist nicht, dass UUIDv4 "falsch" ist. Das Problem ist, dass vollständig zufällige Identifikatoren eine schwächere Schreiblokalität aufweisen als sequenzielle oder zeitlich sortierte Identifikatoren, wenn sie in Indizes verwendet werden.
Das ist wichtig, sobald das Schreibvolumen ausreichend hoch ist.
Warum zufällige IDs das Indexverhalten verändern
PostgreSQL verwendet üblicherweise B-Baum-Indizes für Primärschlüssel.
Bei einem anhängenden Identifikator landen neue Zeilen typischerweise am Ende des Indexes. Bei einem zufälligen Identifikator wie UUIDv4 befinden sich die Einfügungen überall im Schlüsselraum.
Das kann zu Folgendem führen:
- mehr Seitenaufteilungen
- schlechtere Cache-Lokalität
- mehr Schreibverstärkung bei hoher Einfügelast
Das ist kein moralisches Versagen von UUIDv4. Es ist eine Folge der Zufälligkeit.
Wann Sie es bemerken
Viele Systeme werden sich nie darum kümmern.
Wenn die Tabelle bescheiden groß ist oder der Schreibdurchsatz moderat ist, ist UUIDv4 oft in Ordnung.
Sie beginnen, sich darum zu kümmern, wenn:
- die Tabelle groß ist
- Einfügungen häufig sind
- der Primärschlüssel auch das gruppierte Zugriffsverhalten für benachbarte Systeme darstellt
Das ist der Punkt, an dem zeitlich sortierte IDs attraktiv werden.
ULID und UUIDv7
ULID ist beliebt, weil es lexikografisch sortierbar und dennoch dezentralisiert ist. Es verbessert die Lokalität im Vergleich zu UUIDv4.
Heute verdient UUIDv7 auch ernsthafte Aufmerksamkeit, da es zeitlich sortierte UUIDs in einem standardisierten Format bereitstellt.
Das führt zu einer moderneren Faustregel:
- verwenden Sie UUIDv4, wenn Zufälligkeit in Ordnung ist und die Arbeitslast nicht empfindlich ist
- verwenden Sie ULID oder UUIDv7, wenn Indexlokalität und Reihenfolge von Bedeutung sind
Der Anwendungs-Kompromiss
Die Wahl des Identifikators ist nicht nur eine Datenbankentscheidung.
Sie wählen auch:
- Sortierverhalten
- Zeichenlänge und Kodierung
- Interoperabilität mit Bibliotheken und Datenbanken
- menschliche Lesbarkeit in Protokollen und URLs
Deshalb gibt es keinen universellen Gewinner.
Eine nützliche Empfehlung
Wenn Sie ein neues System starten und zeitlich sortierte Identifikatoren wünschen, ziehen Sie ein standardisiertes Format vor, wo immer dies möglich ist. Das bedeutet in der Regel, zuerst UUIDv7 zu evaluieren, wobei ULID immer noch eine pragmatische Option ist, wenn dessen Ökosystem besser zu Ihrem Stack passt.
Wenn Sie bereits UUIDv4 verwenden und die Datenbank gesund ist, migrieren Sie nicht nur, weil ein Blogbeitrag gesagt hat, dass zufällige IDs schlecht sind. Messen Sie zuerst die tatsächliche Arbeitslast.
Weiterführende Literatur