ULID – die bessere UUID (?)

Ich bin langjähriger Befürworter von UUIDs für Primärschlüssel in Datenbanken, aber trotzdem ständig auf der Suche nach effizienteren und innovativeren Lösungen. Daher freut es mich, hier eine bessere Variante der UUIDs vorzustellen, die Vorteile beider Welten kombiniert: die ULIDs!

In der NoSQL-Welt sind UUIDs als Primärschlüssel schon lange üblich. Der wesentliche Vorteil hier: Es gibt keine Probleme mit doppelten Primärschlüsseln bei der Replizierung oder Skalierung.

Aber auch bei relationalen Datenbanken gibt es einige Vorteile:

• UUIDs können von der Anwendung erstellt werden, ohne dass eine Sequenz ausgelesen werden muss. Das reduziert die Datenbankzugriffe.
• Jeder Datensatz in jeder Tabelle hat eine eindeutige ID. Eine UUID, die man in einem Log oder einem Kommentar findet, kann eindeutig einem Datensatz zugeordnet werden. Verwechslungen sind ausgeschlossen.
• Und auch hier gilt: Datensätze können einfach zwischen Datenbanken oder Tabellen kopiert und verschoben werden, ohne Gefahr zu laufen, doppelte Primärschlüsseln zu erhalten.

Es gibt aber auch ein paar wesentliche Nachteile von UUIDs als Primärschlüssel.

• UUIDs brauchen mit 16 Byte viel Speicherplatz. Int nur 4 Byte bzw. Bigint 8 Byte.
  Aber Speicher ist selten unser größtes Problem.
• Man kann nicht danach sortieren, um zu erfahren, in welcher Reihenfolge die Einträge angelegt wurden.
  Aber dafür hat man ja in der Regel einen Zeitstempel gespeichert.
• Performance Probleme bei Verwendung von „clustered indexes“.
  Und die können ganz gravierend werden, insbesondere wenn viele Datensätze geschrieben werden!

Ein Clustered Index ist ein Index, der die physische Reihenfolge der Datensätze in einer Tabelle beeinflusst. Er ordnet die Daten direkt in der physischen Reihenfolge des Index-Schlüssels und wird normalerweise auf einer eindeutigen ID-Spalte erstellt (PK oder unique FK, wenn es keinen PK gibt). Dadurch werden Abfragen beschleunigt. Der Index wird normalerweise mit einem B-Tree (Balanced Tree) erstellt.

UUIDs als Primärschlüssel in einem Clustered Index verlangsamen das Einfügen (CREATE) von Datensätzen, da neue Datensätze nicht einfach am Ende des Indexes hinzugefügt werden können, sondern aufgrund der Zufälligkeit der UUID an der richtigen Stelle im Index eingefügt werden müssen.

Das Konzept der ULIDs schlägt einen UUID-kompatiblen Datentyp (16 Byte) vor, der mit einem Zeitstempel beginnt und mit einer Zufallszahl endet. Dadurch sind ULIDs im Gegensatz zu UUIDs lexikografisch sortierbar.

Daher stammt auch der Name ULID, der die Abkürzung für Universally Unique Lexicographically Sortable Identifier ist.

01AN4Z07BY        79KA1307SR9X4MV3
|----------|      |----------------|
 Zeitstempel          Zufallswert
   48 Bits              80 Bits

Der Zeitstempel zählt die vergangenen Millisekunden seit dem 1. Januar 1970. Die 48 Bits reichen noch für die nächsten paar tausend Jahre.

Durch diese Methode ist schon mal sichergestellt, dass ULIDs, die mit einem zeitlichen Unterschied von min. 1 Millisekunde erstellt werden, richtig sortiert sind und einfach am Ende des Index hinzugefügt werden können.

Werden auf einem System in einer Millisekunde mehrere ULIDs erstellt, so können „monotone“ ULIDs verwendet werden. Bei dieser Art von ULIDs wird bei allen ULIDs, die in der selben Millisekunde erzeugt werden, einfach die letzte Stelle des Zufallswerts erhöht, anstatt dass er immer komplett neu berechnet wird:

01BX5ZZKBKACTAV9WEVGEMMVRY
01BX5ZZKBKACTAV9WEVGEMMVRZ
01BX5ZZKBKACTAV9WEVGEMMVS0
01BX5ZZKBKACTAV9WEVGEMMVS1

Ps.: ULIDs werden mit Crockford’s base32 dargestellt, können aber auch in eine UUID konvertiert und entsprechend dargestellt werden.

