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 d' uuid car nous pouvons 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.

postgresql index uuid

— sudo
source

Je crois que «base de données fédérée» est le mot à la mode pour votre situation. Et, oui, les UUID sont la solution pour cela. C'est la raison même pour laquelle les UUID ont été inventés il y a des décennies: pour partager des données entre des systèmes distribués sans coordination centralisée.

— Basil Bourque

Des mois plus tard: En effet, la "base de données fédérée" évoquée par Basil Bourque est ce que nous recherchons. Non seulement nous avons plusieurs serveurs, mais nous avons également des clients (qui peuvent être considérés comme plus de parties de la base de données fédérée) créant des identifiants hors ligne. C'est pourquoi nous utilisons des UUID.

— sudo

Réponses:

Utilisez le uuidtype de données intégré de PostgreSQL et créez 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 uuidchamp sous une forme aussi compacte que cela est actuellement pratique.

(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 des performances apportées afin que vous souhaitiez les prendre en compte.)

Si, pour une raison quelconque, vous ne pouviez pas utiliser le uuidtype, vous créiez généralement un arbre b sur la représentation textuelle ou, de préférence, une byteareprésentation de l'uuid.

— Craig Ringer
source

Bien que la déclaration concernant les hashindices par rapport à b-treeest une croyance commune, je pense qu'il serait utile de citer les sources d'une telle affirmation.

— Volte le

À partir de PostgreSQL 10, les hashindex sont désormais protégés contre les pannes. Cela dit, les hashindex ne peuvent être utilisés qu'avec =, donc si vous avez besoin d'autres opérateurs, b-treec'est toujours préférable.

— rintaun

Quelques années plus tard, d'après mon expérience, cela hashn'a pas été beaucoup plus rapide que b-tree, même dans Postgres 10. Mais comme les index de hachage prennent tellement moins d'espace disque que b-tree, cela pourrait être plus rapide dans une configuration où les gros index deviennent un problème, qui je pense n'a pas été le cas pour moi. Eh bien, je garderai un œil maintenant que je peux les utiliser en toute sécurité dans la v10.

— sudo

Il y a de bonnes notes sur les améliorations de la performance de l'indice de hachage dans les versions 10 et 11 : rhaas.blogspot.com/2017/09/… - amitkapila16.blogspot.com/2017/03/…

— Glenn Morton

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:

http://www.postgresql.org/message-id/4407.1115698257@sss.pgh.pa.us

— derekm
source

Oui, je reçois un avertissement lorsque j'essaie d'utiliser un index de hachage. "Très découragé" ou quelque chose.

— sudo

Dans certains cas, les index de hachage fonctionnent bien dans PostgreSQL, mais j'ai récemment constaté qu'ils ne renvoyaient aucun résultat à mes requêtes lorsque j'essayais d'optimiser avec les index de hachage sur les clés primaires et étrangères de type de données UUID intégrées. Les index de hachage ont vraiment des avantages, si seulement ils fonctionnaient pour tous les types de données, et les développeurs PostgreSQL le savent, ils sont juste trop paresseux pour le réparer eux-mêmes, et ils gardent leur code situé comme s'ils priaient / pour leur éventuel Sauveur.

— derekm

Quelqu'un a sauvé les index de hachage, je suppose parce qu'ils jouent un rôle essentiel dans le partitionnement des données, sur lequel Pg10 s'est concentré: wiki.postgresql.org/wiki/… Mais ils ne vous donnent toujours pas tout ce que j'ai vu théoriquement utile dans la classe de base de données collégiale;)

— sudo