Banco de dados / ORM
O Hibernate oferece uma conveniência poderosa: você modifica um objeto Java dentro de uma transação, e as mudanças são persistidas automaticamente no banco no momento do flush, sem precisar chamar save() explicitamente. Isso funciona porque o Hibernate mantém um snapshot do estado original de cada entidade carregada e, no flush, compara o estado atual com…
O artigo anterior mostrou como transações longas esgotam o connection pool. Mas esse é apenas o dano visível — o que a aplicação sente diretamente. Dentro do banco de dados, uma transação longa causa um conjunto separado de problemas que continuam existindo mesmo depois que o connection pool é dimensionado corretamente, mesmo com PgBouncer, mesmo…
Existe uma falha de produção com uma assinatura muito específica. A aplicação está no ar. O banco de dados está saudável. A CPU não está alta. A memória está ok. Mas os requests começam a demorar cada vez mais, o timeout do load balancer começa a disparar, e o log enche de uma exceção: O…
O over-fetching traz dados demais. O under-fetching traz dados de menos — e paga o preço voltando ao banco repetidas vezes para completar o que precisava desde o início. É um problema mais sutil que o N+1 porque não segue um padrão mecânico de loop. Ele aparece em código perfeitamente razoável: uma chamada de serviço…
Existe uma linha de código que aparece em tutoriais, exemplos de documentação e código de produção com igual frequência: sql Ou sua versão em JPQL: java Ela funciona. Retorna os dados. Os testes passam. E em muitos sistemas, ela é a origem de um desperdício silencioso e contínuo: trazer da rede, desserializar e alocar na…
Existe uma categoria de problema de performance que tem uma característica cruel: ele não aparece durante o desenvolvimento, não aparece nos primeiros meses de produção, e quando aparece, a aplicação já está sob pressão de usuários reais. O Missing Index é esse problema. A query funcionava perfeitamente com 10.000 registros. Com 2.000.000, ela trava. A…
Se você já abriu o log SQL do Hibernate e viu uma query com múltiplos JOINs retornando um número de linhas absurdamente maior do que o esperado — e a aplicação continuava funcionando, mas lenta — você encontrou o Cartesian Product Explosion. Diferente do N+1, que executa muitas queries pequenas, este problema executa poucas queries…
Se você já habilitou o log de SQL do Hibernate e viu algo assim no console: …repetindo dezenas ou centenas de vezes, você encontrou o N+1 query problem. É um dos bugs de performance mais silenciosos e devastadores que existem — porque a aplicação continua funcionando, as respostas chegam corretas, mas debaixo do capô o…
Quem trabalha com JPA há algum tempo provavelmente já passou por uma situação estranha como esta: Você altera uma entidade: Depois executa uma query aparentemente inocente: E então, sem chamar: o banco recebe um: A primeira reação normalmente é: “Mas eu não mandei salvar nada.” E é justamente aí que muitos desenvolvedores começam a descobrir…