Buscar API vs. Apache Solr Buscar

34

He estado usando el módulo Apache Solr Search en Drupal 6 y estoy buscando en la API de búsqueda para instalar Drupal 7. He visto algunas discusiones aquí, pero estoy buscando alguna razón para elegir una u otra.

¿Hay alguna razón para elegir uno sobre el otro? Si es así, ¿por qué o por qué no? He oído que puede haber problemas de complejidad y / o problemas de rendimiento con Search API. ¿Es esto cierto?

search hross
fuente
No sugeriría solr para búsqueda multilingüe. Depende de lo importante que sea la búsqueda. La búsqueda multilingüe puede llevar mucho tiempo. La configuración puede ser dolorosa. Para la búsqueda multilingüe, su idioma debe ser compatible con solr. Hay reglas gramaticales que deben establecerse para su idioma. También necesita instalar Java y Solr para que no pueda usar un alojamiento compartido barato. Si está desarrollando un motor de búsqueda, es posible que desee utilizarlo. Si está calculando los recursos de desarrollo, ¡entonces la búsqueda en el sitio de Google Payd podría ser una mejor opción! Incluso soy co-mantenedor de gss modulep
ram4 el
¿Porqué es eso? ¿Alguna referencia?
giorgio79
Ou lo siento, mencioné que la configuración puede ser dolorosa. Para la búsqueda multilingüe, su idioma debe ser compatible con solr. Hay reglas gramaticales que deben establecerse para su idioma. También cuando lo examiné, los módulos estaban en estado de desarrollo y necesitaban más trabajo para que las cosas funcionaran. Pero es el motor de búsqueda más rápido. Por lo tanto, debe preguntarse qué tan importante es la función de búsqueda para usted. También necesita instalar Java y Solr para que no pueda usar un alojamiento compartido barato.
ram4nd
Una de las cosas que tuve que venir a Apache Solr en comparación con Search API fue tener una búsqueda de filtro de selección múltiple. Con Search API parecía imposible. Solr parecía tener esta opción.
user219492
Mencionaría la compatibilidad con múltiples sitios: SearchAPI no tiene compatibilidad con múltiples sitios (usando el mismo índice SOLR para almacenar contenidos de múltiples sitios). Apachesolr, en cambio, permite: 1. indexar múltiples contendientes de sistes en el mismo índice SOLR 2. filtrar los resultados por un sitio en particular 3. realizar una búsqueda solo en el sitio local filtrando los resultados de otros sitios
thePanz

Respuestas:

19

A partir de 2015, podemos comparar Search API vs Apache Solr Search modules con los números:

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

lo que indica la clara elección. Search API se desarrolló 3 años después y logró aprovechar a su competidor.

Además, Search API proporciona una arquitectura muy diferente y más flexible y se mantiene de manera más activa. Lo que es más importante, ya es compatible con los nuevos Drupal 8 y Solr 5.x que Apachesolr aún no tiene.

La API de búsqueda comenzó de nuevo y es más flexible en su configuración, incluido el soporte de Vistas (para Apachesolr necesita el módulo adicional). También hay muchos módulos que amplían su funcionalidad.

En segundo lugar, para evitar que la comunidad resuelva dos problemas debido a las diferencias en la arquitectura de estos módulos, actualmente existen algunos esfuerzos combinados entre estos dos proyectos, tales como:

  • creando la forma común de mostrar bloques de facetas a través de Facet API (también conocido como filtros),
  • un esquema común y archivos de configuración solrconfig.xml,
  • ambos mantenedores trabajaron juntos y migraron las clases de conexión del módulo Apache Solr Search a Search API.

Fuente: Battleplan for Search & Solr en Drupal 8 en Acquia

Tenga en cuenta que no se recomienda utilizar ambos módulos en el mismo entorno.

Para un análisis técnico adicional de las diferencias, verifique los detalles a continuación.

API de búsqueda

