Reduzindo a busca de licitações públicas de 13 segundos para 150 milissegundos
Como estagiário, o primeiro sistema que assumi de ponta a ponta foi um motor de busca para licitações públicas brasileiras. Compradores de órgãos públicos precisavam encontrar editais, contratos e acórdãos espalhados pelo Comprasnet, pelo TCU e pela AGU, portais que não conversavam entre si e não tinham busca de verdade. Um estudo da CGU apontava que 85% dos órgãos públicos eram deficitários no planejamento de contratações, em boa parte porque encontrar precedentes era doloroso. As pessoas faziam isso na mão.
A primeira versão consultava o PostgreSQL direto, com ILIKE e uma pilha de joins. Sobre um acervo que crescia (indexávamos cerca de 600 novas licitações por dia, além de acórdãos e termos de referência) uma única busca levava cerca de 13 segundos. Para uma ferramenta que deveria substituir a busca manual, 13 segundos é o mesmo que estar quebrada.
Para onde ia o tempo
A lentidão não era um bug; era a ferramenta errada. Busca textual sobre centenas de milhares de documentos longos com ILIKE '%termo%' não usa índice, então cada consulta varria a tabela inteira. Cada cláusula OR extra para relevância piorava o quadro. Estávamos pedindo a um banco relacional que fosse um motor de busca.
O que eu mudei
Movi a busca para o Apache Solr e tratei a indexação como parte de primeira classe do pipeline:
- Modelei os documentos em torno de como as pessoas realmente buscavam (por objeto, órgão, faixa de valor e data) em vez de espelhar o schema do banco.
- Ajustei analisadores para o português (stemming, remoção de acentos, stopwords), para que “aquisição” e “aquisicao” casassem.
- Construí um job diário de indexação que normalizava e enriquecia cada documento novo antes de ele chegar ao índice, mantendo as consultas rápidas conforme o acervo crescia.
- Mantive o Postgres como fonte da verdade e deixei o Solr cuidar da recuperação.
O resultado
O tempo de consulta caiu de ~13 segundos para ~150 milissegundos, cerca de 98% de redução. A mesma busca que antes fazia as pessoas esperarem passou a responder antes de elas terminarem de ler a página. O motor passou a sustentar nosso produto de planejamento de contratações (DTR40) para três clientes governamentais, incluindo o Ministério da Agricultura e a secretaria de TI do Distrito Federal.
O que isso me ensinou
A lição não foi “Solr é rápido”. Foi que problemas de performance costumam ser problemas de modelagem disfarçados. Antes de recorrer a cache ou máquinas maiores, hoje pergunto se os dados estão sequer no formato da pergunta que está sendo feita. A maior parte dos 98% veio dessa única decisão: mover a recuperação para uma ferramenta feita para isso e desenhar o índice em torno do usuário, não da tabela.