Esta inquietud se puede abordar de variadas maneras, por lo tanto te compartimos la que para nosotros es la respuesta más completa.
Solución:
Intenté usar ambos y puedo decir esto: depende de su 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 múltiples entidades aún en progreso para ello. La integración de ApacheSolr puede almacenar una gran cantidad de datos de contenido diferentes cuando se configura correctamente.
La API de búsqueda indexa entidades y tiene muchas cosas maravillosas escritas para ella. 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 además de la ID se requerirá un entity_load, golpear su base de datos o cualquier capa de almacenamiento en caché que haya implementado. Para los sitios con muchas búsquedas, es posible que esta no sea la solución más optimizada.
Aquí hay una gran presentación dada en drupalcon chicago sobre el módulo de integración de ApacheSolr, minuto 16 para menciones a la API de búsqueda.
A partir de 2015, podemos comparar los módulos Search API vs Apache Solr Search 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. La API de búsqueda se desarrolló 3 años después y logró aprovecharse de su competidor.
Además, la API de búsqueda proporciona una arquitectura muy diferente y más flexible y se mantiene de forma más activa. Lo que es más importante, ya tiene soporte para 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 algunos problemas sean resueltos dos veces por la comunidad debido a diferencias en la arquitectura de estos módulos, actualmente existen algunos esfuerzos combinados entre estos dos proyectos como:
- creando la forma común de mostrar bloques de facetas a través de Facet API (también conocida 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 de búsqueda de Apache Solr a la API de búsqueda.
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 más detallado de las diferencias, consulte 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 Facet API
-
Basada en gran medida en Entity API
- Proporciona metadatos.
- Se utiliza para configuraciones de índice y servidor
Funciones de extensión:
- Autocompletar API de búsqueda
- Archivos adjuntos
- Búsquedas guardadas
- Ubicación
- Senderos de facetas bonitas
- Control deslizante (rangos de API de búsqueda)
- y muchos más.
Estructura basica:
Características del índice:
- Diferentes fuentes de datos
- Una fuente de datos: entidades
-
Basado en Entity API:
- Cada propiedad se puede indexar
- Las propiedades de las entidades relacionadas se pueden indexar
Cómo configurar su índice – campos:
Vistas de la API de búsqueda:
- Compatibilidad con vistas completas
- Mostrar cualquier propiedad de una entidad
- Utilice cualquier campo indexado como filtro, argumento u ordenación
- La mayor parte del código se basa en la integración de vistas de Entity API
-
De forma predeterminada: datos recuperados a través de la carga de la entidad
- Se puede omitir (configuración “Recuperar datos de Solr” en el servidor)
- Alternativa: páginas de API de búsqueda
Recetas de la API de búsqueda:
- 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
Funciones de extensión:
- Archivos adjuntos (sin soporte de medios, codificación personalizada para archivos adjuntos a otras entidades)
- Ubicación (Apachesolr geo, Apachesolr ubicación)
Recetas Apachesolr:
- Plataforma de búsqueda empresarial de código abierto
- Fundación Apache
- Búsqueda de texto completo, resaltado, búsqueda por facetas, agrupación, manejo de documentos enriquecido
- Repartido
- Replicación / escalable
- Java
- REST HTTP y respuestas en XML / JSON y algunos otros
- No relacional
Fuente: API de búsqueda vs presentación de diapositivas de Apachesolr
Ver también:
- ¿Cuándo vale la pena usar el módulo principal de búsqueda de Drupal?
- ¿Cuáles son las ventajas de utilizar Apache Solr sobre el módulo de búsqueda principal?
Creo que realmente tienes que 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. Entonces, los perfiles, los usuarios y los nodos están en diferentes índices. Hay un módulo para permitir búsquedas multiíndice, no cubría mis necesidades, pero YMMV. Si tiene muchos tipos de contenido y muchos campos en el mismo índice, la definición del índice puede resultar bastante complicada. (Informes NB SearchAPI D8 para admitir búsquedas de índices múltiples)
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, espere tener que escribir un código personalizado para incluir información de colecciones de campos, referencias y otros campos. Apachesolr D7 no admite 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á satisfecho con la codificación en ganchos.
La idea de buscar identificadores de entidad y luego renderizar cada uno individualmente (puede ser utilizado por ambos módulos) parecería una pesadilla de rendimiento, pero, si almacena en caché las visualizaciones de su entidad, podría ser más eficiente que renderizar a partir de la respuesta solr.