Quando a culpa recai no banco de dados — e quase nunca deveria
É muito comum participar de reuniões com times de desenvolvimento nas quais o volume de uso do sistema aumentou e ouvir que o banco de dados está “sentando” ou que se tornou o grande gargalo da operação. Quando isso ocorre, é comum o time correr até o administrador de nuvem solicitando “mais máquina” ou até iniciar discussões sobre migrar de um banco de dados para outro, sob o argumento de que o atual ficou caro, chegando inclusive a falar em mudar de paradigma, de modelos relacionais para não relacionais, quando este, de fato, não é o problema real.
O que a experiência prática nos mostra, especialmente em cenários de alta complexidade, é que os SGBDs estão entre as peças de engenharia e ciência da computação mais avançadas e otimizadas que existem. Eles operam, por vezes, verdadeiros milagres para retornar o dado solicitado em tempo recorde. Em 95% dos casos, ou mais, o banco de dados aguenta a pancada; o problema está nos 5% que, quando aparecem, maltratam o banco a ponto de tudo parecer não funcionar mais. Em bancos de dados, temos um componente chamado otimizador de consultas, responsável por resolver a complexidade das instruções e, com base em dados estatísticos das tabelas, colunas e índices, determinar o melhor caminho para encontrar os dados da forma mais eficiente possível. Empresas como Oracle e Microsoft investem pesado nesse componente, buscando resolver desde consultas bem escritas até verdadeiras monstruosidades criadas pelas aplicações.
Escalabilidade, concorrência e o preço do mau uso do banco de dados
A escalabilidade de um sistema é frequentemente testada pela sua capacidade de lidar com o inesperado. O caso citado é emblemático: uma aplicação sofre instabilidade não por falha de hardware, mas por um uso questionável dos recursos, como centenas de requisições simultâneas tentando acessar e atualizar um único registro de estoque durante um pico de vendas. Nesses momentos, o volume destrói sonhos. O banco de dados tenta proteger a integridade das informações por meio de bloqueios, mas, se a modelagem não previu esse volume, tratando corretamente as transações e contando com metadados que ajudem a minimizar os bloqueios, o sistema inevitavelmente trava. O culpado apontado quase sempre é o banco de dados e, na maioria das análises, descobre-se que ele faz milagres — mas não sempre. A conclusão recorrente é que a estratégia de acesso aos dados precisa ser revisada.
Um dos maiores equívocos da engenharia moderna é a crença de que é possível compensar código ineficiente com mais poder de processamento. Vemos empresas mantendo máquinas gigantes para suportar operações que poderiam ser resolvidas com uma fração desses recursos se houvesse um ajuste fino nas consultas. O custo da negligência com o banco de dados impacta diretamente o caixa da empresa. Quando ignoramos fundamentos básicos, como a criação de índices assertivos ou a manutenção de estatísticas atualizadas, forçamos o motor do banco a realizar leituras completas em tabelas gigantescas para encontrar uma única informação. O resultado é um consumo desproporcional de CPU e disco, levando a um aumento exponencial da latência que nenhum upgrade de hardware consegue mascarar indefinidamente.
Performance sustentável exige método, não troca de tecnologia
Ao escrever uma consulta, o desenvolvedor está expressando uma intenção de resultado, e cabe ao otimizador do banco de dados decidir o melhor caminho para entregar esse dado. Para que essa decisão seja eficiente, o SGBD precisa de contexto. Se a modelagem negligencia chaves estrangeiras, restrições de unicidade e índices pensados de acordo com os dados que serão filtrados, o planejador de consultas perde os artefatos necessários para tomar a decisão ótima. Tratar o banco de dados apenas como um repositório passivo de tabelas, ignorando o poder de seus mecanismos de otimização, é como tentar pilotar uma aeronave moderna usando apenas os comandos manuais de um planador.
Em aplicações de negócio, onde a proporção de leitura para escrita costuma ser de dez para um, pequenos erros de lógica, como o problema das consultas N+1, tornam-se fatais. Esse é o cenário em que, para carregar uma lista de itens, a aplicação dispara uma nova consulta para cada linha individualmente, gerando idas e vindas demais entre a aplicação e o banco de dados e um overhead de processamento que sufocam o servidor. O segredo para a sustentabilidade de longo prazo não está em trocar de banco de dados a cada novo problema de performance, mas em adotar um método de engenharia que respeite a mecânica do banco e utilize o conhecimento de especialistas para apertar os parafusos certos.
Performance se constrói, não se compra!
Concluir que o banco de dados é o problema sem antes analisar todo o contexto é um erro de diagnóstico caro. Trabalho com performance de aplicações durante grande parte do meu dia e costumo dizer que resolver problemas de desempenho vai muito além do conhecimento da ferramenta: exige compreensão do contexto de negócio para o qual aquele processo foi construído. A tecnologia de bancos de dados evoluiu a ponto de resolver muitos problemas de escrita de SQL, mas ainda exige que o desenvolvedor conheça a natureza dos dados com os quais trabalha e entenda quais estruturas precisam existir para que o banco responda o mais rápido possível. Quando a engenharia de software e a inteligência de dados caminham juntas, o que antes parecia um gargalo intransponível revela-se apenas uma questão de ajuste, permitindo que o sistema escale com eficiência, baixo custo e, acima de tudo, previsibilidade.