Hier sieht man schön, dass ULIDs (in Form von UUIDs in PostgreSQL) ähnlich beginnen, wenn sie zu einem ähnlichen Zeitpunkt erstellt wurden. Die ersten zwei Einträge wurden zum exakt selben Zeitpunkt erstellt, weshalb sich die UUIDs daher nur in der letzten Stelle unterscheiden (2->3).

Bei der Verwendung von UUIDs, insbesondere der Version 4 wo Zufallswerte verwendet werden, ist das Risiko von Kollisionen – also das Auftreten von zwei identischen UUIDs – extrem gering. In der Praxis wird dieses Risiko als so minimal angesehen, dass es vernachlässigt werden kann. Bei ULIDs, die ebenfalls auf Zufallsgenerierung basieren, ist das Kollisionsrisiko theoretisch etwas höher als bei UUIDs, aber dennoch immer noch so gering, dass es in den meisten Anwendungen ignoriert werden kann.

Interessiert an einem Beratungsgespräch?

Sprechen Sie uns an oder buchen Sie direkt einen Termin.

Jetzt Beratungstermin vereinbaren

Und wie nutze ich ULIDs in Java? Ganz einfach! Dafür gibt es bereits mehrere Bibliotheken, die einen Generator für ULIDs zur Verfügung stellen, wie zum Beispiel ulid-creator und ulid4j. In den folgenden Beispielen zeige ich, wie der ulid-creator verwendet werden kann.

Zuerst muss die Abhängigkeit ergänzt werden. Hier der Code für Maven bzw. Gradle:

<dependency>
  <groupId>com.github.f4b6a3</groupId>
  <artifactId>ulid-creator</artifactId>
  <version>5.2.0</version>
</dependency>

implementation group: 'com.github.f4b6a3', name: 'ulid-creator', version: '5.2.0'

Es sollte immer die neuste Version verwendet werden, die sich hier finden lässt: https://mvnrepository.com/artifact/com.github.f4b6a3/ulid-creator

Mit dem folgenden Code kann eine „monotone“ ULID generiert werden, was sich besonders beim Erstellen von großen Mengen Primärschlüssel anbietet:

final Ulid ulid = UlidCreator.getMonotonicUlid();

Außerdem können ULIDs auch basierend auf einer Zeichenkette erstellt werden. Das ist deterministisch, wodurch zum Beispiel geprüft werden kann, ob eine ULID für einen gewissen String erstellt wurde:

final var username = "JohnDoe";
final Ulid usernameUlid = UlidCreator.getHashUlid(time, userName);
 
// ....
 
// verify ULID belongs to John Doe
if(Arrays.equals(theUlidToCheck.getRandom(), usernameUlid.getRandom())) {
    // the random part of theUlidToCheck equals the random part of the JohnDoe ULID
}

Um ULIDs beispielsweise mit Hibernate und einer PostgreSQL Datenbank zu verwenden, kann als Primärschlüssel einfach eine UUID verwendet werden:

@Entity
public class Event implements Serializable {
    @Id
    @Column(name = 'event_id', unique = true, nullable = false)
    @Type(type = "org.hibernate.type.PostgresUUIDType")
    private UUID id;
 
    @Column(name = "creation_date")
    @CreationTimestamp
    private LocalDateTime creationDate;
 
    // ...
}

Beim Erzeugen der neuen Entitäten muss dann nur die ULID vor dem Persistieren generiert und als UUID gespeichert werden:

events.forEach(event -> event.setId(UlidCreator.getMonotonicUlid().toUuid()));
eventRepo.saveAll(events);

Das war’s schon!

Sie suchen einen Partner, der Ihre Digitalisierung realisiert?

Erfahren Sie, mit welchen Leistungen pep.digital Sie in Ihren Vorhaben unterstützen kann

Mehr über unsere Services erfahren

Während UUIDs ihre Vorteile haben und in manchen Situationen weiterhin eine gute Wahl sein können, bieten ULIDs dank ihrer lexicographischen Sortierbarkeit und ihrer Eindeutigkeit eine interessante Alternative, insbesondere für Systeme, die eine hohe Schreibdurchsatzrate aufweisen oder wo die Reihenfolge der Erstellung wichtig ist.

Für Projekte, die eine effiziente und dennoch eindeutige Identifikationsmethode benötigen, sind ULIDs definitiv eine Überlegung wert!

