Adieu Integer, bonjour UUIDv7

• Buildkite a adopté la nouvelle norme UUIDv7 comme clé primaire, remplaçant l’ancien système de clé primaire séquentielle et de clé secondaire UUID
• Les UUID (Universally Unique Identifiers) sont des identifiants uniques pouvant être générés indépendamment, largement utilisés dans les systèmes distribués et les bases de données
• Les UUID offrent plusieurs avantages par rapport aux identifiants entiers séquentiels, notamment l’imprévisibilité, la prévention de l’exposition d’informations internes sensibles et une couche de défense supplémentaire
• Cependant, le caractère aléatoire des UUID standard non ordonnés dans le temps peut entraîner des problèmes de performance des bases de données
• Pour résoudre ce problème, Buildkite a expérimenté des UUID compatibles UUIDv4 mais ordonnés dans le temps, ce qui a réduit de 50 % le volume du Write Ahead Log (WAL) de sa base de données principale
• La version 7 des UUID (UUIDv7) encode un timestamp Unix en millisecondes dans les 48 bits les plus significatifs, tandis que les 74 bits restants sont générés aléatoirement
• Buildkite a décidé d’utiliser UUIDv7 comme clé primaire pour toutes les nouvelles tables, ce qui supprime le besoin de coordination dans la génération des identifiants et simplifie la logique applicative
• Des alternatives comme l’implémentation ShardingID d’Instagram et l’implémentation de clés primaires composites de Shopify ont été envisagées, mais l’équipe a choisi UUIDv7
• La transition vers UUIDv7 nécessite davantage d’espace de stockage en raison de la longueur de 128 bits des UUID, mais cela reste négligeable par rapport au reste de l’espace occupé par une ligne de base de données
• L’entreprise est actuellement en train de sharder sa plus grande base de données Postgres et pourrait à l’avenir utiliser UUIDv8 pour inclure un numéro de shard dans les identifiants si nécessaire

[GN⁺]

Commentaires sur Hacker News

• UUIDv7 est utile pour les systèmes distribués internes grâce à ses clés ordonnées, mais peut ne pas convenir comme identifiant public en raison de problèmes de sécurité potentiels.
• On affirme que les identifiants aléatoires nuisent aux performances, mais en pratique ils sont meilleurs pour les systèmes de stockage distribués, car ils évitent les hotspots sur un nœud unique.
• Il existe plusieurs versions de UUID en raison de l’évolution des besoins et des propriétés recherchées pour les identifiants.
• UUIDv7 combine les avantages d’une clé primaire séquentielle pour une indexation efficace avec une clé secondaire UUID pour un usage externe.
• L’un des inconvénients potentiels de UUIDv7 est que les utilisateurs peuvent extraire l’heure de création à partir de l’identifiant.
• Une fonction UUID v7 pour PostgreSQL a été publiée en open source, offrant des avantages comme une amélioration de la vitesse des insertions par lots.
• UUIDv7 peut être utilisé avec le type uuid de Postgres, qui accepte toute donnée de la bonne longueur.
• Certains préfèrent une clé primaire séquentielle de 64 bits et une clé aléatoire supplémentaire de 64 bits pour un usage externe, afin de masquer les informations sur la taille des données et la date de création.
• Les UUID sont utiles pour générer des clés à partir de nombreuses sources séparées qui devront être fusionnées plus tard.
• Il existe un débat sur la nécessité de « valider » les GUID/UUID. Ils sont souvent traités comme des identifiants opaques.
• Le choix entre UUIDv7 et ULID dépend des besoins spécifiques ; les ULID offrent 6 bits d’aléa supplémentaires par rapport à ce que les UUID utilisent pour leurs métadonnées.