O que é UUID? Porque usá-lo?
UUID — (do inglês Universally Unique IDentifier )
O que é?
UUID é um identificador universalmente exclusivo utilizado para identificação de qualquer coisa no mundo da computação. O UUID é um número de 128 bits representado por 32 dígitos hexadecimais, exibidos em cinco grupos separados por hifens, na forma textual8-4-4-4-12 sendo um total de 36 caracteres (32 caracteres alfanuméricos e 4 hifens). Por exemplo:
3d0ca315-aff9–4fc2-be61–3b76b9a2d798
O objetivo dos UUIDs é possibilitar a identificação unica de uma informação em sistemas distribuídos, sem uma coordenação central. Neste contexto a palavra única deve ser tomada com o significado de “praticamente única” uma vez que os identificadores possuam um tamanho finito, é possível para dois itens diferentes compartilhar do mesmo identificador. O tamanho e o processo de geração do identificador necessitam ser selecionados de forma a tornar esta improbabilidade suficientemente na prática.
Versões
Em sua representação textual8-4-4-4-12o UUID possui um carácter em específico que representa a versão em que o mesmo foi gerado. Veja o exemplo abaixo:
xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx ( O V indica a versão )3d0ca315-aff9–4fc2-be61–3b76b9a2d798 ( UUID versão 4 )
- Versão 1: são gerados a partir de um tempo e um node id (geralmente o endereço MAC);
- Versão 2: são gerados a partir de um identificador (geralmente um id de grupo ou usuário), tempo e um node id;
- Versões 3 e 5: produzem UUIDs gerados por hashing de um identificador de namespace e nome;
- Versão 4: são gerados usando um número aleatório ou pseudo-aleatório.
Você pode obter mais detalhes dos algorítimos utilizados para geração de cada versão lendo a RFC 4122.
Porque usá-lo?
Existe uma longa discussão se a utilização de IDs incrementais pode ser considerado um vazamento acidental de informação. (Na minha opinião é sim!). Essa questão é abordada com excelência nesse fantástico artigo do Phil Sturgeon.
Normalmente quando criamos uma tabela no banco de dados, adicionamos uma coluna ID (ou qualquer outro nome representativo) como chave primaria sendo auto-increment. Um ID auto-increment é um número inteiro que começa em 1 e é aumentado em +1 sempre que um novo registro é salvo no banco de dados.
O problema dessa abordagem é que esse ID acaba sendo exposto nas URLs das aplicações para identificar um recurso em específico. Isso é bastante comum em APIs Rest. Veja um exemplo:
A tabela abaixo representa as possíveis URLs que você teria em uma API Rest para a manipulação de um usuário na aplicação.┌───────────┬──────────────────────┬─────────┐
│ Verb │ URI │ Action │
├───────────┼──────────────────────┼─────────┤
│ GET │ /users │ index │
│ GET │ /users/create │ create │
│ POST │ /users │ store │
│ GET │ /users/{id} │ show │
│ GET │ /users/{id}/edit │ edit │
│ PUT/PATCH │ /users/{id} │ update │
│ DELETE │ /users/{id} │ destroy │
└───────────┴──────────────────────┴─────────┘Perceba como o ID é utilizado (na maioria das URLs!) para identificar o usuário.
Agora imagine que você acabou de criar um novo usuário nessa aplicação fictícia da tabela acima, e recebeu o ID número 56. Não é preciso ser nenhum gênio pra deduzir que possivelmente tal aplicação possui no máximo 56 usuários, certo? Então… No artigo do Phil Sturgeon, ele aborda essa questão como um vazamento de “sucesso” para seus concorrentes.
Outro ponto que merece atenção é a facilidade na manipulação do ID por ele ser um número inteiro incrementado em +1, pode ser facilmente forjado alterando-se a URL.
Ainda utilizando o exemplo da tabela acima, imagine que você acesse a página para editar as informações do seu usuário, obviamente a URL seria /users/56/edit . O que acontece se um usuário “mal intencionado” alterar essa URL (/users/47/edit por exemplo) e tentar editar os dados de outro usuário? Se a aplicação em questão não tiver uma boa politica de segurança — com níveis de acesso (ACL), por exemplo — ele simplesmente irá conseguir!
Ainda nesse contexto, quer outro exemplo? Facilidade na extração de dados!
Alguém pode criar um robô (Bot, Crawler e etc…) que visite uma determinada URL, e dentro de um laço de repetição faça o incremento do ID para cada interação do laço, dessa forma o conteúdo da aplicação pode ser extraído por completo sem muito esforço…
Vantagens de utilizar UUIDs
Abaixo eu listo algumas vantagens na adoção dos UUIDs:
- Descentralização na criação de identificadores únicos.
Como o UUID segue uma especificação, você pode gera-lo independente do ambiente ou linguagem de programação.
- Facilidade na sincronização de dados.
Se sua aplicação permitir o uso Offline, você pode gerar registros a partir do cliente e armazena-los localmente. Quando sua aplicação ficar online você não terá problemas ao sincronizar os dados com o servidor, uma vez que os UUIDs são descentralizados e únicos.
- Omite a quantidade de registros criados em uma tabela.
- Dificuldade a manipulação da URL.
Aquele esquema de adicionar +1 não funciona com UUID.
Desvantagens de utilizar UUIDs
Sim! isso mesmo… No mundo da computação não existe bala de prata e nem tudo são flores. Abaixo eu cito algumas desvantagens:
- Um pouquinho mais complicado de depurar.
É mais fácil lembrar de um número 56 do que um 3d0ca315-aff9–4fc2-be61–3b76b9a2d798, por exemplo.
- Maior uso de espaço, uma vez que o UUID é 4 vezes maior.
- Menor desempenho quando armazenado como string.
Os UUIDs em sua forma textual são armazenados como campos CHAR (36) no banco de dados. Isso tem um custo de desempenho em tabelas com muitos registros, porque o BD não consegue indexar corretamente esses registros. (Uma boa alternativa é armazena-los como binários — Mas, isso é assunto pra outro post.)
Conclusão
É por esses e outros motivos que o UUID é uma ótima alternativa para criar identificadores exclusivos para seus registros, sem depender do banco de dados pra isso.
Gostaria de saber sua opinião sobre o assunto! Você já conhecia/usava os UUIDs em sua aplicação?
