Introduction
L'utilisation de clés primaires UUID aléatoires dans les bases de données est une pratique courante. Cependant, cette approche présente des inconvénients, notamment en termes de performances, en raison de la nature non ordonnée des UUID4, ce qui peut entraîner des opérations de pagination supplémentaires pour l'index clusterisé.
Contexte Technique
Un index clusterisé détermine l'ordre de stockage physique des lignes dans une table. Les lignes de données de la table sont stockées dans les pages de feuille de l'index, triées par la clé indexée. Cela signifie qu'il ne peut y avoir qu'un seul index clusterisé par table et que cet index est essentiellement la table elle-même.
SQLite utilise un index clusterisé implicite appelé rowid pour les tables ordinaires, qui est un entier 64 bits servant de clé primaire. Les tables sans rowid, quant à elles, utilisent la clé primaire déclarée comme index clusterisé.
Analyse et Implications
Les tests de performances ont montré que l'utilisation de clés primaires UUID4 peut être 10 à 12 fois plus lente que l'utilisation de clés primaires entières. Cela est dû au fait que les UUID4 sont ordonnés aléatoirement, ce qui force SQLite à constamment rééquilibrer l'arbre B.
L'analyse des profils a révélé que le temps passé à équilibrer l'arbre, à lire et à écrire les données est nettement plus élevé avec les UUID4 par rapport aux clés primaires entières.
Perspective
Il est possible de résoudre ce problème en utilisant des UUID7, qui sont ordonnés dans le temps, éliminant ainsi le problème d'ordre des UUID4. Les tests ont montré que les UUID7 peuvent améliorer les performances, même si elles sont légèrement plus lentes que les clés primaires entières en raison de la taille plus grande des clés blob.
En conclusion, l'utilisation de clés primaires UUID dans SQLite nécessite une attention particulière aux implications en termes de performances et de conception de la base de données.
