Générateur ULID

Qu’est-ce qu’un ULID ?

Un ULID (Universally Unique Lexicographically Sortable Identifier) est un identifiant de 128 bits concu pour etre a la fois globalement unique et ordonne dans le temps. Cree par Alizain Feerasta en 2016, les ULID repondent a une limitation cle des UUID : les UUID aleatoires (v4) ne sont pas triables, ce qui cause des problemes de performance lorsqu’ils sont utilises comme cles primaires de base de donnees.

Un ULID encode un horodatage Unix en millisecondes dans ses bits les plus significatifs, suivi de donnees cryptographiquement aleatoires. Cela signifie que les ULID generes plus tard sont toujours lexicographiquement superieurs aux precedents — vous pouvez les trier comme des chaines de caracteres et obtenir l’ordre chronologique automatiquement.

Les ULID sont representes sous forme de chaines de 26 caracteres utilisant l’encodage Crockford Base32, ce qui les rend compatibles avec les URL, insensibles a la casse et plus compacts que le format UUID de 36 caracteres.

Structure d’un ULID

Un ULID fait 128 bits au total, divises en deux composants :

L’horodatage occupe les 48 premiers bits (10 caracteres Crockford Base32). Il stocke le nombre de millisecondes depuis l’epoque Unix (1er janvier 1970). Cela donne aux ULID une plage de validite jusqu’a environ l’an 10889.

La partie aleatoire occupe les 80 bits restants (16 caracteres). Lorsque plusieurs ULID sont generes dans la meme milliseconde, les implementations incrementent generalement la portion aleatoire de maniere monotone pour preserver l’ordre de tri au sein du meme horodatage.

Encodage Crockford Base32

Les ULID utilisent le Crockford Base32, un alphabet d’encodage concu par Douglas Crockford et optimise pour la lisibilite humaine :

0123456789ABCDEFGHJKMNPQRSTVWXYZ

Quatre lettres sont deliberement exclues :

• I — confondu avec 1 ou l
• L — confondu avec 1 ou I
• O — confondu avec 0
• U — peut former des mots vulgaires accidentels

Cela rend les ULID plus surs a lire a haute voix, a transcrire manuellement et a utiliser dans les URL. L’encodage est insensible a la casse, donc 01ARZ3NDEK et 01arz3ndek representent la meme valeur.

ULID vs UUID vs NANOID

Propriete	UUID v4	ULID	NANOID	UUID v7
Taille	128 bits	128 bits	Configurable (126 bits par defaut)	128 bits
Longueur texte	36 car.	26 car.	21 car. (par defaut)	36 car.
Encodage	Hex + tirets	Crockford Base32	Base64 URL-safe	Hex + tirets
Triable	Non	Oui (horodatage)	Non	Oui (horodatage)
Horodatage	Non	48 bits ms	Non	48 bits ms
Monotone	Non	Dans la meme ms	Non	Dans la meme ms
Standard	RFC 4122	Spec (communaute)	Spec (communaute)	RFC 9562
Ecosysteme	Universel	En croissance	Centre sur JavaScript	En croissance

Quand choisir ULID

Choisissez ULID lorsque vous avez besoin d’identifiants triables et compacts et que vous travaillez dans un environnement ou la specification ULID est bien supportee. Les ULID sont particulierement interessants pour :

• Event sourcing — Les evenements doivent etre ordonnes. Les horodatages ULID fournissent un ordre naturel sans numero de sequence separe.
• Bases de donnees distribuees — Cassandra, DynamoDB et d’autres systemes distribues beneficient de cles de partition ordonnees dans le temps qui evitent les points chauds.
• Files de messages — Les ULID comme identifiants de messages permettent aux consommateurs de traiter les messages dans un ordre approximativement chronologique.
• Agregation de logs — Lors de la fusion de logs provenant de plusieurs services, les identifiants de log bases sur ULID se trient correctement entre les sources.

Choisissez UUID v7 a la place si vous avez besoin d’une compatibilite maximale avec l’ecosysteme (des bibliotheques UUID existent dans tous les langages) et que le format de 36 caracteres est acceptable. UUID v7 offre le meme avantage d’ordonnancement temporel dans un format RFC standardise.

Choisissez NANOID si vous avez besoin de l’identifiant le plus court possible et que la triabilite n’est pas importante — par exemple, les raccourcisseurs d’URL ou les cles generees cote client ou la compacite est primordiale.

ULID monotones

Lors de la generation de plusieurs ULID dans la meme milliseconde, une implementation naive pourrait produire des identifiants avec des horodatages identiques et des parties aleatoires independantes — qui pourraient ne pas se trier dans l’ordre de generation. Les ULID monotones resolvent ce probleme en incrementant le composant aleatoire de 1 pour chaque ULID genere dans la meme milliseconde.

Cela garantit que meme la generation sub-milliseconde preserve un ordonnancement strict. La plupart des bibliotheques ULID de production implementent la generation monotone par defaut.

Le compromis est que les ULID monotones generes dans la meme milliseconde ont une legere correlation dans leurs portions aleatoires. En pratique, cela n’a aucun impact sur l’unicite — l’espace aleatoire de 80 bits est suffisamment vaste pour que meme les increments sequentiels au sein d’une seule milliseconde ne se chevauchent jamais entre differents generateurs.

Cas d’utilisation courants

• Cles primaires de base de donnees : Les ULID offrent l’unicite des UUID avec l’ordonnancement favorable aux index des entiers auto-incrementes
• Identifiants d’evenements dans les architectures evenementielles : L’ordonnancement chronologique naturel simplifie le rejeu d’evenements, le debogage et les pistes d’audit
• Correlation en systemes distribues : Des services independants generent des identifiants triables sans coordination, permettant la correlation de logs inter-services
• Donnees temporelles : L’horodatage integre permet des requetes temporelles approximatives sur l’identifiant lui-meme, sans colonne d’horodatage separee
• Identifiants de ressources API : 26 caracteres est plus compact que les 36 d’un UUID, et l’encodage insensible a la casse evite les problemes d’URL