Melhor estratégia de IDs para seu próximo app (UUID ou autoincrement?)

Подписаться 362 тыс.

Просмотров 26 тыс.

50% 1

Quanto mais informações eu preciso armazenar e lidar dentro da minha aplicação, maior vai ser o banco de dados dela, e tudo isso impacta no preço que se paga para manter o armazenamento desses dados.
Dependendo do tamanho e estilo do seu projeto, existem algumas estratégias de ID que podem ajudar a diminuir esse número e ainda ser mais efetivas para o seu resultado, inclusive coisas como paginação.
Nesse vídeo vou trazer uma estratégia bem conhecida, desenvolvida pelo Twitter/X, mas também algumas alternativas mais acessíveis, já que dificilmente seu app vai ser do tamanho de um Twitter ou Instagram, por exemplo.
-----
Conecte-se a 500mil devs e avance para o próximo nível com a nossa plataforma: rocketseat.com.br/
Cadastre-se na nossa plataforma: app.rocketseat.com.br/signup
Junte-se a mais de 392mil devs em nossa comunidade no Discord: / discord
Acompanhe a Rocketseat nas redes sociais:
Twitter: @rocketseat
Facebook: @rocketseat
Instagram: @rocketseat

Опубликовано:

14 май 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 82

@RafaelDailySantosMartins 14 дней назад

Simplesmente uma AULA de sistemas distribuidos. Ótimo conteúdo. Esse nível de conhecimento eu só fui ter na faculdade e raramente vejo em português na internet.

@thiagosilvaloopes 9 дней назад

Sim. Por isso que os caras da Rocketseat são sensacionais, muito conteúdo gratuito, com extrema qualidade 🥳🎉

@nickolassilva8994 16 дней назад

Adorei este conteúdo, IDs era uma das coisas que mais me quebravam a cabeça na questão de performance e aplicabilidade. Eu realmente não encontrei outro vídeo igual a este. Esse conteúdo que o diegão fez tem um baita valor. Parabéns, DIegão. Baita aula

@raimundoclessyo8943 14 дней назад

Simplesmente facinante ❤. Entrega muito contéudo em um único vídeo e o melhor totalmente grátis

@eorafasantos 11 дней назад

Simplesmente gratificante entrar aqui e ter esse tipo de conteúdo pra consumir. Fico feliz de estar na Rocket e poder entender e conectar esses conteudos com meu aprendizado atual. Começando a construir minhas bases. Sensacional ❤❤

@daniellimae 11 дней назад

esse video ficou mt bom, esses cortes facilitou mt assistir ao video

@podcastcafecomrafa 15 дней назад

Curti muito Diego, acho que a Rocket ganha muito se começar a trazer pra cá mais conteúdos fundamentais não específicos de uma linguagem.

@LeandroSantiagoGomes 3 дня назад

a partir do momento que você precisa fazer um SORT vc já acaba com a condição de "ordenável" da chave ID, afinal você obrigatoriamente vai aplicar uma ordenação por um campo no bd, e pra isso existe indexes

@rodrigoaraujo1608 8 дней назад

Que conteúdo foda, me tirou várias dúvidas !

@edu_sdorneles 16 дней назад

Que vídeo RICO em informações, muito massa!!!

@eduardopalhares3526 15 дней назад

Que conteúdo de altíssimo nível 👏

@georgebezerra8863 16 дней назад

Cara muito bom esse conteúdo !!!!!

@reginaldosnunes 16 дней назад

Muito bom, interessante e direto ao ponto.

@TrickUltimatefull 11 дней назад

Simplesmente genial! 🙌

@devarthurreis 16 дней назад

Aula perfeita

@devcoelho 16 дней назад

Sei q o vídeo e sobre bancos relacionais e tal, mas qual sua opinião sobre o ObjectId do MongoDB? Será q ele é suficiente pra grandes projetos como um Twitter da vida, ou teríamos q usar um SnowflakeID também?

@ronalddurand2680 16 дней назад

valeu Diego pela info top de mais

@GabrielOliveira-nj9qg 9 дней назад

Por favor Diegão, traz mais conteúdos técnicos como esse

@vinybas 9 дней назад

Criei recentemente uma aplicação, e, na hora de discutir a estratégia de Id (as legadas usavam Identity/auto-increment, eu queria usar Guid), o DBA implicou com o Guid dizendo que, o fato dele não ser ordenável, traria uma perda de performance muito grande no BD. Acabei recorrendo ao ULID, tem suas desvantagens, principalmente por não ser muito popular, mas atendeu muito bem ao projeto. Dei uma olhada no snowflake mas o custo de implementação não valeria a pena.

@gabrielmedeiros9806 15 дней назад

Uma dúvida, mas se eu usar a opção where para fazer a paginação com o id não corre o risco de repetir o dado, pois algum desse registro pode ser apagado e essa sequência ser quebrada?

@ageurodriguesdeoliveira8953 13 дней назад

