Qual é o tipo de coluna UUID mais eficiente

15

Para armazenar um UUID de 128 bits, existem várias opções de armazenamento:

uma coluna de byte [16]
duas colunas bigint / long (64 bits)
uma coluna CHAR (36) - 32 dígitos hexadecimais + 4 traços.
uma coluna específica do banco de dados UUID, se o db suportar

Do ponto de vista da indexação, quais são as mais eficientes? Se o db não suportar um tipo de uuid dedicado, quais de 1, 2, 3 são os melhores candidatos?

— Vlad Mihalcea
fonte

1

Isso também é um pouco "depende" - muitas especificações de implementação.

— Craig Ringer

2

Eu nunca escolheria 3: nunca armazene algo em 36 bytes quando isso puder ser feito em 16. Uso raw(16)no Oracle e uuidno PostgreSQL.

— Colin 't Hart

1

quanto mais simples, melhor.

— akuzminsky

uuid>> bytea>> textcom CHECKrestrição> varchar(36)>> char(36). Consulte: dba.stackexchange.com/a/89433/3684 e dba.stackexchange.com/a/115316/3684 .

— Erwin Brandstetter

15

Um uuidtipo dedicado é sua melhor aposta para o PostgreSQL. Difícil dizer com outros bancos de dados - não é impossível alguém implementar um uuidtipo que é armazenado com menos eficiência do que um tipo de byte simples.

Novamente no PostgreSQL, byteaseria uma maneira razoável de armazenar UUIDs se você não tivesse o uuidtipo. Para outros bancos de dados, depende de como eles armazenam dados binários.

Sempre que possível, eu evitaria usar hex-com-traços. É muito menos eficiente comparar, classificar e armazenar.

Então, realmente, "não (2) ou (3)". Sempre. Use (4) onde suportado, (1) caso contrário.

— Craig Ringer
fonte

Uma coisa a observar é que o tipo UUID do PostgreSQL não é suportado nativamente em matrizes ou isso foi corrigido? postgresql.org/message-id/…

— Christophe Roussy

@ChristopheRoussy Isso é de 2013. Foi uma pequena supervisão. SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]

— Craig Ringer

3

Em ordem de preferência: 4,1,2,3 Não use UUIDs como a chave de cluster, se estiver usando o SQL server, pois ele não somente se fragmentará; a chave de cluster é usada em todos os índices não em cluster e você adicionaria esses bytes a cada linha do índice. A fragmentação pode ser atenuada usando NEWSEQUENTIALID, mas geralmente prefere uma identidade bingint para sua Chave de Clustering sobre um GUID para evitar inchaço em outros índices.

A diferença entre escolher 1 sobre 2 dependerá de quão mais eficiente o banco de dados lida com duas colunas de tipos básicos em uma matriz fixa de coluna única. Deve ser fácil o suficiente para testar com dados fictícios. Veja a velocidade das suas consultas, bem como o tamanho dos índices e dados. Pequeno + rápido é o melhor!

— GilesDMiddleton
fonte

1

Alguém teria que supor que qualquer tipo de dado suportado nativamente seria melhor otimizado no produto do que qualquer coisa que pudesse ser montada como cliente desse produto. Depois disso, o que tiver a menor contagem de bytes, para que você obtenha o máximo de linhas por página.

— Michael Green
fonte

É verdade, mas é apenas o tamanho de byte que importa? O tipo não afeta o algoritmo de indexação?

— Vlad Mihalcea

@ Vlad Eu uso o SQL Server. AFAIK todos os tipos de dados são tratados da mesma maneira ao construir uma árvore B (ou um índice de hash para 2104 na memória). Existem boas razões para manter isso o mais estreito possível.

— Michael Green