Busca textual completa no Postgres: Elasticsearch vs. alternativas

Busca textual completa (Full Text Search)

• Busca textual completa é a técnica de encontrar itens em uma coleção de textos com base na presença de palavras-chave e frases específicas
• A maioria dos mecanismos de busca, como o Elasticsearch, usa o algoritmo BM25 para ranquear os resultados de busca
  • O BM25 considera com que frequência um termo aparece e o quão único esse termo é em todos os documentos
• Busca textual completa é diferente de busca por similaridade ou busca vetorial, que pesquisam e ranqueiam resultados com base em significado semântico
• Muitos aplicativos modernos combinam busca textual completa com busca por similaridade, o que é chamado de busca híbrida, e isso pode produzir resultados mais precisos

Postgres FTS

Vantagens

1. Simplicidade

   • O Postgres FTS não exige infraestrutura adicional e pode ser usado em qualquer serviço gerenciado de Postgres, como o AWS RDS
   • No longo prazo, isso pode economizar bastante tempo e esforço, já que não é necessário orquestrar e gerenciar um mecanismo de busca externo

2. Busca em tempo real

   • No Postgres FTS, os dados podem ser pesquisados imediatamente após o commit
   • Isso pode ser muito útil para empresas que constroem experiências de busca voltadas ao usuário ou sensíveis à latência, como sites de e-commerce ou fintechs

3. Transações do Postgres e MVCC

   • As transações ACID e o controle de concorrência multiversão (MVCC) do Postgres garantem a confiabilidade dos resultados de FTS em acessos concorrentes e atualizações frequentes

Desvantagens

1. Funcionalidade incompleta

   • O conjunto limitado de recursos do Postgres FTS pode ser um impeditivo para algumas empresas
   • Recursos ausentes incluem pontuação BM25, ajuste de relevância, tokenizadores personalizados e facetamento

2. Queda de desempenho em grandes volumes de dados

   • O Postgres FTS funciona bem em tabelas com milhões de linhas, mas o desempenho cai significativamente em tabelas com dezenas de milhões de linhas

3. Sobrecarga transacional

   • Criar um índice GIN em uma coluna adiciona uma pequena latência, normalmente de milissegundos, às transações que afetam essa coluna

Resumo principal

• O Postgres FTS é ideal para busca em tabelas pequenas e médias que não exigem consultas de FTS sofisticadas
• O significado de "médias" e "sofisticadas" foi deixado intencionalmente vago, porque isso depende dos requisitos de desempenho
• Felizmente, testar e migrar para/de o Postgres FTS é muito simples

Elasticsearch

Vantagens

1. Conjunto de recursos abrangente

   • O Elasticsearch consegue lidar com praticamente qualquer consulta de FTS
   • A query DSL do Elastic é o padrão em funcionalidades de busca textual completa

2. Alto desempenho

   • Segundo benchmarks, o Elasticsearch consegue consultar bilhões de linhas em milissegundos graças ao Lucene, um mecanismo de busca maduro e amplamente testado, e à sua arquitetura distribuída

3. Mais do que busca

   • Além de FTS, o Elasticsearch também é um mecanismo de consultas analíticas, banco de dados vetorial e plataforma de segurança e observabilidade
   • Muitas organizações apreciam a simplicidade de consolidar vários serviços dentro do Elasticsearch

Desvantagens

1. Não é um armazenamento de dados confiável

   • Muitas empresas se arrependeram de ter decidido usar o Elasticsearch como armazenamento principal de dados
   • Essa abordagem não é recomendada. O Elasticsearch não tem transações ACID nem MVCC, o que pode causar inconsistência e perda de dados, e a falta de propriedades relacionais e de consistência em tempo real dificulta muitas consultas típicas de banco de dados

2. Necessidade de pipeline ETL

   • Como o Elasticsearch não é um armazenamento de dados confiável, organizações que usam Postgres normalmente extraem, transformam e carregam (ETL) os dados do Postgres para o Elasticsearch
   • Como falhas no pipeline ETL podem causar todo tipo de interrupção em produção, é preciso manter tudo com muito cuidado para que mudanças no schema principal do Postgres não quebrem o pipeline

3. Perda de frescor dos dados

   • Jobs de ETL consomem tempo e são executados periodicamente
   • Os dados que chegam ao Elasticsearch muitas vezes estão horas atrás do Postgres
   • Para aplicativos que precisam fazer busca em tempo real sobre tabelas do Postgres, isso pode ser um impeditivo

4. Custo

   • É surpreendente ouvir de várias empresas que o Elasticsearch se tornou seu maior item de custo de software
   • À medida que o custo dos clusters de Elasticsearch disparou, muitas dessas empresas migraram do Elasticsearch Cloud para gestão própria, o que reduziu gastos com nuvem, mas criou novos problemas
   • O Elasticsearch é notoriamente difícil de operar, ajustar e administrar
   • Essas organizações contratam engenheiros caros para gerenciar clusters de Elasticsearch

Resumo principal

• O Elasticsearch oferece excelente desempenho de busca em troca de overhead operacional e menor frescor dos dados
• Ele é recomendado quando alternativas mais leves não são viáveis ou quando você pretende usar outros serviços do Elasticsearch

Mecanismos de busca alternativos

• Nos últimos anos, surgiram mecanismos de busca modernos como Algolia, Meilisearch e Typesense
• Esses mecanismos geralmente são usados para construir experiências de busca voltadas ao usuário
• A busca do Hacker News também é construída sobre o Algolia
• Cada serviço se diferencia em detalhes, mas há um ponto importante para desenvolvedores que procuram busca para Postgres
• Nenhuma dessas soluções foi construída especificamente para o Postgres
• Usuários de Postgres provavelmente enfrentarão problemas semelhantes aos do Elasticsearch com esses serviços

Será possível ter o melhor dos dois mundos?

• O ParadeDB é um mecanismo de busca textual completa construído para o Postgres
• Baseado em uma extensão chamada pg_search, o ParadeDB embute dentro do Postgres o Tantivy, uma alternativa ao Lucene escrita em Rust
• Assim como o Postgres FTS, o ParadeDB se conecta a bancos de dados Postgres autogerenciados existentes sem exigir infraestrutura adicional
• Assim como o Elasticsearch, o ParadeDB oferece os recursos de um mecanismo avançado de busca textual completa
• A compatibilidade com serviços gerenciados de Postgres, como o Amazon RDS, estará disponível em breve

[galadbran]

Então, eu estava me perguntando o que era o FTS do Postgres e descobri que se referia a um recurso nativo.

[xguru]

Esses caras vêm melhorando continuamente e publicando textos relacionados, então já compartilhei várias vezes no GeekNews.

ParadeDB - PostgreSQL for Search
pg_bm25 - extensão de busca full-text para Postgres que oferece qualidade no nível do Elastic

[cometkim]

Os paradedb, pg_search e pg_bm25 mencionados no texto são todos o mesmo projeto.