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.
la source
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, unebyteareprésentation de l'uuid.la source
hashindices par rapport àb-treeest une croyance commune, je pense qu'il serait utile de citer les sources d'une telle affirmation.hashindex sont désormais protégés contre les pannes. Cela dit, leshashindex ne peuvent être utilisés qu'avec=, donc si vous avez besoin d'autres opérateurs,b-treec'est toujours préférable.hashn'a pas été beaucoup plus rapide queb-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.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/[email protected]
la source