Descripción general de la API:

  • Marco para crear búsquedas fácilmente
  • Resúmenes de fuentes de datos e implementaciones de backend
  • Gran ecosistema con extensiones, por ejemplo, backends
  • Integración de API de facetas

  • Muy basado en API de entidad

    • Proporciona metadatos.
    • Utilizado para configuraciones de índice y servidor

Características de extensión:

  • Buscar autocompletar API
  • Archivos adjuntos
  • Búsquedas guardadas
  • Ubicación
  • Senderos de facetas bonitas
  • Control deslizante (Buscar rangos de API)
  • y muchos más.

Estructura basica:

Estructura básica del módulo Search API Solr

Características del índice:

  • Diferentes fuentes de datos
  • Una fuente de datos: entidades

  • Basado en la API de la entidad:

    • Cada propiedad puede ser indexada
    • Las propiedades de entidades relacionadas pueden indexarse

Cómo configurar su índice - campos:

Cómo configurar su índice - campos en Search API Solr

Vistas de API de búsqueda:

  • Soporte de vistas completas
  • Mostrar cualquier propiedad de una entidad
  • Use cualquier campo indexado como filtro, argumento u orden
  • La mayoría del código se basa en la integración de vistas de Entity API

  • Por defecto: datos recuperados a través de la carga de la entidad

    • Se puede omitir (configuración "Recuperar datos de Solr" en el servidor)
  • Alternativa: Buscar páginas de API

Buscar recetas de API:

  • Ganchos CRUD para índices y servidores

  • Ganchos para agregar

    • fuentes de datos
    • backends
    • alteraciones de datos
    • procesadores

  • Gancho disparado al indexar elementos

  • Gancho disparado al ejecutar una búsqueda

Apachesolr

Características de extensión:

  • Archivos adjuntos (sin soporte de medios, codificación personalizada para archivos adjuntos a otras entidades)
  • Ubicación (Apachesolr geo, ubicación Apachesolr)

Recetas Apachesolr:

  • Plataforma de búsqueda empresarial de código abierto
  • Fundación Apache
  • Búsqueda de texto completo, resaltado, búsqueda por facetas, agrupamiento, manejo de documentos enriquecido
  • Repartido
  • Replicación / escalable
  • Java
  • REST HTTP y respuestas en XML / JSON y algunos otros
  • No relacional

Fuente: Search API vs Apachesolr slideshow

Ver también:

kenorb
fuente
Redacción impresionante, gracias! Pregunta 1: ¿por qué se recomienda no usar ambos módulos en el mismo entorno? Pregunta 2: ¿Las diferencias de rendimiento entre los módulos son insignificantes en este momento (entiendo que Search API w / solr ahora puede indexar múltiples campos, por lo que ya no es necesaria la carga de la entidad para mostrar, por ejemplo, imágenes en miniatura con resultados de búsqueda)?
Jordan Magnuson
@JordanMagnuson 1. No utiliza ambos módulos al mismo tiempo, porque no son muy compatibles y la mayoría de los sitios web se ocupan solo de una instancia de búsqueda de Solr, por lo que no tiene sentido utilizar ambos, a menos que No importa duplicar el trabajo. Por ejemplo, cuando necesita crear alguna vista de búsqueda, ambos módulos ofrecen integración separada con el módulo de vistas, por lo que necesitaría crear dos vistas.
kenorb
@JordanMagnuson 2. No estoy seguro del rendimiento, nunca he tenido uno específico y probablemente cambie cada versión (estaba usando Apachesolr hace bastante tiempo). Si usa vistas y facetas, generalmente usa el mecanismo de caché de vistas, por lo que no le importa mucho el tiempo de procesamiento y, por supuesto, memcached, APC / XCache, etc. El rendimiento realmente depende de la estructura del sitio y de cómo interactúan los módulos entre sí. otro.
kenorb
Es curioso que Search API se utilice más, pero Acquia recomienda usar el módulo Apache Solr docs.acquia.com/acquia-search/search-api#animated
AlxVallejo
@AlxVallejo Creo que lo recomiendan para la producción, porque tienen archivos de configuración de Apachesolr estables y bien escritos para admitir sus instancias Solr de Acquia Cloud (compartidas) (esa es la única razón, supongo) y dado que Search API estaba activamente en el estado de desarrollo, así que el riesgo involucrado incluía que los archivos de configuración tendrían que actualizarse más a menudo. También lo recomendaron a nuestro proyecto (grande), pero después de un corto tiempo de jugar y verificar nuestros requisitos, cambiamos su recomendación a Search API. No tenían archivos de configuración estables, sin embargo, proporcionamos los nuestros.
kenorb
24

