Sabe aquela busca que demora uma eternidade pra retornar? Ou pior, que volta com um monte de coisa que não tem nada a ver com o que você digitou?
Pois é. Provavelmente tem um LIKE '%produto%' na origem disso tudo.
O problema do LIKE
Quando você usa o LIKE com wildcards, você está mandando o banco fazer um table scan: ele lê cada linha, caractere por caractere, até achar o que você quer. Em um projeto pequeno, com poucos dados, você nem nota. Mas conforme a aplicação cresce e os acessos aumentam, isso vira o caminho mais rápido pra sua performance ir por água abaixo.
Com LIKE, o banco lê cada linha. Com FTS, vai direto ao índice.
Pensa comigo: imagine que você precisasse ler um dicionário inteiro do começo ao fim só pra encontrar uma palavra. É exatamente isso que o banco está fazendo cada vez que essa query roda.
O alerta de ouro: não use o que você não precisa
Muita calma nessa hora.
Se você está criando um projeto paralelo, um MVP ou uma aplicação com poucos usuários, esquece o Elasticsearch e qualquer implementação complexa de FTS. O custo de manutenção, infraestrutura e sincronização de dados é alto demais pra um cenário que não exige essa robustez.
O LIKE do seu banco relacional está ótimo pro começo. Não tente aplicar arquitetura do iFood num sistema de agendamento de barbearia!
A solução: Full-Text Search (para sistemas de alta escala)
Quando falamos de milhares ou milhões de acessos e buscas complexas, o jogo muda completamente. O Full-Text Search (FTS) resolve isso com uma estrutura chamada índice invertido. Em vez de varrer o texto, o sistema cria antecipadamente um mapa de palavras, igualzinho ao índice remissivo no final de um livro.
O índice invertido mapeia cada palavra para os documentos onde ela aparece. Na hora da busca, é só consultar o mapa.
Então quando o usuário digita "fone bluetooth sem fio", o sistema não sai varrendo a tabela de produtos linha por linha. Ele consulta o índice e devolve o resultado. Instantaneamente.
Quando ir além do básico?
O PostgreSQL já tem suporte nativo a FTS e resolve bem pra volumes médios. Mas em arquiteturas de alto desempenho, o caminho natural é delegar isso pra motores especializados, como o Elasticsearch.
Os principais benefícios que você ganha:
- Fuzzy search: tolerância a erros de digitação. O usuário pesquisou "notebbok gammer"? Ele ainda encontra o que precisa.
- Relevância: resultados contextuais, indo além da correspondência exata. Pesquisou "celular barato"? O sistema entende a intenção, não só as palavras.
- Performance: latência baixíssima mesmo com milhões de registros e alta concorrência.
Conclusão
Se a sua aplicação exige uma busca rápida e inteligente sob alta concorrência, migrar pra um motor de Full-Text Search é um divisor de águas.
Só não esquece: a melhor arquitetura é aquela que atende aos requisitos do seu momento. Não suba a complexidade antes de ter o problema de escala que a justifique. Primeiro faça funcionar, depois você vai apertando os parafusos.
Dica bônus: quer manter seus dados do banco relacional sincronizados com a ferramenta de busca em tempo real? Pesquisa sobre CDC (Change Data Capture). Você vai agradecer depois.