Como devo indexar um UUID no Postgres?


26

Eu sou novo no PostgreSQL e um tanto novo nos bancos de dados em geral. Existe uma maneira estabelecida de como devemos indexar valores UUID no Postgres? Estou dividido entre usar hash e usar um trie, a menos que já exista algo incorporado que ele use automaticamente. O que quer que eu use vai lidar com grandes quantidades de dados.

A família de operadores SP-GiST "text_ops" indexa usando uma trie. Como os UUIDs são bastante longos e muito diferentes, esses sons são atraentes, mesmo que eu apenas fizesse pesquisas de correspondência completa.

Há também uma opção de hash. Hashing é O (1), e não precisarei fazer nenhuma comparação além da igualdade, é claro, mas como os UUIDs são muito longos, tenho medo de que gerar hashes a partir deles perca muito tempo.

Ou isso é algo que depende muito do sistema e usa detalhes?

Prefiro usar bigserial na maioria dos casos, mas me disseram para usar o uuid para isso. Precisamos de uuid porque podemos ter vários servidores usando bancos de dados diferentes, portanto não há garantia de que teremos bigints exclusivos. Poderíamos usar uma sequência (e semente) diferente para cada servidor, mas ainda não é tão flexível quanto os UUIDs. Por exemplo, não poderíamos migrar entradas de banco de dados de um servidor para outro sem converter os IDs e suas referências em todos os lugares.


2
Eu acredito que "banco de dados federado" é a palavra da moda para sua situação. E, sim, os UUIDs são a solução para isso. Essa foi a razão pela qual os UUIDs foram inventados décadas atrás: para compartilhar dados entre sistemas distribuídos sem coordenação centralizada.
Basil Bourque

Meses depois: De fato, o "banco de dados federado" apresentado por Basil Bourque é o que buscamos. Não apenas temos vários servidores, mas também clientes (que podem ser considerados mais partes do banco de dados federado) criando IDs enquanto estão offline também. É por isso que usamos UUIDs.
Sudo

Respostas:


31

Use o uuidtipo de dados interno do PostgreSQL e crie nele um índice de árvore b regular.

Não há necessidade de fazer nada de especial. Isso resultará em um índice ideal e também armazenará o uuidcampo no formato mais compacto possível atualmente.

(Os índices de hash no PostgreSQL anteriores à versão 10 não eram à prova de falhas e eram realmente uma relíquia histórica que tendia a ter um desempenho melhor do que um b-tree de qualquer maneira. Evite-os. No PostgreSQL 10 eles foram feitos à prova de falhas e tinham melhorias de desempenho feitas para que você possa considerá-las.)

Se, por algum motivo, você não puder usar o uuidtipo, geralmente criará uma árvore b na representação do texto ou, de preferência, uma bytearepresentação do uuid.


2
Embora a afirmação sobre hashíndices versus b-treeseja uma crença comum, acho que seria útil citar fontes para tal afirmação.
Volte

11
A partir do PostgreSQL 10, os hashíndices agora são protegidos contra falhas. Dito isto, os hashíndices só podem ser usados ​​com =, portanto, se você precisar de outros operadores, b-treeainda é preferível.
rintaun

11
Alguns anos depois, na minha experiência, hashnão foi muito mais rápido do que b-tree, mesmo no Postgres 10. Mas como os índices de hash ocupam muito menos espaço em disco que o b-tree, pode ser mais rápido em uma configuração em que grandes índices se tornam um problema que sinto que não foi o meu caso. Bem, vou ficar de olho agora que posso usá-los com segurança na v10.
Sudo #

Há alguns boa escrever ups no índice hash perf melhorias na v10 e v11: rhaas.blogspot.com/2017/09/... - amitkapila16.blogspot.com/2017/03/...
Glenn Morton

3

Os índices de hash estão ausentes em ação no PostgreSQL. O PostgreSQL sabe que precisa de índices de hash e que o código para índices de hash é antigo e mofado, mas não o remove porque está esperando alguém aparecer e revisar a indexação de hash. Veja este tópico:

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


Sim, recebo um aviso quando tento usar um índice de hash. "Altamente desencorajado" ou algo assim.
Sudo #

Os índices de hash funcionam bem no PostgreSQL em algumas circunstâncias, mas recentemente descobri que eles fizeram com que minhas consultas não retornassem resultados quando tentei otimizar com índices de hash nas chaves primárias e estrangeiras internas do tipo de dados UUID. Existem realmente benefícios nos índices de hash, se eles funcionarem para todos os tipos de dados, e os desenvolvedores do PostgreSQL sabem disso, são muito preguiçosos para consertar eles mesmos e mantêm seu código como se estivessem rezando para / por seus eventuais salvador.
derekm

2
Alguém resgatou índices de hash, suponho, porque eles desempenham um papel crítico no particionamento de dados, no qual a página 10 tem se concentrado: wiki.postgresql.org/wiki/… Mas eles ainda não fornecem tudo o que vi teoricamente útil na classe de banco de dados da faculdade;)
sudo
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.