He intentado usar ambos y puedo decir esto: depende de tu situación.

Actualmente, la versión estable 7 del módulo de integración ApacheSolr solo puede indexar nodos. Por lo tanto, si tiene entidades que no son nodos que necesita indexar, debe usar el parche de multientidad aún en progreso para ello. La integración de ApacheSolr puede almacenar muchos datos diferentes de contenido cuando se configura correctamente.

La API de búsqueda indexa las entidades y tiene muchas cosas maravillosas escritas para ello. Sin embargo, la API de búsqueda solo obtiene la identificación de los datos que está buscando. Esto significa que para cargar más datos que no sean la ID, se requerirá una carga de entidad, golpeando su base de datos o cualquier capa de almacenamiento en caché que coloque en su lugar. Para sitios con mucha búsqueda, esta podría no ser la solución más optimizada.

Aquí hay una gran presentación dada en drupalcon chicago sobre el módulo de integración ApacheSolr, minuto 16 para menciones a Search API.

LSU_JBob
fuente
Resumen impresionante. exactamente lo que quería saber. ¡Gracias!
2011
Si esto respondió con éxito a su pregunta, ¿puede marcarla como la respuesta? ¡Gracias!
LSU_JBob
1
Para aquellos de ustedes que se preguntan, la multientidad ahora está en la rama de desarrollo de la integración de apache solr, por lo que debería estar fuera con la próxima versión beta.
LSU_JBob
2
Para aquellos que leen este hilo ... Un factor mitigante en el rendimiento es la API de búsqueda que permite la indexación y recuperación de datos de nodo ahora. Hay una discusión de rendimiento aquí .
hross
1
Esta respuesta está desactualizada, eche un vistazo a drupal.org/node/1999392 search_api_solr ahora tiene opciones multisitio, también permite la devolución no solo del NID. El crecimiento masivo en la base de instalación de search_api_solr en 2014 superó el uso de apachesolr D7.
Duncanmoo
2

Creo que realmente debes probar ambos y tomar una decisión informada. Pero tenga en cuenta que apachesolr todavía no tiene una versión beta para Drupal 8.

En Search API no puede combinar entidades en el mismo índice SearchAPI. Por lo tanto, los perfiles, los usuarios y los nodos están en diferentes índices. Hay un módulo para permitir búsquedas de múltiples índices, no cubrió mis necesidades, pero YMMV. Si tiene muchos tipos de contenido y muchos campos en el mismo índice, la definición del índice puede volverse bastante difícil de manejar. (NB SearchAPI D8 informa que admite búsquedas de índice múltiple)

Apachesolr permite la edición de campos por contenido, lo que puede ser más fácil, pero no tiene la capacidad de agregar contenido relacionado a un documento, de hecho, espera tener que escribir un código personalizado para incluir información de colecciones de campos, referencias y algunos otros campos. Apachesolr D7 no es compatible con ajax, a menos que use vistas, pero al usar vistas pierde facetas. Dicho esto ... modificar la información almacenada en el índice es bastante fácil si está contento de codificar en ganchos.

La idea de buscar identificadores de entidad y luego renderizar cada uno individualmente (puede ser utilizado por ambos módulos) parece ser una pesadilla de rendimiento, pero, si almacena en caché las pantallas de su entidad, podría ser más eficiente que renderizar desde la respuesta solr.

dmcg
fuente