rponte/using-uuid-as-pk.md

## using-uuid-as-pk.md

      
    Raw
  

              using-uuid-as-pk.md
            
          
    Pretende usar UUID como PK em vez de Int/BigInt no seu banco de dados? Pense novamente...

TL;TD

Não use UUID como PK nas tabelas do seu banco de dados.
Um pouco mais de detalhes

Usar UUID como tipo numa PK (Primary Key) em vez de Int/BigInt em bancos de dados relacionais (RDBMS) parece ter se tornado comum em aplicações nesse mundo de APIs REST, microsserviços e sistemas distribuídos, afinal temos algumas boas vantagens nessa abordagem:

segurança: IDs opacos para expor em APIs REST;
geração de IDs descentralizados: assim browsers, clients e serviços, apps mobile e outros bancos podem gerar IDs únicos;
ideal em DBs distribuídos ou com múltiplos nodes de escrita;
são ótimos para tabelas temporárias ou ao fazer merge entre bancos;
super útil em migração entre DBs (evita colisão);
seu uso em batch processing pode melhorar substancialmente o throughput;
comuns em cenários de replicação de dados;

Vantagens existem e são várias, especialmente em cenários distribuídos, mas há um custo: impacto direto na escrita e na leitura do seu banco de dados.
Apesar desse custo depender de N fatores como banco de dados e versão utilizada, setup e tuning, workload, hardware etc, não dá para ignorar que ao usar UUID como PK nós estamos tentando resolver um problema de 4 bytes (32 bits) com 16 bytes (128 bits)! É 4x mais problema para inserir, ler e armazenar!
Conhecer e entender as principais devantagens (trade-offs) é importante antes de bater o martelo. A verdade, é que praticamente todos os RDBMS modernos apresentam algum tipo de problema ou limitação no uso de UUID como PK, apesar da maioria destes problemas poderem ser contornados ou minimizados através de analise, setup ou tuning apropriado. E é justamente nesse momento de fazer essa analise e tuning que o papel de um DBA no time brilha.
Para não me alongar mais, segue alguns desses trade-offs:

requer maior espaço em disco;
compromete o buffer de memoria para tabela de indexes;
UUID não são ordenáveis (embora existam specs e implementações para tal, como a ULID);
maioria dos servidores são 64 bits: UUID são chaves de 128 bits, logo precisam de no minimo 2 ciclos de CPU para serem processadas;
pode piorar? claro, basta armazenar seu o UUID como texto no banco;
PostgreSQL e impacto na escrita e leitura;
PostgreSQL e Write Amplification;
MySQL e clustered indexes;
MS SQL Server e clustered indexes (sofre do mesmo mal do MySQL);
Oracle e impacto de performance;

O problema não é o uso do tipo UUID em si, mas sim utilizá-lo como chave primária em tabelas do banco de dados. O que estou querendo dizer, é que, desenhar uma feature seguindo deliberadamente essa abordagem costuma ser responsável e fazer muito sentido, mas adotá-la cegamente para TODAS as tabelas do seu schema é muito perigoso!
Muitas vezes, esse tipo de design é utilizado como um "shortcut" (atalho) para facilitar a vida dos devs na hora de expor suas entidades em APIs REST, mas que joga todo o onus da manutenção para o time de infra, DBAs e muitas vezes para própria empresa, como comprar mais disco ou substituir hardware. Além disso, um ID opaco só resolve parte do problema de segurança, pois ainda se faz necessário validações de acesso e propriedade dos dados, que geralmente é a parte mais chata de se implementar.
Não me entenda errado, não é que esse tipo de solução não funcione, ela vai funcionar, mas como meu amigo Raul Oliveira me disse uma vez:

Eh como fazer caminhada plantando bananeira. Da pra fazer, vai concluir, gastar mais energia. Mas eh uma boa ideia?

Perceba que é muito fácil enumerar as vantagens das tecnologias e no uso de técnicas, pois elas estão escancaradas em todos os lugares. Mas na minha opinião, um bom arquiteto(a) ou dev(a) senior não escolhe tecnologias apenas por suas vantagens, mas principalmente por suas desvantagens. Ele(a) precisa saber o que está perdendo ao tomar uma decisão!
Contudo, é dificil entender e pesar o custo e impacto das desvantagens sem um contexto, por isso...
Contextos importam