Muito bom, eu nem sabia desses problemas que podem ter. Ou seja nunca fiz uma aplicação que tem inserções absurdas

@engroga 9 дней назад

2:45 substituir o offset por comparação com id numérico? E se os ids não forem contíguos? 🤔

@rhkina 16 дней назад

Não sei se a solução de pegar os últimos registros a partir da ordem dos registros funciona... E se já houver registros deletados? Mas, com certeza, o espaço ocupado e o tempo de processamento contam bastante a favor do auto incremento. Tem uma boa explicação do problema de se usar uuid no vídeo do Theo (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-a-K2C3sf1_Q.htmlsi=_NNKfuFI5o-x9jxz). Ele sugere o uso do nanoid.

@VictorTorresOficial 9 дней назад

Funciona porque é um cursor. Se tiver registro apagado depois do where id > ponteiro, o banco de dados vai contar normalmente apenas os registros que ele encontrou, retornando ao atingir o valor definido no limit ou ao esgotar as linhas da tabela. O cursor é apenas uma referência de onde você parou na última página, um ponto de partida.

@rvian4 15 дней назад

Vale adicionar que os uuid dao uma quebrada em index clusterizadas. Sql server tem o global uniqueidentifier que da uma mitigada nisso

@user-ry8nk8yi8q 16 дней назад

cara qual app é esse q ele usa pra fazer notas e navegar ao mesmo tempo?

@sedraccalupeteca5769 12 дней назад

Eu utilizo uuid, na maioria das vezes faço API, eu ordeno com created_at (já tive caso de ter encontrado o registro com mesmo timestamp), e para minimizar os registros da db utilizo multitenancy a nível de base dados (não seja tanta vantagens em fazer a nível de tabelas), de modo mais mecânico como a fazer backup de informações antigas e depois apago.

@Iacapuca 15 дней назад

Você pode usar UUID e Incremental ao mesmo tempo. Usa o incremental como sua primary key e cria uma coluna para o uuid como por exemplo "external_refid", dai tu passa a usar o refid para tudo o que precisar fora do seu backend. Isso é util para não expor o incremental ao mesmo tempo que você tem as vantagens dele

@GabrielOliveira-nj9qg 9 дней назад

5:29

@LuizGustavo-km1yb 10 дней назад

kct, esse conteúdo foi foda

@gabrielaltran 14 дней назад

Entendi alguma coisa que o Diego disse? Com certeza não, mas a didática e a forma de explicar é sensacional

@CarlosEduardo-we7gb 15 дней назад

Eu aqui me perguntando como que faz uma paginação, e o Daniel explicando isso no vídeo também, xô correr ali pro meu Backend rapidin hahahaha

@yuur1440 14 дней назад

Onde é feito essas lives?

@kenjiutaka 13 дней назад

Alguém tem um exemplo de cursor based pagination usando ulid ou outro id time sortable? Tentei mas n consegui 😅

@Matheus-qv7yw 15 дней назад

baita aula

@pedroenrique6783 16 дней назад

Qual essa ferramenta que ele usa para digitar na tela alguém sabe ? 😅

@reinheimermat 15 дней назад

Alguém sabe dizer onde o Diego grava essas lives?

@williamroger9375 16 дней назад

Galera por favor, me respondam onde é e quando acontecem essas lives de onde tiram esses cortes?

@devgustavovasquez 16 дней назад

poderiam avisar por email/insta, as notificações da twitch não chegam para mim

@ivambergsilva591 16 дней назад

Na Twitch, pow. No canal dele. É avisado no discord, toda vez

@Carlos72639 15 дней назад

Qual é o canal dele?@@ivambergsilva591

@williamroger9375 14 дней назад

@@ivambergsilva591 Valeu mano, eu não tenho o hábito de usar muito o discord, raramente acessso, mas essas lives do Diego eu quero muito ficar acompanhando então vou seguir ele lá na Twitch também, muito obrigado!

@AlexandredeCarli 14 дней назад

Bem, acredito que houve uma simplificação ingênua na comparação de que a diferença entre armazenar um integer ocupa menos espaço que uma string. Vários bancos de dados relacionais reservam espaço em disco sobre o tamanho da página que o registro ocupa, e não necessariamente o que está escrito dentro da página, portanto é uma falácia dizer que necessariamente por ter dados inteiros ou texto vão ocupar mais ou menos espaço. Espero que isso leve a mais pessoas pesquisarem sobre o tema (:

@fernandomoraes2325 14 дней назад

Considerações: - Existem variações do UUID, e a versão 4 é ordenável. - Indiferente de conter ou não na url um id amigável, é seu dever no backend fazer a segurança do acesso - Para a maioria gigantesca das aplicações o custo extra de um id maior (tamanho de banco e etc) nunca será um problema

@thiagoteles8963 12 дней назад

vc pode criptografar o id, para usuario e no backend descriptografa e busca os dados necessarios , uso assim no laravel fica a mesma coisa no banco de dados e o usuario sempre irá ver criptografado

@ElVen1x 10 дней назад

Mas ainda vai ter problemas de legibilidade e caso tu precise de alguma forma encontrar essa informação, tu vai ter que ter acesso a chave secreta da criptografia

@etni_dev 15 дней назад

o custo computacional de se criar um id é assim tão relevante? O snow flake parece bem completo, precisamos de tantas soluções? Me parece que criar uma coluna para ordenação é mais interessante, é mais simples e o custo computacional não é assim tão alto, mas não colocaria o nome de public_id, ter 2 ids parece confuso

@juniormartinxo 16 дней назад

Bom vídeo. Eu, particularmente, gosto muito de uuid, pois já tive que fazer junção de dados com sequence e foi um BO enorme trabalhar um monte de ID igual. No final tive que reescrever as chaves... loucura! Bacana mostrar Snowflake ID e semelhantes, mas na minha opinião, "created_at" com timestamp(3) já torna o campo suficientemente ordenável para a maioria das aplicações.

@vitvitvitvitvitvitvitvit 16 дней назад

com timestamp(3) não aconteceria o problema que diego disse? eu só fiz site interno e sempre uso id auto incremental mesmo por ser mais fácil.

@juniormartinxo 16 дней назад

@@vitvitvitvitvitvitvitvit cara, muito difícil de acontecer em uma aplicação comum pois as datas são persistidas com milissegundos, saca este exemplo real (2024-04-19 01:08:48.277 e 2024-04-19 01:08:48.688), repara a casa dos milissegundos (277 e 688). Estes dados foram inseridos juntos e ainda assim deu uma diferença grande.

@juniormartinxo 15 дней назад

@@vitvitvitvitvitvitvitvit sim, pois a data é persistida com milissegundos.

@lucascaton 14 дней назад

É muito raro, quase impossível. O timestamp do PostgreSQL já tem resolução em nanosegundos 🙂

@eliseumds 9 дней назад

Eu sei que é natural pensar que daria pra fazer paginação desse jeito aí (id > 980), mas na realidade não funciona porque muitas vezes teremos filtros aplicados.

@Herongozo54 15 дней назад

gran video

@omarcospreviato 15 дней назад

Uso sempre o nanoid com 21 char, na minha opinião é o melhor dos mundos, a colisão aconteceria em ~41 milhões de anos com a inserção de 1.000 ids por segundo.

@isaquesb 14 дней назад

"Onde é que começa essa desgraça?, onde é que termina essa desgraça?" Fernandes, Diego - 2024 kkkkkkkkk!!!

@M0T4 14 дней назад

Otimo conteudo pra mim que so usava ShortId() em tudo haha

@dridev01 13 дней назад

Caralho que AULA da porra

@lucasfranzolin 16 дней назад

Vou ter que refatorar mais uma app....poxa Diegão 😂

@samuelmatos8875 15 дней назад

Seria bacana falar sobre o fato do next nao permitir cachear arquivos que são carregados dinámicamente durante a execução em produção. Sempre retorna erro 404, e para contornar o problema, precisa criar um servidor customizado... Chatao isso

@talismamanuel 15 дней назад

muitas inserções seriam tipo quanto?

@Brendospdev 13 дней назад

eu colocaria no mínimo na casa dos milhares para milhões em um certo período de tempo. Na empresa que trabalho, lidamos com mais de 15k inserções por minuto e isso não é muito se comparado com twitter, instagram, discord...

@iury664 8 дней назад

"Eita..."' hahahahahah

@TiagoCaus 16 дней назад

Cara, pra que xingar?????

@devcoelho 16 дней назад

E qual é o problema??!

@melkyvinicius6201 16 дней назад

Sério cara? Então tá bom de voltar pro fundamental, pqp

@TiagoCaus 15 дней назад

@@devcoelho na grande maioria, minha filha de 5 anos está proximo. Não deu outra ela perguntou "Pai o que é !"#$"? Entendeu?

@TiagoCaus 15 дней назад

@@melkyvinicius6201 Não sei o que é prioridade para você, mas no dia que tiver uma filha e ela ouvir uma pessoa falando palavras que não é de comum, vai entender. Desejo o melhor para você.

@jonnyborgesdev 16 дней назад

Nem assisti o video porque UUID ou autoincrement NUNCA devem ser utilizados em um banco de dados, abraço.

@Theoxysmusic 16 дней назад

O que deve ser usado então na sua opinião ?

@Bruno-cg4vu 16 дней назад

Ué, tem dois ERP onde eu trabalho e são grandes internamente e usa autoincremente

@Cultosaurus_Erectus 16 дней назад

@@Bruno-cg4vu Relaxa, o JonnyBorgesdev sabe o que 'e melhor para a gente. A qualidade do codigo dele e alta, ou seja, esta alinhada com o tamanho do ego dele.