De consultas de 3 minutos para busca em menos de 1 segundo
Algumas das vitórias de engenharia mais satisfatórias não são features novas — são os momentos em que o sistema para de brigar com quem depende dele. Uma dessas, pra mim, foi a busca.
Trabalhei por mais de uma década num grande sistema de gestão de processos jurídicos no Ministério Público de Goiás. Conforme os dados cresciam para milhões de registros, a busca que todo mundo usava dezenas de vezes por dia foi ficando cada vez mais lenta. No pior momento, algumas consultas levavam dois a três minutos — tempo suficiente pra começar uma, trocar de tarefa e voltar torcendo pra ter terminado.
O banco de dados não era o vilão; era só a ferramenta errada para o trabalho.
Consultas relacionais com LIKE '%termo%' em várias tabelas com join não podem
ser indexadas de forma eficiente, e cada busca virava um full scan. Estávamos
pedindo ao Postgres algo que ele nunca foi feito para fazer bem.
A virada
A solução foi parar de buscar texto no banco e passar a buscar num sistema feito pra isso. Introduzimos o Elasticsearch, indexamos os documentos relevantes e movemos as consultas pesadas de texto pra lá. As mesmas buscas que levavam minutos caíram para menos de três segundos — quase sempre bem abaixo de um.
A parte interessante não foi instalar o Elasticsearch. Foi tudo ao redor:
- Modelar o que indexar. Você não espelha o banco no Elasticsearch. Você decide pelo que os usuários realmente buscam e modela os documentos em torno desses padrões de acesso — desnormalizando de propósito.
- Manter sincronizado. A indexação acontece em background jobs, pra que uma escrita nunca trave esperando o cluster de busca, e pra que uma reindexação de milhões de documentos não derrube a aplicação junto.
- Relevância é decisão de produto. Ordenar por score, dar boost em certos campos, lidar com acentos e termos parciais — não são questões de banco, são sobre o que significa um bom resultado para quem está buscando.
O que levei disso
Trabalho de performance raramente é sobre um truque esperto. É sobre perceber quando um componente está sendo usado contra a sua natureza, e ter a disposição de introduzir a ferramenta certa — e então fazer o trabalho sem glamour de sincronizar, reindexar e ajustar relevância pra que continue rápido conforme os dados crescem.
Cortar uma espera de três minutos para três segundos não adicionou nenhuma feature. Mas devolveu a centenas de pessoas um pedaço do dia delas, todo dia. É esse tipo de resultado que eu continuo perseguindo.