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.
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...
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.
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
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!
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.
@@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
@@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!
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.
Ó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.
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.
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...
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.
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.
@@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.
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
Também pode ser feito com o UUIDv5, que usa um algoritmo de hash já ultrapassado, mas que ainda quebra um galho, economizando alguns bytes de armazenamento.
Eu nunca achei que esse problema da árvore fosse sério. Na minha cabeça, essa estrutura de dado convertia o valor do UUID em algo como um ASCII ou qualquer outro padrão com algum método de prevenção de colisão built-in e assim colocando em ordem a árvore sem precisar reestruturar tudo. Não é pra isso que se instala um driver UUID no banco?
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
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.
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.
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
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?
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.
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.
4 месяца назад
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?
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.
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".
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.
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.
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.
Um KSUID é um UUIDv4 com a adição de um prefixo ordenável de 32 bits. Ou seja, o KSUID é um Power Ultra ID . Só que vc será obrigado a armazená-lo ou em string ou em binário, sem poder aproveitar a otimização fornecida pelos próprios bancos que têm o tipo de dados UUID nativo.
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?
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.
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).
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
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.
O UUIDv7 é lexicograficamente ordenável, tanto no formato binário (para armazenamento) como no formato de string (para apresentação para humanos). Os bancos não precisam de algoritmo de ordenação específico para o UUIDv7, embora alguns deles implementem uma ordenação especial para o UUIDv1.
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.
Haha boa, produzo o vídeo que eu gostaria de assistir 🤣🤣
Me inscrevi na hora por isso
90% do conteúdo do youtube é para o pessoal muito inciante. Otimo vídeo!
Não vou pagar já passou muitacoisa
UUID V7 e ULID, para os casos em que precisamos de performance e índices ao se trabalhar com grandes quantidades de dados.
Ia comentar isso.
3:17
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...
Conteúdo raro de excelente qualidade em menos de 5 minutos 😮
Belo conteúdo Waldemar, há tempos sinto uma carência por conteúdos avançados. Boa!
Cara, que explicação incrível. Obrigado e muito sucesso.
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.
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
@@daleffi se eu fosse mais apressado teria feito essa cagada
muito bom, por mais vídeos assim, técnicos , objetivos, dando uma visão geral com soluções, desses desafios que temos nos projetos 👏👏👏
Obrigado por compartilhar conosco.
pesquisei agora pelo V7, ainda não conhecia! vlws!
Que video completo! Muito bom hein 👏🏽
Conteúdo de simples comunicação e rico em conhecimento, obrigado pelo vídeo mano
Parabéns pelo conteúdo direto ao ponto, ainda mais pra nós de tecnologia que não gostamos de enrolação hahaha
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!
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.
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
@@felipe.raposoresolve sim. Só o cara usar o id pra pesquisar e o uuid pra validar
@@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
@@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!
Bom conhecimento. Vou ver outros vídeos já que tu falou que aborda assuntos avançados.
Top! Interessante demais…. Como eh bom saber os fundamentos das coisas ne
Perfeito, já virei fâ do seu trabalho!
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.
Ótima informação, vai ajudar muito, obrigado!
Bem explicado, valeu por compartilhar
Muito interessante ! Obrigada !
tem o snowflake id criado pelo twitter, ainda não cheguei a usar mas parece interessante
Obrigado
Vídeo curto mas miuto informativo, valeu.
Ó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.
Valeu Robson! Na verdade na query não tem problema de ele ser randômico. Não interfere em nada.
Excelente conteúdo, muito bom!
Muito brabo, jamais pensaria nisso!
bacana demais
Nossa video sensacional obrigado
Que vídeo incrível obrigado
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.
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.
INT Sequencial pra relacionamentos e indices e ULID pra external_id
Interessante
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...
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.
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.
@@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.
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
Também pode ser feito com o UUIDv5, que usa um algoritmo de hash já ultrapassado, mas que ainda quebra um galho, economizando alguns bytes de armazenamento.
Ganhou mais um inscrito
Tenho 4 anos de experiência e nunca precisei usar uuid 😅
Eu nunca achei que esse problema da árvore fosse sério. Na minha cabeça, essa estrutura de dado convertia o valor do UUID em algo como um ASCII ou qualquer outro padrão com algum método de prevenção de colisão built-in e assim colocando em ordem a árvore sem precisar reestruturar tudo. Não é pra isso que se instala um driver UUID no banco?
❤
Confesso que fiquei mto tempo parado usando o uuid v4, as próximas vou usar o v7 pra ver a diferença.
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
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.
mt bom!
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.
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
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?
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.
E quais bancos de dados tem suporte a UUID v7 sabendo da ordenação temporal?
O banco não precisa suportar tu vai salvar em um campo string.
como saber qual a versão está sendo usada?
Pode colar um id no chatgpt e perguntar pra ele explicar
É só você pegar um UUID que foi gerado e olhar qual é o dígito após o segundo hífen. Se for 4, será um UUIDv4; se for 7, será um UUIDv7.
tem como fazer isso depois q já tem um banco de dados só com uuids ?
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.
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?
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.
niceeee
Então é ruim deixar que o banco de dados crie o id automático para o usuário?
a questão é que o auto incremento do banco vai gerar id's sequenciais, no video ele diz os problemas de fazer dessa maneira...
Legal, não sabia disso. Já salvei. Valeu!
No postgres vocês usam a extensão do ulid? Ou criam ele na camada de app e armazenam como uuid mesmo?
Sempre criei no app, para não depender muito do banco para isso.
@@WaldemarNetoDevLab boa, também acho mais fácil. Abraço e parabéns pelo vídeo!
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".
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.
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.
Setar o indice pra usar hash já não resolve o problema ?
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.
Dúvida o KSUID é uma boa solução?
Nunca testei mas é um padrão estável, acho que é uma opção valida.
Um KSUID é um UUIDv4 com a adição de um prefixo ordenável de 32 bits. Ou seja, o KSUID é um Power Ultra ID . Só que vc será obrigado a armazená-lo ou em string ou em binário, sem poder aproveitar a otimização fornecida pelos próprios bancos que têm o tipo de dados UUID nativo.
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?
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.
O índex não usa árvores binária, ele usa B-tree
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).
Perfeito!
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
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.
O UUIDv7 é lexicograficamente ordenável, tanto no formato binário (para armazenamento) como no formato de string (para apresentação para humanos). Os bancos não precisam de algoritmo de ordenação específico para o UUIDv7, embora alguns deles implementem uma ordenação especial para o UUIDv1.
Se eu não usar nada o problema é menor kkk
E a chave aleatória do pix? Kkk
É um UUIDv4.