Seit der ursprünglichen Veröffentlichung dieses Artikels hat sich im Bereich der eindeutigen IDs einiges getan. Mit RFC 9562 wurde im Mai 2024 UUID Version 7 (UUIDv7) standardisiert. UUIDv7 ist eine zeitbasierte UUID‑Variante, die ähnlich wie ULID lexikographisch sortierbar ist und damit viele der beschriebenen Vorteile von ULIDs auch im offiziellen UUID‑Standard verfügbar macht.

UUIDv7 kombiniert einen Millisekunden‑Zeitstempel mit kryptographisch starken Zufallsbits und ist so aufgebaut, dass neu erzeugte IDs im Allgemeinen monoton ansteigen und sich gut für B‑Tree‑basierte Primärschlüssel eignen. Damit adressiert der neue UUID Standard endlich die Performance‑Probleme, die bei zufälligen UUIDv4 in clustered Indexes auftreten. ULIDs bleiben hingegen weiterhin interessant, wenn eine kompakte Base32‑kodierte ID benötigt wird (s.o., für Menschen besser lesbar) oder wenn bestehende Systeme bereits darauf setzen oder noch keine UUIDv7 unterstützen.

Eine UUIDv7 besteht aus 128 Bits, die wie folgt aufgeteilt sind:

48 Bit: UNIX‑Zeitstempel in Millisekunden (big‑endian)

4 Bit: Konstante 0111 (= Version 7)

12 Bit: Zufalls-/Entropie‑Bits oder monotone Sequenz

2 Bit: Konstante 10 für RFC‑konforme UUIDs

62 Bit: Zufalls-/Entropie‑Bits oder monotone Sequenz

Dadurch könnten zwei UUIDv7 die in der selben Millisekunde erzeugt wurden folgendermaßen aussehen:

019c23e9-ac08-71eb-aa5b-1234567890A1
|------------|-|--------------------|
 Zeitstempel  7  Zufallswert (mit Konstante s.o.)
   48 Bits            76 Bits

Werden die letzten Bits zufällig generiert, könnten zwei zur selben Millisekunde generierte UUIDv7 folgendermaßen aussehen:

019c23e9-ac08-71eb-aa5b-123457568795
019c23e9-ac08-71eb-aa5b-123424323120

Hier wurden die letzten Bits zufällig generiert – sie sind nicht aufsteigend.

Wird von der Implementierung des UUID-Generators jedoch eine monoton aufsteigende Reihenfolge garantiert, könnten die UUIDv7 so aussehen:

019c23e9-ac08-71eb-aa5b-123456789001
019c23e9-ac08-71eb-aa5b-123456789002

Hier sind jetzt nicht nur die ersten 48 Bits (Zeitstempel) streng aufsteigend, sondern auch die letzten 76 Bits.

UUIDv7 werden erst von wenigen Datenbanksystemen nativ unterstützt.

Mit PostgreSQL können UUIDv7 mit folgender Funktion erzeugt werden: uuidv7() (seit Version 18)

Mit MariaDB können UUIDv7 mit folgender Funktion erzeugt werden: UUID_v7() (seit Version 11.7)

Leider hat es die Unterstützung von UUIDv7 nicht in das Java 25 (LTS) Release geschafft. Mit Java 26 werden dann aber UUIDv7 nativ unterstützt und können folgendermaßen generiert werden.

final UUID uuidv7 = UUID.ofEpochMillis(System.currentTimeMillis());

Dabei werden allerdings die letzten Bits der UUID mit Zufallsdaten befüllt. Werden also mehrere UUIDs in derselben Milisekunde generiert, ist die Sortierung nicht monoton aufsteigend (wie z.B. bei ULIDs oder PostgreSQL). Daher sollte in einem solchen Fall die Generierung der UUIDv7 der (PostgreSQL) Datenbank überlassen werden, falls möglich.

Wenn UUIDv7 verwendet werden können, gibt es in vielen Systemen nur noch wenige Gründe, die für die Verwendung von ULIDs sprechen. Einer der Gründe ist die bessere, kompaktere Base32-Darstellung, die gerade in URLs oder Logs vorteilhaft sein kann.

Wenn UUIDv7 von Datenbank und Programmiersprache unterstützt werden, sollten Systeme, die viele Datensätze mit UUID PKs schreiben, in Zukunft auf UUIDv7 setzen.

ULIDs, so schön sie auch sind, werden damit vermutlich ein Nischenprodukt oder gar ein Auslaufartikel.