Version des UUID Expliquées — Arrêtez d'utiliser la version 4 partout

Dans votre base de code, il y a une ligne qui ressemble à cela : id = uuid.v4()Cela fonctionne. Vos tests passent. Vos utilisateurs ne se plaignent jamais. Et chaque fois que la DBA regarde le plan de requête, elle se contente de soupirer.

Le UUID v4 est devenu par défaut car il est simple, universellement disponible et résistant aux collisions, de sorte que vous n'atteindrez jamais de conflit. Mais « cela fonctionne » et « c'est le bon outil » ne sont pas la même chose — et pour les clés primaires dans une base de données, le v4 ralentit activement votre système à l'échelle.

Ce que le UUID v4 fait réellement à votre base de données

Les bases de données relationnelles utilisent des index B-arbre pour les clés primaires. Un arbre B maintient les données triées afin que la base de données puisse trouver des lignes en O(log n). Lorsqu'une nouvelle ligne est insérée, la base de données doit la placer dans la position correcte dans l'index trié.

Avec le UUID v4, chaque nouvel identifiant est aléatoire. 550e8400-e29b-41d4-a716-446655440000 peut être suivi de f47ac10b-58cc-4372-a567-0e02b2c3d479 — il n'existe pas de relation entre les insérations consécutives. La base de données doit naviguer vers une feuille aléatoire de l'arbre B à chaque fois.

Cela cause deux problèmes à grande échelle :

• Les divisions de page : Lorsqu'une feuille de l'arbre B est pleine, la base de données doit la diviser en deux pages et mettre à jour le parent. Avec des insérations aléatoires, les divisions se produisent fréquemment dans toute l'index — pas seulement à la fin.
• Les manques de cache : Le pool de tampon de la base de données conserve les pages utilisées récemment en mémoire. Les insérations séquentielles touchent les mêmes « pages chaudes ». Les insérations aléatoires dispersent les lectures à travers tout l'index, détruisant le cache et forçant des lectures sur disque.

Sur une table avec des millions de lignes et un fort débit d'écriture, cette fragmentation de l'index s'accumule en latence réelle. Si votre EXPLAIN ANALYZE montre que les scans d'index prennent plus de temps qu'ils ne le devraient, les UUIDs aléatoires pourraient être une partie de l'analyse.

L'arbre de UUID

UUID v1 : Horodatage, adresses MAC et la raison pour laquelle on ne l'utilise plus

Le UUID v1 était le premier « UUID triable ». Il encode un horodatage de 60 bits en intervalles de 100 nanosecondes depuis le 15 octobre 1582, combiné avec une séquence horaire et l'adresse MAC de votre machine. Le résultat est approximativement triable par temps.

La partie adresse MAC est ce qui a tué le v1. Elle révèle l'identifiant de l'interface réseau de votre serveur dans chaque ID que vous générez — pour chaque enregistrement utilisateur, chaque commande, chaque événement. Les chercheurs en sécurité ont démontré que les UUID v1 provenant du même appareil sont prévisibles une fois qu'on a un seul échantillon. Les organisations ont commencé à éviter son utilisation pour tout contenu visant les utilisateurs, et la plupart des bibliothèques de UUID l'ont marqué comme obsolète.

UUID v4 : Aléatoire, sécurisé, et mal adapté aux clés primaires

Le UUID v4 est composé de 122 bits de données aléatoires cryptographiques (les bits restants codent la version). La probabilité de collision pour un milliard de UUIDs est environ 1 sur 10^18. En pratique, c'est nul.

Cette aléatoire est exactement ce que vous voulez pour les jetons de sécurité, les identifiants de session, les clés API et les identifiants de corrélation — tout ce qui nécessite un ID qui ne peut pas être deviné ou énuméré. Pour ces cas d'utilisation, continuez à utiliser le v4. Le problème est que « ne peut pas être deviné » et « adapté à la base de données » sont des propriétés opposées.

Souhaitez-vous expérimenter avec la génération de UUID ? Le Générateur de UUID sur IO Tools vous permet de générer des versions v1, v4, v7 et d'autres variantes simultanément afin de voir la différence de structure.

UUID v7 : La nouvelle norme que vous devriez utiliser

Le UUID v7 a été standardisé par l'IETF dans le RFC 9562 en mai 2023. Il met un horodatage en millisecondes du système Unix dans les 48 bits les plus significatifs, suivis d'un champ de version de 4 bits, d'un compteur de séquence de 12 bits et de 62 bits de données aléatoires.

En pratique, cela signifie que les UUIDs générés plus tard sont plus grands lexicologiquement. Les insérations consécutives se trouvent dans des positions adjacentes dans l'arbre B. Aucune dispersion aléatoire, aucune division inutile de page, aucun épuisement du cache. Il se comporte comme un entier auto-incrémenté depuis le point de vue de la base de données — tout en restant globalement unique sans coordination.

