Aller au contenu principal

2. Motivation

2. Motivation​

L'une des principales raisons d'utiliser les UUID est qu'aucune autorité centralisée n'est requise pour les administrer (bien que deux formats puissent tirer parti d'ID de nœud IEEE 802 optionnels, d'autres ne le font pas). Par conséquent, la génération à la demande peut être entièrement automatisée et utilisée à diverses fins. L'algorithme de génération d'UUID décrit ici prend en charge des taux d'allocation très élevés de 10 millions par seconde par machine ou plus, si nécessaire, de sorte qu'ils pourraient même être utilisés comme ID de transaction.

Les UUID ont une taille fixe (128 bits), ce qui est raisonnablement petit par rapport à d'autres alternatives. Cela se prête bien au tri, à l'ordonnancement et au hachage de toutes sortes; au stockage dans les bases de données; à l'allocation simple; et à la facilité de programmation en général.

Étant donné que les UUID sont uniques et persistants, ils constituent d'excellents URN. La capacité unique de générer un nouvel UUID sans processus d'enregistrement permet aux UUID d'être l'un des URN avec le coût de création le plus bas.

2.1. Motivation de la mise à jour​

Beaucoup de choses ont changé depuis la création initiale des UUID. Les applications modernes ont besoin de créer et d'utiliser des UUID comme identifiant principal pour une variété d'éléments différents dans des systèmes informatiques complexes, y compris, mais sans s'y limiter, les clés de base de données, les noms de fichiers, les noms de machines ou de systèmes et les identifiants pour les transactions pilotées par événements.

Un domaine dans lequel les UUID ont gagné en popularité est celui des clés de base de données. Cela découle de la nature de plus en plus distribuée des applications modernes. Dans de tels cas, les schémas "auto-incrémentés" souvent utilisés par les bases de données ne fonctionnent pas bien: l'effort requis pour coordonner les identifiants numériques séquentiels sur un réseau peut facilement devenir un fardeau. Le fait que les UUID puissent être utilisés pour créer des valeurs uniques et raisonnablement courtes dans des systèmes distribués sans nécessiter de coordination en fait une bonne alternative, mais les versions UUID 1-5, qui ont été définies à l'origine par [RFC4122], manquent de certaines autres caractéristiques souhaitables, telles que:

  1. Les versions UUID qui ne sont pas ordonnées dans le temps, telles que UUIDv4 (décrites dans la section 5.4), ont une mauvaise localité d'index de base de données. Cela signifie que les nouvelles valeurs créées successivement ne sont pas proches les unes des autres dans l'index; ainsi, elles nécessitent que les insertions soient effectuées à des emplacements aléatoires. Les effets négatifs sur les performances qui en résultent sur les structures courantes utilisées pour cela (l'arbre B et ses variantes) peuvent être dramatiques.

  2. L'époque grégorienne de 100 nanosecondes utilisée dans les horodatages UUIDv1 (décrits dans la section 5.1) est peu commune et difficile à représenter avec précision à l'aide d'un format de nombre standard tel que celui décrit dans [IEEE754].

  3. L'introspection/l'analyse est nécessaire pour ordonner par séquence temporelle, par opposition à la possibilité d'effectuer une simple comparaison octet par octet.

  4. Des problèmes de confidentialité et de sécurité réseau découlent de l'utilisation d'une adresse de contrôle d'accès au support (Media Access Control, MAC) dans le champ de nœud de UUIDv1. Les adresses MAC exposées peuvent être utilisées comme surface d'attaque pour localiser les interfaces réseau et révéler diverses autres informations sur ces machines (au minimum, le fabricant et, potentiellement, d'autres détails). De plus, avec l'avènement des machines virtuelles et des conteneurs, l'unicité de l'adresse MAC n'est plus garantie.

  5. Bon nombre des détails d'implémentation spécifiés dans [RFC4122] impliquaient des compromis qui ne sont ni possibles à spécifier pour toutes les applications ni nécessaires pour produire des implémentations interopérables.

  6. [RFC4122] ne faisait pas de distinction entre les exigences de génération d'un UUID et celles de simple stockage, bien qu'elles soient souvent différentes.

En raison des problèmes susmentionnés, de nombreuses applications de base de données largement distribuées et de grands fournisseurs d'applications ont cherché à résoudre le problème de la création d'un meilleur identifiant unique basé sur le temps et triable pour une utilisation comme clé de base de données. Cela a conduit à de nombreuses implémentations au cours des 10 dernières années et plus résolvant le même problème de manières légèrement différentes.

Lors de la préparation de cette spécification, les 16 implémentations différentes suivantes ont été analysées pour les tendances en matière de longueur d'ID totale, de disposition des bits, de formatage et d'encodage lexicaux, de type d'horodatage, de format d'horodatage, de précision d'horodatage, de format et de composants de nœud, de gestion des collisions et de séquençage de génération de ticks multi-horodatage:

  1. [ULID]
  2. [LexicalUUID]
  3. [Snowflake]
  4. [Flake]
  5. [ShardingID]
  6. [KSUID]
  7. [Elasticflake]
  8. [FlakeID]
  9. [Sonyflake]
  10. [orderedUuid]
  11. [COMBGUID]
  12. [SID]
  13. [pushID]
  14. [XID]
  15. [ObjectID]
  16. [CUID]

Une inspection de ces implémentations et des problèmes décrits ci-dessus a conduit à ce document, dans lequel de nouveaux UUID sont adaptés pour résoudre ces problèmes.

De plus, [RFC4122] lui-même avait besoin d'une refonte pour aborder un certain nombre de sujets tels que, mais sans s'y limiter, les suivants:

  1. Mise en œuvre de rapports d'errata divers. Principalement autour des clarifications de la disposition des bits, qui conduisent à des implémentations incohérentes [Err1957], [Err3546], [Err4975], [Err4976], [Err5560], etc.

  2. Découpler les autres versions UUID de la disposition des bits UUIDv1 afin que des champs comme "time_hi_and_version" n'aient pas besoin d'être référencés dans un UUID qui n'est pas basé sur le temps tout en fournissant des sections de définition similaires à celle pour UUIDv1 pour UUIDv3, UUIDv4 et UUIDv5.

  3. Fournir des meilleures pratiques d'implémentation autour de nombreux scénarios du monde réel et cas limites observés par les implémentations existantes et prototypes.

  4. Aborder les meilleures pratiques de sécurité et les considérations pour l'ère moderne en ce qui concerne les adresses MAC, les algorithmes de hachage, le caractère aléatoire sécurisé et d'autres sujets.

  5. Fournir aux implémentations une option basée sur des normes pour les conceptions UUID spécifiques à l'implémentation et/ou expérimentales.

  6. Fournir plus de vecteurs de test qui illustrent de vrais UUID créés conformément à la spécification.

Dernière mise à jour le