Qu'est-ce qu'un UUID et quand devriez-vous en utiliser un ?
Ouvrez presque n'importe quelle base de données, API ou application et vous trouverez de longues chaînes telles que 550e8400-e29b-41d4-a716-446655440000. Ce sont des UUID, et ils résolvent un problème trompeusement délicat : comment générer un identifiant unique sans qu’une autorité centrale ne le coordonne ? Voici comment ils fonctionnent et quand les contacter.
Qu'est-ce qu'un UUID
UUID signifie Universally Unique Identifier : une valeur de 128 bits, généralement affichée sous la forme de 32 caractères hexadécimaux répartis en cinq groupes séparés par des traits d'union. L'essentiel réside dans le nom : il est conçu pour être unique dans l'espace et dans le temps, afin que deux systèmes, n'importe où, puissent générer des UUID indépendamment et ne jamais entrer en collision.
Comment peut-il être unique sans coordination ?
Le type le plus courant, la version 4, est presque entièrement aléatoire : 122 bits aléatoires. Le nombre de valeurs possibles est si astronomique (environ 5 undécillions) que la probabilité que deux UUID générés aléatoirement correspondent est effectivement nulle, même sur des milliards d'entre eux. Vous n'avez pas besoin d'un comptoir central ; le hasard à lui seul rend les collisions pratiquement impossibles. Générez-en un instantanément avec notre générateur d'UUID.
UUID et ID à incrémentation automatique
Les bases de données traditionnelles utilisent des identifiants séquentiels (1, 2, 3…). Ils sont simples et compacts, mais ils présentent des inconvénients que les UUID évitent :
- Aucune coordination nécessaire : plusieurs serveurs peuvent créer des enregistrements hors ligne et les fusionner ultérieurement sans conflits d'ID.
- Impossible de le deviner : les identifiants séquentiels divulguent des informations (un concurrent peut voir que vous avez la « commande n° 1043 ») et sont faciles à énumérer ; Les UUID ne le sont pas.
- Généré n'importe où : le client peut créer l'ID avant de parler au serveur.
Quand utiliser lequel
Utilisez les UUID pour les systèmes distribués, les identifiants publics, la fusion de données provenant de plusieurs sources ou partout où vous ne souhaitez pas que les identifiants soient devinables. Tenez-vous-en aux entiers à incrémentation automatique lorsque vous disposez d’une seule base de données, que vous souhaitez des clés compactes et que vous valorisez des identifiants lisibles par l’homme. De nombreux systèmes utilisent les deux : une clé entière interne et un UUID externe.
Une note sur les compromis
Les UUID sont plus grands que les entiers (16 octets contre 4 à 8), ce qui affecte légèrement les performances de stockage et d'indexation à grande échelle. Pour la plupart des applications, la différence est négligeable et les avantages sont gagnants, mais cela vaut la peine de le savoir.
Les versions d'UUID que vous rencontrerez réellement
Tous les UUID ne sont pas aléatoires. La version 4 (aléatoire) est de loin la plus courante et celle que produisent la plupart des outils de « génération d'un UUID ». La version 1 intègre un horodatage et un identifiant de machine, ce qui le rend triable mais peut divulguer des informations. La nouvelle version 7 est classée dans le temps et de manière aléatoire : elle est de plus en plus populaire car elle trie par ordre chronologique tout en restant indevinable, ce qui améliore les performances de la base de données. Pour la plupart des besoins, la version 4 est la valeur par défaut ; optez pour la version 7 lorsque vous souhaitez un classement adapté aux bases de données.
UUID et performances de la base de données
Un vrai compromis : les UUID v4 aléatoires comme clé primaire peuvent nuire aux performances d'écriture de la base de données, car chaque insertion atterrit à un endroit aléatoire dans l'index plutôt que de s'ajouter proprement à la fin comme un entier séquentiel. À petite échelle, cela n'a pas d'importance, mais pour des millions de lignes, cela compte - c'est exactement pourquoi les UUID v7 ordonnés dans le temps existent. Un modèle courant est une clé d'auto-incrémentation interne pour les performances, ainsi qu'un UUID externe pour les identifiants publics.
Les collisions sont-elles possibles ?
En pratique, non. Le nombre d'UUID v4 aléatoires est si vaste (2¹²²) que vous pourriez en générer des milliards par seconde pendant des années sans jamais vous attendre à un affrontement – la probabilité est comparable à celle d'être frappé par une météorite. Vous n'avez pas besoin de rechercher les doublons en utilisation normale. Cette résistance aux collisions sans aucune coordination centrale est la seule raison pour laquelle les UUID sont si utiles dans les systèmes distribués.
Résultat
Un UUID est un identifiant de 128 bits suffisamment unique pour être généré n'importe où sans coordination. Contactez-les lorsque vous avez besoin d'identifiants distribués, indevinables ou générés par le client ; conservez des entiers simples lorsque vous disposez d’une base de données et que vous souhaitez des clés compactes et lisibles. Pour des utilitaires de développement plus pratiques, consultez notre boîte à outils de développement.
