postgresql - create - heroku postgres

¿Algún motivo para no utilizar la búsqueda de texto completo incorporada de PostgreSQL en Heroku?

Question

Me estoy preparando para implementar una aplicación de Rails en Heroku que requiere búsqueda de texto completo. Hasta ahora lo he estado ejecutando en un VPS usando MySQL con Sphinx.

Sin embargo, si quiero usar Sphinx o Solr en Heroku, tendría que pagar por un complemento.

Observé que PostgreSQL (el DB utilizado en Heroku) tiene una función de búsqueda de texto completo incorporada.

¿Hay alguna razón por la que no pueda usar la búsqueda de texto completo de Postgres? ¿Es más lento que Sphinx o hay alguna otra limitación importante?

Answer 1

Edición, 2016 - ¿Por qué no ambos?

Si está interesado en Postgres vs. Lucene, ¿por qué no ambos? Consulte la extensión de ZomboDB para Postgres, que integra Elasticsearch como un tipo de índice de primera clase. Todavía es un proyecto bastante temprano pero me parece realmente prometedor.

• ZomboDB

(Técnicamente no está disponible en Heroku, pero aún así vale la pena mirarlo).

Divulgación: soy cofundador de los complementos Websolr y Bonsai Heroku, por lo que mi perspectiva es un poco parcial hacia Lucene.

Mi lectura en la búsqueda de texto completo de Postgres es que es bastante sólida para casos de uso directo, pero hay una serie de razones por las que Lucene (y, por lo tanto, Solr y ElasticSearch) es superior tanto en términos de rendimiento como de funcionalidad.

Para empezar, jpountz ofrece una excelente respuesta técnica a la pregunta: ¿Por qué Solr es mucho más rápido que Postgres? Vale la pena un par de lecturas para digerir realmente.

También comenté un episodio reciente de RailsCast que compara ventajas y desventajas relativas de la búsqueda de texto completo de Postgres versus Solr. Permítanme recapitular eso aquí:

Ventajas pragmáticas para Postgres

• Reutilice un servicio existente que ya está ejecutando en lugar de configurar y mantener (o pagar) otra cosa.
• Muy superior al operador SQL LIKE increíblemente lento.
• Menos problemas para mantener los datos sincronizados, ya que todo está en la misma base de datos, sin integración a nivel de aplicación con alguna API de servicio de datos externo.

Ventajas de Solr (o ElasticSearch)

Fuera de mi cabeza, sin ningún orden en particular ...

• Escale su carga de indexación y búsqueda por separado de su carga regular de base de datos.
• Análisis de términos más flexible para cosas como normalización de acento, derivación lingüística, N-grams, eliminación de marcado ... Otras características geniales como revisión ortográfica, extracción de "contenido enriquecido" (por ejemplo, PDF y Word) ...
• Solr / Lucene puede hacer todo lo posible en la lista de tareas de búsqueda de texto completo de Postgres .
• Clasificación de relevancia mucho mejor y más rápida, eficientemente personalizable en el tiempo de búsqueda.
• Probablemente, un rendimiento de búsqueda más rápido para términos comunes o consultas complicadas.
• Probablemente un rendimiento de indexación más eficiente que Postgres.
• Mejor tolerancia para el cambio en su modelo de datos desvinculando la indexación de su almacén de datos primario

Claramente, creo que un buscador dedicado basado en Lucene es la mejor opción aquí. Básicamente, puede pensar en Lucene como el repositorio de fuente abierta de facto de la experiencia de búsqueda.

Pero si su única otra opción es el operador LIKE , entonces la búsqueda de texto completo de Postgres es una victoria definitiva.

Answer 2

Dado que acabo de realizar el esfuerzo de comparar la búsqueda elástica (1.9) con el FTS postgres, pensé que debería compartir mis resultados ya que son algo más actuales que los que cita @gustavodiazjaimes.

Mi principal preocupación con postgres era que no tenía facetas incorporadas, pero eso es trivial para construir usted mismo, aquí está mi ejemplo (en django):

