Quel est le type de colonne UUID le plus efficace

15

Pour stocker un UUID 128 bits, il existe plusieurs options de stockage:

  1. une colonne d'octet [16]
  2. deux colonnes bigint / long (64 bits)
  3. une colonne CHAR (36) - 32 chiffres hexadécimaux + 4 tirets.
  4. une colonne spécifique à la base de données UUID, si db la prend en charge

Du point de vue de l'indexation, lesquels sont les plus efficaces? Si la base de données ne prend pas en charge un type uuid dédié, lesquels parmi 1, 2, 3 sont les meilleurs candidats?

sql-server mysql oracle postgresql index Vlad Mihalcea
la source
1
C'est un peu trop "ça dépend" - beaucoup de spécificités d'implémentation.
Craig Ringer
2
Je ne choisirais jamais 3: ne stocke jamais quelque chose en 36 octets quand cela peut être fait en 16. J'utilise raw(16)dans Oracle et uuiddans PostgreSQL.
Colin 't Hart
1
le plus simple sera le mieux.
akuzminsky
uuid>> bytea>> textavec CHECKcontrainte> varchar(36)>> char(36). Voir: dba.stackexchange.com/a/89433/3684 et dba.stackexchange.com/a/115316/3684 .
Erwin Brandstetter

Réponses:

15

Un uuidtype dédié est votre meilleur pari pour PostgreSQL. Difficile à dire avec d'autres bases de données - il n'est pas impossible pour quelqu'un d'implémenter un uuidtype qui est stocké moins efficacement qu'un type d'octet simple.

Encore une fois dans PostgreSQL, byteaserait un moyen raisonnable de stocker les UUID si vous n'en aviez pas le uuidtype. Pour les autres bases de données, cela dépend de la façon dont elles stockent les données binaires.

Dans la mesure du possible, j'éviterais fortement d'utiliser hex-avec-tirets. C'est beaucoup moins efficace pour comparer, trier et stocker.

Donc vraiment, "pas (2) ou (3)". Déjà. Utilisez (4) lorsque cela est pris en charge, (1) sinon.

Craig Ringer
la source
Une chose à noter est que le type UUID PostgreSQL n'est pas pris en charge nativement dans les tableaux ou cela a-t-il été corrigé? postgresql.org/message-id/…
Christophe Roussy
@ChristopheRoussy Ça date de 2013. C'était un oubli mineur. SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]
Craig Ringer
3

Dans l'ordre de préférence: 4,1,2,3 N'utilisez pas les UUID comme clé de clustering si vous utilisez SQL Server car, non seulement il se fragmentera mal, la clé de clustering est utilisée dans tous les index non clusterisés et vous ajouteriez ces octets à chaque ligne d'index. La fragmentation peut être atténuée en utilisant NEWSEQUENTIALID, mais préférez généralement une identité bingint pour votre clé de clustering à un GUID pour éviter le gonflement dans d'autres index.

La différence entre le choix de 1 sur 2 dépendra de l'efficacité avec laquelle la base de données gère deux colonnes de types de base sur un tableau fixe à une seule colonne. Il devrait être assez facile de tester avec des données fictives. Regardez la vitesse de vos requêtes ainsi que la taille des index et des données. Petit + rapide est le meilleur!

GilesDMiddleton
la source
1

Il faudrait supposer que tout type de données pris en charge nativement serait mieux optimisé dans le produit que tout ce qui pourrait être assemblé en tant que client de ce produit. Après cela, tout ce qui a le plus petit nombre d'octets vous permet donc d'obtenir le maximum de lignes par page.

Michael Green
la source
C'est vrai, mais est-ce seulement la taille d'octet qui compte? Le type n'affecte-t-il pas l'algorithme d'indexation?
Vlad Mihalcea
@Vlad J'utilise SQL Server. AFAIK tous les types de données sont traités de la même manière lors de la construction d'un arbre B (ou d'un index de hachage pour 2104 en mémoire). Il y a de bonnes raisons de garder cela aussi étroit que possible.
Michael Green