UUIDv4 est un bon choix par défaut lorsque vous avez besoin d'identifiants uniques pouvant être générés de manière indépendante entre les services.
Le problème n'est pas que UUIDv4 est "faux". Le problème est que les identifiants entièrement aléatoires ont une localité d'écriture plus faible que les identifiants séquentiels ou ordonnés dans le temps lorsqu'ils sont utilisés dans des index.
C'est important une fois que le volume d'écriture est suffisamment élevé.
Pourquoi les IDs aléatoires modifient le comportement des index
PostgreSQL utilise couramment des index B-tree pour les clés primaires.
Avec un identifiant convivial pour les ajouts, les nouvelles lignes ont tendance à se retrouver près de la fin de l'index. Avec un identifiant aléatoire comme UUIDv4, les insertions se répartissent dans l'ensemble de l'espace clé.
Cela peut conduire à :
- plus de divisions de pages
- une moins bonne localité de cache
- une amplification des écritures accrue lors d'une charge d'insertion importante
Ce n'est pas un échec moral de UUIDv4. C'est une conséquence de l'aléatoire.
Quand vous le remarquez
De nombreux systèmes ne s'en soucieront jamais.
Si la table est modeste en taille ou que le débit d'écriture est modéré, UUIDv4 est souvent acceptable.
Vous commencez à vous en soucier lorsque :
- la table est grande
- les insertions sont fréquentes
- la clé primaire est également le modèle d'accès clusterisé pour les systèmes adjacents
C'est à ce moment que les identifiants ordonnés dans le temps deviennent attrayants.
ULID et UUIDv7
ULID est populaire car il est triable lexicographiquement et reste décentralisé. Il améliore la localité par rapport à UUIDv4.
Aujourd'hui, UUIDv7 mérite également une attention sérieuse car il fournit des UUID ordonnés dans le temps dans un format standardisé.
Cela conduit à une règle de base plus moderne :
- utilisez UUIDv4 lorsque l'aléatoire est acceptable et que la charge de travail n'est pas sensible
- utilisez ULID ou UUIDv7 lorsque la localité et l'ordre des index importent
Le compromis d'application
Le choix de l'identifiant n'est pas seulement une décision de base de données.
Vous choisissez également :
- le comportement de tri
- la longueur et l'encodage de la chaîne
- l'interopérabilité avec les bibliothèques et les bases de données
- la lisibilité humaine dans les journaux et les URL
C'est pourquoi il n'y a pas de vainqueur universel.
Une recommandation utile
Si vous commencez un nouveau système et souhaitez des identifiants ordonnés dans le temps, privilégiez un format standardisé lorsque cela est possible. Cela signifie généralement évaluer UUIDv7 en premier, ULID restant une option pragmatique lorsque son intégration est meilleure pour votre stack.
Si vous utilisez déjà UUIDv4 et que la base de données est saine, ne migrez pas juste parce qu'un article de blog a dit que les identifiants aléatoires sont mauvais. Mesurez d'abord la charge de travail réelle.
Lectures complémentaires