Cuidado com UUID em bancos relacionais!

💎 Quer aprender tópicos avançados de desenvolvimento e liderança? Venha para a TechLeads.club comece.techlea...
UUIDs podem causar um grande impacto negativo no desempenho de bancos de dados relacionais como MySQL e PostgreSQL devido a sua natureza randômica.
Nesse vídeo eu explico porque UUIDs são problemáticos e quais as melhores opções para resolver esse problema.
🔗 Links
- planetscale.co...
- shopify.engine...

[@cardeal1389]

UUID V7 e ULID, para os casos em que precisamos de performance e índices ao se trabalhar com grandes quantidades de dados.

[@yetanothercoder]

Ia comentar isso.

[@allandasilvaa]

Que ótimo, foi o que eu imaginei.

[@leandrosoares6]

Conteúdo raro de excelente qualidade em menos de 5 minutos 😮

[@viniciusvasques4015]

Poderia ser um vídeo de 10+ minutos de sensacionalismo porém entregou todo conteúdo em menos de 5 com qualidade. Isso que é respeitar o tempo do próximo, perfeito.

[@WaldemarNetoDevLab]

Haha boa, produzo o vídeo que eu gostaria de assistir 🤣🤣

[@geandresm]

Me inscrevi na hora por isso

[@rhialicandido8644]

Eu uso o ID com o index e o UUID como string, varchar, quando retorno os dados para o usuário eu escondo o ID e apresento apenas o UUID em tela, isso já resolve o meu problema ehehee!

[@iannascimento913]

Parabéns pelo conteúdo direto ao ponto, ainda mais pra nós de tecnologia que não gostamos de enrolação hahaha

[@FábioLima-h7k]

Muito bom! Resume toda a questão e apresenta uma solução. Apenas faltou dizer que é preferível persistir o ULID/UUIDv7 como UUID/GUID (quando suportado pelo BD) ou binário (quando não). As pessoas tendem a associar UUID com uma string, quando na verdade é um número.

[@ManoelJunior]

Obrigado por compartilhar conosco.

[@aldycolares3663]

Bom conhecimento. Vou ver outros vídeos já que tu falou que aborda assuntos avançados.

[@dami-i]

Esse tipo de conteúdo é bem bacana. Embora fiquei perdido algumas vezes por conta da pronúncia do termo "UUID" se confundir com "o ID". Seria mais fácil de fazer a distinção se fosse usada a pronúncia em inglês "you you ID".

[@JRRRRRRRRRRR]

muito bom, por mais vídeos assim, técnicos , objetivos, dando uma visão geral com soluções, desses desafios que temos nos projetos 👏👏👏

[@Afonsolelis2]

Perfeito, já virei fâ do seu trabalho!

[@shift564]

muito bom o conteúdo, deixou claro que isso é preocupação de grande escala, sobre storage, hoje vejo JR se preocupando com storage sendo que o guri não tem 100 usuário na plataforma...

[@ursochurrasqueira]

tem o snowflake id criado pelo twitter, ainda não cheguei a usar mas parece interessante

[@weller781]

Uma solução que encontrei para ter um hash e o Id sequencial foi: fazer a coluna id auto incrementada e ao ter o dado já persistido no banco, pegar esse id gerado automaticamente e transformar ele em hash usando SHA256 e fazer o update na coluna x que salva o hash, para o front mando esse hash correspondente ao Id sequencial. Na época que implementei essa lógica eu sabia pouco sobre bancos e não queria ter o Id sequencial no front justamente para evitar que o usuário burlasse os dados exibidos. Achei meio gambiarra mas foi uma solução que está servindo bem rsrs

[@davidmolizane]

Conteúdo de simples comunicação e rico em conhecimento, obrigado pelo vídeo mano

[@adeonir]

Ótima explicação.
Eu cheguei a usar CUID em algumas aplicações, ele também é ordenável e ocupa menos espaço por ser mais curto.

[@gabrieljose7041]

Muito bom o vídeo parabéns!! Me conta aí oq tu acha de prefixo ou sufixo de IDs? Eu tenho tentado adotar isso em projetos com muitas entidades e principalmente quando tem muitas entidades relacionadas a um fluxo só, fica mais simples de saber a quem aquele ID se refere

[@carlotadias9335]

Muito interessante ! Obrigada !

[@aldairavelino3188]

Bem explicado, valeu por compartilhar

[@jamesortiz]

Ótima informação, vai ajudar muito, obrigado!

[@polvoazul]

Uma vantagem: com UUID v4 vc pode gerar novas chaves direto no cliente, sem precisar falar com o banco, salvando um roundtrip em alguns casos.
Uma desvantagem: UUID sendo maior, vc gasta mais storage, o q nao eh mt relevante, mas o seus indexes ficam maiores (pq em geral vc vai ter index em ids), e ae vao caber menos no cache de memoria, e isso pode sim ter um impacto relevante em performance (pq memoria nao eh tao barato assim).

[@joalisonpereiradev]

Vídeo curto mas miuto informativo, valeu.

[@viniciuspimentel8690]

Muito brabo, jamais pensaria nisso!

[@rft13hk]

Uma opção que usamos é criar uma chave composta de um campo date + UUID, assim o índice só precisa percorrer a chave da data do dia da gravação.

[@ericnevesr]

Excelente conteúdo, muito bom!

[@RobsonFeDev]

Ótimo conteúdo, parabéns!! Também me proecupo bastante com a performance do banco, só que ao mesmo tempo voce tem que se atentar a segurança, eu ainda não utilizei esses UUID mencionados, mas sempre pensei que pelo uuid padrão ser muito randômico, ele não é uma escolha ideal para aplicações grandes, realizar query de grande volume de dados.

[@WaldemarNetoDevLab]

Valeu Robson! Na verdade na query não tem problema de ele ser randômico. Não interfere em nada.

[@dantemesquita7751]

Que vídeo incrível obrigado

[@MakerVerse]

Nossa video sensacional obrigado

[@AlvesNamor]

E quais bancos de dados tem suporte a UUID v7 sabendo da ordenação temporal?

[@FlavioAugustoToldo]

como saber qual a versão está sendo usada?

[@tiagoleomil4329]

Ganhou mais um inscrito

[@rafa_veiga]

Confesso que fiquei mto tempo parado usando o uuid v4, as próximas vou usar o v7 pra ver a diferença.

[@Pedroallesss]

mt bom!

Muito bom o vídeo!
Esse caráter de aleatoriedade impacta, de fato, o índice do tipo b-tree. Mas se utilizarmos o tipo de índice hash, não mitigamos o problema?
Ficaremos limitados a operação de match exato, mas que parece ser o normal quando estamos falando de chave primária e de UUID.
Acha válido?

[@WaldemarNetoDevLab]

Bom ponto! Problema do hash é que ele é chave e valor e é limitado comparado ao b-tree e também quando testei o MySQL, por exemplo, não suportava hash para chaves primarias.

[@oazevedolucas]

Cara eu tenho uma dúvida. Se eu vou trabalhar com grande quantidade de usuarios exemplo +1milhão, não chega um ponto que extoura o maior número possível?

[@HumbertoRamosCosta]

1 milhão de registros em bancos de dados hoje é trivial
Mesmo que você delete e crie outros registros é praticamente impossível ultrapassar o espaço amostral tanto do UID quanto da chave sequencial.

[@infocastell]

Legal, não sabia disso. Já salvei. Valeu!

[@RenanMiranda-c1o]

