Cuidado com UUID em bancos relacionais!

Vou te mostrar como utilizar UUIDs da melhor maneira
💎 Quer aprender sobre tópicos avançados de desenvolvimento e liderança? Venha para a TechLeads.club tinyurl.com/tl...
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...

[@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

[@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.

[@quilamcz]

3:17

[@gabrielrhoden2639]

90% do conteúdo do youtube é para o pessoal muito inciante. Otimo vídeo!

[@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...

[@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!

[@felipe.raposo]

Resolve não. Porque se vc apresenta o UUID para o usuário, ele vai precisar usar esse UUID para pesquisar o registro novamente. E o seu backend vai precisar encontrar o registro baseado no UUID. Então vc vai precisar indexar esse cara de alguma forma. Você vai acabar caindo nos problemas que o vídeo explica.

[@daleffi]

Fora que usar uuid como string vc está usando 32bytes ao invés de 16bytes como ele deveria ser nativamente. Não sei se é uma ideia ótima

[@WillianMattos]

​@@felipe.raposoresolve sim. Só o cara usar o id pra pesquisar e o uuid pra validar

[@rhialicandido8644]

​@@felipe.raposoSe você não possui um sistema ou aplicação grande igual ao do shopify ou do C6 bank é uma excelente ideia sim! Nem todo recurso que existe é o ideal para ser usado em todos os sistemas, o sistema em que trabalho funciona há 5 anos dessa forma com boa performance pq não possui uma base grande de dados. Abraço

[@rhialicandido8644]

​@@felipe.raposoSe você não tem um sistema igual ao C6 ou do Shopify que gera milhares de registros por dia, resolve fácil, além do mais banco de dados possui views e stored procedures para ajudar na performance! Nem toda solução que existe deve ser usada! Um abraço!

[@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.

[@daleffi]

Cara esse teu comentário tem que ser emoldurado! O que eu já vi gente armazenar uuid como string e achar que está fazendo um ótimo negócio, não está escrito no gibi

[@leandrosoares6]

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

[@gui_dev_]

Que video completo! Muito bom hein 👏🏽

[@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 👏👏👏

[@vtrgomes1]

Belo conteúdo Waldemar, há tempos sinto uma carência por conteúdos avançados. Boa!

[@marcelogrsp]

Top! Interessante demais…. Como eh bom saber os fundamentos das coisas ne

[@iannascimento913]

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

[@luizfelipeburgattjolo6578]

pesquisei agora pelo V7, ainda não conhecia! vlws!

[@ManoelJunior]

Obrigado por compartilhar conosco.

[@Afonsolelis2]

Perfeito, já virei fâ do seu trabalho!

[@Eriquen-iz8fl]

Obrigado

[@aldycolares3663]

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

[@davidmolizane]

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

[@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

[@marcosaugusto10298]

Ja trabalhei em empresa de software fiscal. Uma grande empresa de telecomunicação emite pelo ao menos 100 milhoes de notas / mes. Cada nota tem 2 ou 3 items, e cada item tem no minimo 5 impostos. E são tabelas grandes, com vários campos. Fazendo a conta chegamos na cada dos bilhões de leituras. E na época existiam (não sei se ainda estão vigentes) obrigações que tinha que gerar isso nota a nota. O UUID tem o problema da perfomance e do valor do storage, que mesmo sendo "barato" hoje em dia com esse volume de dados geraria um custo a mais ao cliente sem necessidade. Sinceramente, nunca vi ninguem usar uuid nesses casos e não arriscaria também, mesmo usando id númerico ainda era necessário particionar o banco e o DBA tinha que usar configurações especificas para melhorar a performance. Mas esses casos são exceções, hoje estou num projeto menor e uso uuid, acho que vale mais a pena pela praticidade.

[@whurys]

bacana demais

[@ursochurrasqueira]

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

[@carlotadias9335]

Muito interessante ! Obrigada !

[@evertonsales443]

Realmente, UUIDs sendo grandes e randômicos, em uma escalada de dados, tendem a ter mais consultas para achar seu lugar na árvore binária e a gravação sempre é mais custosa. Índices menores, quando muitos dados por segundo faz muita diferença, lembrando que não é só o custo de armazenamento, o tráfego de dados também aumenta muito... Pessoalmente só uso UUIDs para bancos baseados em documentos...

[@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.

[@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

[@WaldemarNetoDevLab]

Interessante, eu particularmente não gosto de usar coisas fora do padrão, colocar sufixo cria um id maior que não tem nenhum padrão, UUID é um padrão conhecido, tem várias bibliotecas. No momento que tu cria o teu ele é unico e tu tem que manter.

[@jamesortiz]

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

[@aldairavelino3188]

Bem explicado, valeu por compartilhar

[@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).

[@daleffi]

Perfeito!

[@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.

[@WaldemarNetoDevLab]

Essa é a ideia que mostro no video do uuid v7 e ULID, é melhor usar um standard pra isso porque simplesmente colocar uma data na frente do uuid tu vai criar um padrão novo e vai ser maior em termos de length.

[@danielvicentefagundes6774]

Interessante

[@viniciuspimentel8690]

Muito brabo, jamais pensaria nisso!

[@joalisonpereiradev]

Vídeo curto mas miuto informativo, valeu.

[@ericnevesr]

Excelente conteúdo, muito bom!

[@MakerVerse]

Nossa video sensacional obrigado

[@i3xi5t51]

Queria entender melhor o que seria "grande quantidade de dados". Atualmente, onde eu trabalho, o projeto existente tem algumas inconsistências em relação ao banco de dados. No geral, isso deve ter sido causado pelo fato de o banco relacional ter sido feito para emular a estrutura de um banco de graph twin, e não foi pensado da melhor forma. Percebi que tenho algumas tabelas com 4k ou 5k linhas, representando nós, e outras com 30k, apenas representando as conexões entre esses nós, sem contar algumas tabelas de dados que estão na casa dos milhões, mas não devem passar muito disso. Em absolutamente todo lugar é utilizado UUID, até onde não há uma necessidade real, mas não sei se o volume de dados é grande o suficiente para justificar uma troca. Ainda que nossas queries costumem demorar bastante, na escala dos segundos, como eu sei quando faz sentido trocar meu UUID v4 para, digamos, um UUID v7?

[@WaldemarNetoDevLab]

Interessante, teria que analisar se o problema de performance é de UUIDs no geral o impacto em queries não é tão grande. Eu assumo que o problema ai é a estrutura de gráfico que deve ter muitos joins, bom era debugar as queries, e ver se todas elas tem index.

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.

[@dantemesquita7751]

Que vídeo incrível obrigado

[@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.

[@daleffi]

​@@WaldemarNetoDevLabeu acho que as consultas sofrem sim pois se sua chave for um uuid elas vão estar mais espalhadas nas páginas de dados, consequentemente suas consultas vão ter que levantar mais páginas do cache do banco. O seu plano apresentará mais operações de I/O do que se fosse uma chave numérica.

[@YouTubeDoNatan]

Então é ruim deixar que o banco de dados crie o id automático para o usuário?

[@rafa_veiga]

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

[@Aliengrato]

❤

[@algonix11]

o uuid só faz sentido em arquitetura realmente distribuida, onde um fragmento da rede nao tem contato nenhum com as demais. e mesmo nesse cenário um random de 64bits faz o o mesmo trabalho mas com muito mais eficiencia.

[@_boraprogramar]

Existem outras abordagens como adicionar id-idbanco ou ainda deixar um serviço na frente do banco para gerar os ids sequenciais, ou separar um range de ids para cada banco

[@tiagoleomil4329]

Ganhou mais um inscrito

[@AlvesNamor]

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

[@WaldemarNetoDevLab]

O banco não precisa suportar tu vai salvar em um campo string.

[@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!

[@Pedroallesss]

mt bom!

[@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.

[@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.

[@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.

[@_boraprogramar]

Tenho 4 anos de experiência e nunca precisei usar uuid 😅

[@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.

[@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.

[@heliobras9466]

O índex não usa árvores binária, ele usa B-tree

[@FlavioAugustoToldo]

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

[@WaldemarNetoDevLab]

Pode colar um id no chatgpt e perguntar pra ele explicar

[@romulo123skate]

niceeee

[@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.

[@zkira445]

E a chave aleatória do pix? Kkk

[@infocastell]

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

[@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".