Em 2012 o Instagram precisou distriuir seu banco de dados (fazer sharding) para melhorar performance e throughput do site, e, em vez de adotar UUID eles resolveram criar um próprio ID de 64bits. Eles não fizeram isso à toa, eles estavam cientes do custo imposto pelo uso de UUID na epoca e dentro do contexto deles.
Um pouco antes, em 2010, o Twitter também precisou gerar IDs únicos entre suas instâncias de MySQL e o banco de dados Cassandra, e para isso optou por um serviço distribuído de geração de IDs, que por sinal foi criado por eles e recebeu o nome de Snowflake. Assim como o Instagram, a equipe do Twitter seguiu por esse caminho pois era importante que os IDs gerados fossem ordenáveis e tivessem o tamanho de 64 bits.
Nesse mundo de microsserviços e sistemas distribuídos, geralmente cada serviço possui um banco isolado e independente que possui um schema pequeno, enxuto e com baixa volumetria de dados, o que acaba por minimizar as chances de problemas ao adotar UUID como PK! Afinal, o estilo arquitetural escolhido já distribui por natureza a massa de dados entre as dezenas ou milhares de serviços. Mas não se engane, se há chances do volume de dados crescer em um intervalo curto de tempo então talvez seja melhor refletir e discutir com seu DBA sobre sua adoção.
Em muitos cenários, nem todas as tabelas precisam ser expostas para sistemas externos, portanto ao adotar UUID como PK atente-se a dar preferência somente às tabelas que precisam mostrar a cara pro mundo a fora, dessa forma minimiza-se o impacto no restante do sistema.
Favoreça um modelo hibrido

Nem oito nem oitenta, já dizia minha mãe.
Na minha opinião, se possível, favoreça o uso de Int/BigInt para IDs internos do banco de dados (PKs e FKs), e use uma coluna do tipo UUID como ID externo (por exemplo external_id). Essa forma hibrida possibilita que seu sistema continue tirando o melhor proveito do seu RDBMS ao mesmo tempo que possibilita ter um ID opaco (segurança).
Essa abordagem não só minimiza o impacto no uso de UUID como também oferece vantagens interessantes:

permite ter um ID opaco para expor em APIs REST;
não precisamos necessariamente de um index na coluna;
podemos usar um index do tipo HASH em vez de BTREE (funciona melhor para queries de comparação por igualdade);
não “espalhamos” o UUID pelas FKs de outras tabelas;
ocupamos menos espaço em disco e memoria, afinal os indices param de referenciar UUIDs;
com menos dados conseguimos operar nosso workload em memoria (e isso por si só já é uma melhoria brutal);
podemos fazer tuning apropriado na coluna de acordo com nosso workload;
permitimos que o banco trabalhe melhor via PK/FK sequencial em JOINs, agregações e ordenações;
excelente para schemas existentes ou legados;

Provavelmente existem outras vantagens nessa abordagem, mas meu pouco conhecimento sobre RDBMS não me permite pensar mais longe nesse momento. De qualquer forma, não esqueça de consultar seu DBA, fazer alguns testes de carga e entender os limites da sua aplicação!
Concluindo

Provavelmente eu falei alguma groselha, então não se acanhe em me corrigir ou dar um toque!
Embora eu tenha sugerido o modelo hibrido, você não precisa adotá-lo ou mesmo considerar que usar UUID como PK seja errado, pois não é! Se está funcionando para você então está tudo bem, continue utilizando, afinal no seu contexto fez (e ainda faz) sentido seguir essa abordagem. O importante aqui é que os trade-offs estejam claros em cima da mesa, caso contrário em algum momento eles podem voltar para assombrar você e sua equipe!
Acredito que existem outras vantagens e desvantagens na adoção de UUID como chave primária, afinal esse tipo de problema não é de hoje, então, caso você lembre de mais algum pró ou mesmo contra, ou um outro contexto interessante não deixe de comentar e compartilhar sua experiência. Com certeza eu posso aprender muito mais e melhor com a sua experiência e de outros.
Enfim, resolvi escrever esse gist por causa dessa thread no twitter e para ajudar o "Rafael do futuro"a não esquecer detalhes sobre este tópico!
Feature	Auto-incr. Integers	UUIDs	TSIDs
Key Type	Variable size integer	128-bit integer	64-bit integer
Uniqueness	Unique within a database	Universally unique	Unique across nodes
Predictability	Predictable sequence	Unpredictable	Unpredictable
Space Efficiency	High(small size)	Low(large size)	Moderate(larger than integers but smaller than UUIDs)
Data locality	High(sequential increment)	Low(random order)	High(time-sorted with random component)
Performance	High(efficient indexing, inserts, reads)	Poor(inefficient inserts, scattered indexes, read penalty)	High(similar to integers)
Readability	High(simple numbers)	Low(32 character strings)	Moderate(13 character strings)
Chronological Sorting	Yes, implicit(based on sequence)	No inherent order	Yes, time-sorted(based on time component)
Multi-node Generation	Not feasible	Easily feasible	Feasible with node IDs
Security (Inference Risk)	High(German Tank Problem)	Low(no inference)	Low(no inference)
Ease of Implementation	High(natively supported)	Moderate(varies by database)	Low(least support, requires function implementation, managing node IDs)
Scalability	Varies(limited by integer type)	High(no practical limit)	High(at least ~70 years, limited by timestamp size)
Migration Flexibility	Moderate(can change to larger integer type)	Low(hard to change key type)	High(drop-in compatible with integers)