Comment dois-je indexer un UUID dans Postgres?
Je suis nouveau sur PostgreSQL et quelque peu nouveau sur les bases de données en général. Existe-t-il un moyen établi d'indexer les valeurs UUID dans Postgres? Je suis partagé entre l'utilisation du hachage et l'utilisation d'un trie, à moins qu'il y ait déjà quelque chose de intégré qu'il utilise automatiquement. Tout ce que j'utilise va gérer d'énormes quantités de données.
La famille d'opérateurs SP-Gist "text_ops" indexe à l'aide d'un trie. Parce que les UUID sont assez longs et très différents, ces sons sont attrayants même si je ne faisais que des recherches de correspondance complètes.
Il existe également une option de hachage. Le hachage est O (1), et je n'aurai pas besoin de faire de comparaisons en dehors de l'égalité bien sûr, mais parce que les UUID sont assez longs, je crains que générer des hachages à partir d'eux ne perde beaucoup de temps.
Ou est-ce quelque chose qui dépend trop du système et utilise des spécificités?
Je préfère utiliser bigserial dans la plupart des cas, mais on m'a dit d'utiliser uuid pour cela. Nous avons besoin de uuid car nous pourrions avoir plusieurs serveurs utilisant différentes bases de données, donc il n'y a aucune garantie que nous aurons des bigints uniques. Nous pourrions utiliser une séquence (et une graine) différente pour chaque serveur, mais ce n'est toujours pas aussi flexible que les UUID. Par exemple, nous ne pourrions pas migrer les entrées de base de données d'un serveur à un autre sans convertir les ID et leurs références partout.
Utilisez le --- intégré de PostgreSQL uuid type de données , et create un index b-tree régulier dessus.
Il n'est pas nécessaire de faire quoi que ce soit de spécial. Cela se traduira par un index optimal et stockera également le champ uuid sous une forme aussi compacte que cela est actuellement possible.
(Les index de hachage dans PostgreSQL avant la version 10 n'étaient pas à l'abri des plantages et étaient vraiment une relique historique qui avait tendance à ne pas fonctionner mieux qu'un arbre b de toute façon. Évitez-les. améliorations apportées aux performances, vous pouvez donc les envisager.)
Si, pour une raison quelconque, vous ne pouviez pas utiliser le type uuid, vous créeriez généralement un arbre b sur la représentation textuelle ou, de préférence, une représentation bytea de l'uuid.
Les index de hachage sont manquants dans l'action dans PostgreSQL. PostgreSQL sait qu'il a besoin d'index de hachage et que son code pour les index de hachage est ancien et moisi, mais ils ne le suppriment pas car ils attendent que quelqu'un vienne et refasse l'indexation de hachage. Voir ce fil: