Boa tarde pessoas, vocês estão bem? Espero que sim, hoje no trabalho surgiu que me levou a uma dúvida, como o banco lida com multiplas inserções para não gerar ids repetidos?
Exemplo, 10 pessoas ao mesmo tempo fazem um cadastro, como o postgres (usamos ele aqui) gera ids diferentes para cada uma desses cadastro sendo que foram ao mesmo tempo? Sou estágiario tenham paciência por favor kakakak
10 pessoas ao mesmo tempo fazem um cadastro
De forma bem resumida, não será ao mesmo tempo. Mesmo que os requests cheguem juntos, será inserido um de cada vez. Mas hoje em dia os computadores estão tão rápidos que dá a impressão de que foram todos ao mesmo tempo. Não foram, alguém foi o primeiro, outro foi o segundo, e assim por diante. A diferença pode ser de milésimos de segundo ou até menos, mas não são simultâneos.
Quanto a não gerar ID's repetidos, geralmente usa-se uma sequence, que é um recurso gerenciado pelo próprio banco de dados: vc simplesmente pede o próximo valor e o banco garante que será único (novamente, porque não tem isso de "mais de um pedir o próximo valor ao mesmo tempo", cada um pede na sua vez). Ou vc pode usar UUID, pois a chance de encontrar um ID repetido é bem pequena.
Leitura complementar:
HUMMMMMM, faz muito sentido obrigado ! <3 vou continuar a dar uma olhada nesse conteudo thanks 💗
Opa!
Muito legal que você está interessado em entender esse funcionamento :)
Basicamente dentre todos os conceitos de constraints, indexes, locks que os SGBDs atuais implementam, alguns com diferentes estratégias, tudo é basicamente voltado para trabalhar com concorrência e consistência de todos os dados.
Vou deixar um link para um paper da Oracle que aborda um pouco esse tema: https://docs.oracle.com/en/database/oracle/oracle-database/21/cncpt/data-concurrency-and-consistency.html#GUID-E8CBA9C5-58E3-460F-A82A-850E0152E95C
Uma segunda recomendação é o livro Database Internals: A Deep Dive Into How Distributed Data Systems Work de Alex Petrov.
Bons estudos!
Saquei saquei, vou dar uma olhada nas recomendações brigadao ai
Bom, eu não sei como é exatamente a implementação no postgres, mas de uma forma geral, esse tipo de situação, em que você tem uma aplicação multithread e em que essas multiplas threads precisam de uma informação que é compartilhada entre elas, costuma ser usado semáforos para fazer essas atualizações, dessa forma, mesmo que ocorra de duas requisições acontecerem exatamente no mesmo momento, apenas uma delas terá permissão para ler e alterar a variável em questão, e a outra thread esperará a vez dela de realizar essa operação.
Então, muito provavelmente, o postgres, bem como os outros bancos, possuem uma variável do tipo semáforo, que armazena o valor do proximo id, que permita apenas um acesso simultâneo, e incrementa essa valor antes de liberar o acesso para a próxima conexão.
Para melhorar o paralelismo disso, e diminuir essa espera, os bancos podem fazer uma espécie de cache (ou buffer) também, onde ele deixaria, por exemplo, 10 ids prontos para serem usados, e as conexões vão pegando esses ids desse buffer na ordem em que foram criados, assim uma thread não precisaria esperar pela outra...
Já vi o akita falando sobre concorrencia e paralelismo, mt conteudo e meio paia de assimilar tudo de uma vez, mas real faz sentido, obrigado pela atenção <3