Búsqueda de texto completo en Postgres: Elasticsearch vs. las alternativas

Búsqueda de texto completo (Full Text Search)

• La búsqueda de texto completo es una técnica para encontrar elementos dentro de una colección de textos según la presencia de palabras clave y frases específicas
• La mayoría de los motores de búsqueda, como Elasticsearch, usan el algoritmo BM25 para clasificar los resultados de búsqueda
  • BM25 toma en cuenta con qué frecuencia aparece un término y qué tan único es ese término en todos los documentos
• La búsqueda de texto completo es distinta de la búsqueda por similitud o búsqueda vectorial, que recupera y clasifica resultados según significado semántico
• Muchas aplicaciones modernas combinan la búsqueda de texto completo con la búsqueda por similitud; a esto se le llama búsqueda híbrida y puede ofrecer resultados más precisos

Postgres FTS

Ventajas

1. Simplicidad

   • Postgres FTS no requiere infraestructura adicional y puede usarse en cualquier servicio administrado de Postgres, como AWS RDS
   • A largo plazo, evita la necesidad de orquestar y administrar un motor de búsqueda externo, lo que puede ahorrar mucho tiempo y preocupaciones

2. Búsqueda en tiempo real

   • En Postgres FTS, los datos se pueden buscar inmediatamente después del commit
   • Esto puede ser muy útil para empresas que construyen experiencias de búsqueda orientadas al usuario o sensibles a la latencia, como sitios de comercio electrónico o fintech

3. Transacciones y MVCC de Postgres

   • Las transacciones ACID y el control de concurrencia multiversión (MVCC) de Postgres garantizan la confiabilidad de los resultados de FTS durante accesos concurrentes y actualizaciones frecuentes

Desventajas

1. Funcionalidad incompleta

   • El conjunto limitado de funciones de Postgres FTS puede ser un factor decisivo para algunas empresas
   • Entre las funciones faltantes están el scoring BM25, el ajuste de relevancia, los tokenizadores personalizados y el faceting

2. Menor rendimiento con conjuntos de datos grandes

   • Postgres FTS funciona bien en tablas con millones de filas, pero su rendimiento cae de forma considerable en tablas con decenas de millones de filas

3. Overhead transaccional

   • Crear un índice GIN en una columna agrega una pequeña latencia, por lo general de milisegundos, a las transacciones que afectan esa columna

Resumen clave

• Postgres FTS es ideal para búsquedas en tablas pequeñas o medianas que no requieren consultas FTS sofisticadas
• Lo que significan exactamente "medianas" y "sofisticadas" se deja deliberadamente ambiguo, porque depende de los requisitos de rendimiento
• Afortunadamente, probar y migrar hacia/desde Postgres FTS es muy sencillo

Elasticsearch

Ventajas

1. Conjunto de funciones integral

   • Elasticsearch puede manejar casi cualquier consulta FTS
   • El Elastic Query DSL (lenguaje específico de dominio) es el estándar de las capacidades de búsqueda de texto completo

2. Alto rendimiento

   • Según benchmarks, Elasticsearch puede consultar miles de millones de filas en milisegundos gracias a Lucene, un motor de búsqueda base probado en batalla, y a su arquitectura distribuida

3. Más que solo búsqueda

   • Además de FTS, Elasticsearch también es un motor de consultas analíticas, una base de datos vectorial y una plataforma de seguridad y observabilidad
   • Muchas organizaciones disfrutan de la simplicidad de consolidar varios servicios dentro de Elasticsearch

Desventajas

1. No es un almacén de datos confiable

   • Muchas empresas han terminado arrepintiéndose de haber decidido usar Elasticsearch como almacén principal de datos
   • No es una práctica recomendada. Elasticsearch carece de transacciones ACID y MVCC, lo que puede provocar inconsistencias y pérdida de datos; además, por sus limitaciones relacionales y de consistencia en tiempo real, muchas consultas de base de datos se vuelven difíciles

2. Requiere una tubería ETL

   • Como Elasticsearch no es un almacén de datos confiable, las organizaciones que usan Postgres normalmente extraen, transforman y cargan (ETL) los datos desde Postgres hacia Elasticsearch
   • Como una falla en la tubería ETL puede provocar todo tipo de incidentes en producción, hay que mantenerla con mucho cuidado para que los cambios en el esquema base de Postgres no la rompan

3. Pérdida de frescura de los datos

   • Los trabajos ETL consumen tiempo y se ejecutan periódicamente
   • Los datos que llegan a Elasticsearch suelen ir con varias horas de retraso respecto a Postgres
   • Para aplicaciones que necesitan búsqueda en tiempo real sobre tablas de Postgres, esto puede ser un impedimento crítico

4. Costo

   • Sorprende escuchar de varias empresas que Elasticsearch se ha convertido en su rubro de software más costoso
   • A medida que el costo de los clústeres de Elasticsearch se disparó, muchas de estas empresas pasaron de Elasticsearch Cloud a autoadministrarlo, lo que redujo el gasto en la nube pero generó nuevos problemas
   • Elasticsearch tiene fama de ser muy difícil de operar, ajustar y administrar
   • Estas organizaciones terminan contratando ingenieros, costosos, para administrar sus clústeres de Elasticsearch

Resumen clave

• Elasticsearch ofrece un rendimiento de búsqueda excelente a cambio de mayor overhead operativo y menor frescura de los datos
• Se recomienda Elasticsearch cuando una alternativa más ligera no es viable o cuando de todos modos se planea usar otros servicios de Elasticsearch

Motores de búsqueda alternativos

• En los últimos años han surgido motores de búsqueda modernos como Algolia, Meilisearch y Typesense
• Estos motores suelen usarse para construir experiencias de búsqueda orientadas al usuario
• La búsqueda de Hacker News también está construida sobre Algolia
• Aunque cada servicio se diferencia en los detalles, hay una advertencia importante para los desarrolladores que buscan búsqueda sobre Postgres
• Ninguna de estas soluciones fue creada específicamente para Postgres
• Los usuarios de Postgres probablemente experimentarán problemas similares a los de Elasticsearch con estos servicios

¿Es posible obtener lo mejor de ambos mundos?

• ParadeDB es un motor de búsqueda de texto completo creado para Postgres
• Basado en una extensión llamada pg_search, ParadeDB integra dentro de Postgres a Tantivy, una alternativa a Lucene escrita en Rust
• Al igual que Postgres FTS, ParadeDB se conecta a bases de datos Postgres autoadministradas existentes sin infraestructura adicional
• Al igual que Elasticsearch, ParadeDB ofrece las capacidades de un motor avanzado de búsqueda de texto completo
• La compatibilidad con servicios administrados de Postgres como Amazon RDS llegará pronto

[galadbran]

Ah, conque Postgres FTS se refería a una función integrada.

[xguru]

Estas personas han seguido mejorándolo de forma constante y publicando artículos relacionados, así que también lo he compartido varias veces en GeekNews.

ParadeDB - PostgreSQL for Search
pg_bm25 - extensión de búsqueda de texto completo para Postgres que ofrece una calidad al nivel de Elastic

[cometkim]

Los tres mencionados en el artículo, paradedb, pg_search y pg_bm25, son el mismo proyecto.