Le compteur de séquence au sein d'un même milliseconde garantit un ordre monotone même pour des générateurs à forte fréquence. Si vous générez 10 000 UUIDs en un milliseconde, ils resteront correctement triés. Le suffixe aléatoire conserve assez d'entropie pour que les collisions entre systèmes distribués restent extrêmement peu probables.

Pour tout nouveau système utilisant PostgreSQL, MySQL ou une autre base de données relationnelle, le UUID v7 devrait être votre choix par défaut pour les clés primaires.

ULID : L'alternative qui a existé avant UUID v7

ULID (Universally Unique Lexicographically Sortable Identifier) résolvait le même problème avant l'existence du UUID v7. Il utilise 48 bits pour l'horodatage en millisecondes du système Unix et 80 bits de données aléatoires, encodés en Base32 de Crockford.

Le résultat est une chaîne de 26 caractères qui ressemble à 01ARZ3NDEKTSV4RRFFQ69G5FAV au lieu du format standard de 36 caractères hyphené du UUID. Il est sécurisé pour les URLs sans encodage, trie correctement comme une chaîne de caractères et est insensible à la casse.

ULID n'a pas de RFC IETF — il a une spécification communautaire sur ulid.github.io. Cela suffit à la plupart des équipes, mais si vous êtes dans un environnement réglementé qui exige des identifiants formellement standardisés, le UUID v7 est la meilleure option. ULID dispose d'un solide support dans les écosystèmes JavaScript et Go, et si votre équipe l'utilise déjà, il n'y a pas de raison urgente de le changer.

Comparaison côte à côte

Propriété	UUID v1	UUID version 4	UUID v7	UDI
Triable	Partiellement	Non	Oui	Oui
Résistant aux collisions	Oui	Oui	Oui	Oui
Adapté à la base de données	Partiellement	Non	Oui	Oui
Sécurisé en matière de confidentialité	Non (adresse MAC)	Oui	Oui	Oui
Organisme standard	RFC 4122 de l'IETF	RFC 4122 de l'IETF	RFC 9562 de l'IETF	Spécification communautaire
Longueur typique	36 caractères	36 caractères	36 caractères	26 caractères
Source d'entropie	Adresse MAC + horodatage	Aléatoire	Horodatage + aléatoire	Horodatage + aléatoire

Quand utiliser chacun

UUID v7 — utilisez cela pour les clés primaires dans tout nouveau système. C'est une norme IETF, dispose d'un soutien croissant dans les bibliothèques (intégrée nativement dans PostgreSQL 17, disponible via des bibliothèques dans chaque langage principal) et vous donne un ordre triable dans l'arbre B sans coordination requise.

UUID version 4 — continuez à utiliser cela pour tout cas de sécurité où la randomisation est importante : jetons de session, jetons de réinitialisation de mot de passe, clés API, paramètres d'état OAuth, identifiants de corrélation dans les journaux. L'indéchiffrabilité est une fonctionnalité ici, pas un défaut.

UDI — utilisez-le si votre équipe l'utilise déjà, particulièrement dans des projets JavaScript ou Go. Le format plus court est vraiment plus agréable dans les URLs et les journaux. Si vous commencez à zéro, le UUID v7 est la meilleure option à long terme simplement parce qu'il est appuyé par l'IETF.

UUID v1 — ne le faites pas. Il n'existe aucune situation où le v1 est le bon choix pour du nouveau code.

Considérations relatives à la migration

Si vous gérez un système existant avec des clés primaires UUID v4, vous n'avez pas besoin de migrer immédiatement — et vous ne devriez pas le faire de manière informelle. Les relations de clés étrangères, le code de l'application et potentiellement des valeurs en cache font référence à ces identifiants. Une migration nécessite une planification rigoureuse et presque certainement un temps de maintenance.

Pour la plupart des équipes, l'approche pragmatique est : utiliser le UUID v7 (ou ULID) pour toutes les nouvelles tables et services. Acceptez que vos tables héritées aient des v4 et gérez la fragmentation par des rééditions périodiques de l'index si l'impact sur les performances est mesurable. Ne laissez pas la perfection être l'ennemi de la bonne solution.

Si vous êtes en phase de développement — nouveau projet, nouvelle base de données, nouvelles tables — il n'y a aucune raison de choisir le v4 pour les clés primaires. Les outils sont là. Générez quelques échantillons de UUID v7 et voyez ce que vous avez à travailler.

Le mot de la fin

Le UUID v4 n'est pas faux — il est simplement fréquemment mal appliqué. Sa randomisation est une propriété de sécurité, et vous devez la préserver là où la sécurité est importante. Pour les clés primaires dans une base de données, cette randomisation devient un fardeau de performance à grande échelle.

Le UUID v7 résout ce problème de manière claire : croissant, globalement unique, standardisé et déjà pris en charge par les bases de données et les ORMs que vous utilisez. Si vous écrivez un nouveau schéma de base de données aujourd'hui, faites de v7 votre choix par défaut. L'avenir de vous-même — et votre DBA — notera la différence.

Vous aimerez peut-être aussi