results = YourModel.objects.filter(vector_search=query)
facets = (results
    .values(''book'')
    .annotate(total=Count(''book''))
    .order_by(''book''))

Estoy usando postgres 9.6 y elástico-search 1.9 (a través de haystack en django). Aquí hay una comparación entre elasticsearch y postgres en 16 diversos tipos de consultas.

    es_times  pg_times  es_times_faceted  pg_times_faceted
0   0.065972  0.000543          0.015538          0.037876
1   0.000292  0.000233          0.005865          0.007130
2   0.000257  0.000229          0.005203          0.002168
3   0.000247  0.000161          0.003052          0.001299
4   0.000276  0.000150          0.002647          0.001167
5   0.000245  0.000151          0.005098          0.001512
6   0.000251  0.000155          0.005317          0.002550
7   0.000331  0.000163          0.005635          0.002202
8   0.000268  0.000168          0.006469          0.002408
9   0.000290  0.000236          0.006167          0.002398
10  0.000364  0.000224          0.005755          0.001846
11  0.000264  0.000182          0.005153          0.001667
12  0.000287  0.000153          0.010218          0.001769
13  0.000264  0.000231          0.005309          0.001586
14  0.000257  0.000195          0.004813          0.001562
15  0.000248  0.000174          0.032146          0.002246
                  count      mean       std       min       25%       50%       75%       max
es_times           16.0  0.004382  0.016424  0.000245  0.000255  0.000266  0.000291  0.065972
pg_times           16.0  0.000209  0.000095  0.000150  0.000160  0.000178  0.000229  0.000543
es_times_faceted   16.0  0.007774  0.007150  0.002647  0.005139  0.005476  0.006242  0.032146
pg_times_faceted   16.0  0.004462  0.009015  0.001167  0.001580  0.002007  0.002400  0.037876

Con el fin de obtener postgres a estas velocidades para búsquedas facetadas, tuve que usar un índice GIN en el campo con un SearchVectorField, que es específico de django, pero estoy seguro de que otros frameworks tienen un tipo de vector similar.

Otra consideración es que la página 9.6 ahora admite la coincidencia de frases, que es enorme.

Mi conclusión es que postgres es para la mayoría de los casos preferible ya que ofrece:

1. pila más simple
2. no hay que buscar las dependencias de contenedor de API de búsqueda (thinking-sphinx, django-sphinx, haystack, etc.). Estos pueden ser un obstáculo, ya que es posible que no sean compatibles con las características de la aplicación de back-end (p. Ej., Faceting / aggregates del pajar).
3. tiene un rendimiento y características similares (para mis necesidades)

Answer 3

Encontré esta comparación increíble y quiero compartirla:

Búsqueda de texto completo en PostgreSQL

Tiempo para compilar el predicado LIKE del índice: ninguno
PostgreSQL / GIN - 40 min
Búsqueda con Sphinx - 6 min
Apache Lucene - 9 min
Índice invertido - alto

Predicado LIKE de almacenamiento de índice - ninguno
PostgreSQL / GIN - 532 MB
Búsqueda de Sphinx - 533 MB
Apache Lucene - 1071 MB
Índice invertido - 101 MB

Frecuencia de consulta LIKE predicado: más de 90 segundos
PostgreSQL / GIN - 20 ms
Búsqueda de Sphinx - 8 ms
Apache Lucene - 80 ms
Índice invertido - 40 ms

Answer 4

La búsqueda de texto completo de Postgres tiene capacidades increíbles en las áreas de derivación, clasificación / aumento, manejo de sinónimos, búsquedas borrosas, entre otras, pero no admite la búsqueda facetada.

Por lo tanto, si Postgres ya está en su pila y no necesita facetas, mejor intente aprovechar el GRAN beneficio de mantener los índices sincronizados y mantener una pila elegante, antes de buscar soluciones basadas en Lucene, al menos si todos su aplicación no se basa en la búsqueda.

Answer 5

La función FTS de Postgresql es madura y bastante rápida en las búsquedas. Vale la pena un vistazo seguro.