já escutei isso algumas vezes, porém não concordo muito...
a complexidade de inserção de um elemento em uma árvore binária balanceada, é O(Log(N)), independente se é randomico ou ordenado, internamente ele vai comparar um UUID com outro da mesma forma que um número é comparado, para jogar ele para esquerda ou direita em cada nível da árvore.
mesmo que o banco aproveitasse o fato de ser sequencial para não criar uma árvore e sim algo próximo a uma lista bulkerizada ordenada, onde a complexidade de insert seria O(1) (o que desconheço que ele faça), o UUID vai ter que ter um indice de qualquer forma, para buscar pela chave, na maioria das vezes um campo de código desses não fica sem indice, dessa forma a complexidade do insert não vai mudar mesmo você tendo uma PK numérica.
Vai haver uma melhoria nos JOINS, porque que individualmente comparar um uuid com outro é mais custoso do que comparar um número com outro, devido a quantidade de bits de um uuid ser muito superior, contudo é uma diferença constante na complexidade, não é linear, nem exponencial, o que não deveria ser um grande problema na prática. (tanto a consulta por UUID numa BTREE quanto a por Numero tem complexidade O(Log(N)))
convivo com aplicações que lidam com grandes quantidades de dados e requisições e trabalham com UUID na chave, e esse nunca foi o problema, o tempo das queries costuma ser semelhante a de aplicações que tenho com volume de dados parecido e chave numérica, por ser uma diferença constante de performance, não linear nem exponencial, costuma ser pouco perceptivel, o que mais costuma fazer diferença é o plano de execução das consultas, e ter os indices criados corretamente para cada situação.
Fora isso a complexidade de gerar um numero auto increment é maior que gerar um UUID, você precisa de um mecanismo de sequence para isso, que geralmente não é escalavel, porque que é um mecanismo thread-safe para geração de números sequenciais, contudo, para ele ser thread-safe, precisa sincronizar a operação, ou seja, todas as threads da sua aplicação em todas as instancias que ela tiver rodando, vão ter que aguardar uma a outra, para geração desse id numérico.
Mas assim, concordo que há de fato uma melhora constante nas operações de consulta, mas pra min nunca justificou a troca, trabalho com microsserviços que fazem centenas de milhares de consultas ao banco por minuto, com centenas de milhões de dados em banco, e nunca tive problema com isso.
Talvez se for um cenário super extremo, com bilhões de dados, e milhões de consultas por minuto, esse tipo de otimização começe a fazer uma diferença maior, mas vejo que é a minoria dos casos.

[@WaldemarNetoDevLab]

Massa teu ponto Renan, tu já fez benchmarks de escrita? Atualmente estou trabalhando em um SaaS multi tenant com milhares de dados e os benchmakrs de escrita diferem bastante quando movemos de uuid v4 para v7 em operações de escrita que precisam mexer no index. Sobre query eu nem mencionei porquê o impacto é realmente minimo.

[@jeffersonsilva763]

Gostaria de saber como isso iria implicar em um banco de dados de escrita escalando na horizontal, recebendo multiplas inserções no mesmo milisegundos em uma alta demanda. Pois o twitter usa o "Snowflake" pra resolver esse problema.

[@WaldemarNetoDevLab]

Massa Jefferson, em termos de escrita não tem problema nenhum. O Twitter usa o snowflake porquê ele é menor e também não tinham muitos padrões ordenáveis no passado.

[@kelvincesar_]

No postgres vocês usam a extensão do ulid? Ou criam ele na camada de app e armazenam como uuid mesmo?

[@WaldemarNetoDevLab]

Sempre criei no app, para não depender muito do banco para isso.

[@kelvincesar_]

@@WaldemarNetoDevLab boa, também acho mais fácil. Abraço e parabéns pelo vídeo!

[@VictorHenrique17]

Setar o indice pra usar hash já não resolve o problema ?

[@WaldemarNetoDevLab]

Bom ponto! Problema do hash é que ele é chave e valor e é limitado comparado ao b-tree e também quando testei o MySQL, por exemplo, não suportava hash para chaves primarias.

[@zkira445]

E a chave aleatória do pix? Kkk

[@cleitinho-dev]

Dúvida o KSUID é uma boa solução?

[@WaldemarNetoDevLab]

Nunca testei mas é um padrão estável, acho que é uma opção valida.

[@joonasalb]

Dúvida, como o banco sabe lidar com a ordenação de acordo com caracteres? como que esse sabe que esse cara por exemplo: 018aab68-d2dd-78f1.. é antes do 018aab68-d2dd-78f2?
Por que eu digo, como o UUID é aleatório, ele acaba ordenadando mesmo assim porém a ordenação acabaria estando errado? kkkkkk fiquei muito nessa dúvida

[@WaldemarNetoDevLab]

Essa é uma ótima pergunta, como o timestamp está no início, comparar duas strings de UUID v7 em ordem lexicográfica (alfabética) reflete a ordem temporal em que foram geradas. Índices B-Tree utilizam a ordem lexicográfica das chaves para organizar os dados. Portanto, UUIDs v7 se beneficiam diretamente dessa característica, permitindo buscas e ordenações eficientes.

[@Kimitri]

tem como fazer isso depois q já tem um banco de dados só com uuids ?

[@WaldemarNetoDevLab]

Puts, ai da trabalho, tem que atualizar todos os relacionamentos, e se existem sistemas externos que dependem dos dados e salvam o id no lado deles vai ser bem dificil.

[@romulo123skate]

niceeee