Por qué el core search de Drupal se rinde antes de tiempo

El módulo search que viene de serie con Drupal 10 (y sigue ahí en 11) cumple cuando tienes cuatro páginas y un blog. En cuanto el sitio crece, la cosa se complica.

El motivo es simple: el buscador interno tira consultas SQL contra search_index y search_dataset, y eso tiene un techo bajo:

• El rendimiento se desploma a medida que la tabla search_index engorda; en sitios con decenas de miles de nodos, las consultas con LIKE duelen.
• No hay relevancia configurable: olvídate de boost por campo, stemming serio o sinónimos. Lo que ves es lo que hay.
• Cero facetas nativas: si quieres que el usuario filtre por taxonomía, rango de fechas o tipo de contenido, te toca picar código o vivir con vistas y exposed filters torpes.
• Sin autocompletado de fábrica.
• El multilingüe es regular: la tokenización del módulo core no entiende ni stemming en español ni análisis lingüístico por idioma.

Para portales corporativos, e-commerce, intranets con miles de documentos o medios editoriales, estas limitaciones bastan para meter un motor de búsqueda dedicado en la pila.

Qué te llevas cuando enchufas Apache Solr a Drupal

Solr es un motor de búsqueda full-text construido sobre Apache Lucene, y está corriendo en producción en sitios que mueven volúmenes que tu Drupal nunca tendrá. Lo que aporta:

• Índice invertido que devuelve resultados en milisegundos aunque tengas millones de documentos.
• Faceted search de verdad: el usuario filtra dinámicamente por categorías, etiquetas, rangos de precio, fechas y cualquier campo indexado.
• Relevancia configurable: boost por campo (qf), funciones de scoring (bf), mm para tolerancia a términos faltantes y perfiles de consulta a medida.
• Análisis lingüístico por idioma: stemming, stop words, normalización de acentos y sinónimos, todo configurable.
• Autocompletado y sugerencias alimentadas por el propio índice, sin inventarse términos.
• Escalabilidad horizontal con SolrCloud cuando toque pensar en alta disponibilidad.

La idea de fondo: Drupal hace de CMS, Solr hace de buscador, y cada uno se centra en lo suyo sin pisarse.

Instalación y configuración: Search API y el módulo Solr

Requisitos previos

Lo primero, un Solr funcionando. Las opciones de siempre:

• Instalación local con el paquete oficial de Apache Solr (8.x o 9.x; en proyectos nuevos, 9.x).
• Docker: la imagen oficial solr te quita problemas en dev y staging.
• Servicios gestionados tipo Acquia Search, SearchStax o Websolr si no quieres administrar el servidor.

Módulos en Drupal

Dos módulos que no se discuten:

1. Search API (search_api): la capa de abstracción que define servidores, índices y procesadores con independencia del backend.
2. Search API Solr (search_api_solr): el backend de Solr, que habla con el core y genera los ficheros de configuración.

Composer y Drush, lo de toda la vida:

composer require drupal/search_api_solr
drush en search_api search_api_solr -y

Configuración del servidor

En Configuración > Búsqueda y metadatos > Search API, crea un servidor nuevo:

• Backend Solr.
• Host, puerto y ruta del core, por ejemplo localhost, 8983, /solr/drupal.
• Si hay autenticación básica o TLS, la pestaña de conexión avanzada es donde lo configuras.

Search API Solr genera por ti los ficheros que el core necesita (schema.xml, solrconfig.xml, los _es.txt para sinónimos y stop words, etc.). Los descargas desde la interfaz, los copias al directorio conf del core y reinicias Solr. Ojo: olvidarse de subir el schema.xml regenerado tras tocar campos es uno de los clásicos del drift entre staging y producción.

Creación del índice

Asocias un índice al servidor y defines:

• Fuentes de datos: típicamente nodos, pero también users, términos de taxonomía o entidades personalizadas.
• Campos a indexar: título, body, campos custom, taxonomías, fecha de publicación, autor. Cada uno con su tipo Solr: text_es para texto en español (con su analizador), string para valores sin tokenizar, integer para numéricos, date para fechas.
• Procesadores: los componentes que transforman datos antes de indexar o consultas antes de ejecutarse.

Indexación con cabeza: procesadores y campos

Los procesadores de Search API son lo que separa una búsqueda que funciona de una que de verdad sirve. Los que uso en casi todos los proyectos:

• HTML filter: fuera etiquetas, fuera ruido.
• Tokenizer: parte el texto en tokens siguiendo reglas lingüísticas.
• Stemmer: reduce palabras a su raíz para que "configuración" y "configurar" matcheen. En español va con el SpanishLightStemFilterFactory que Solr trae de serie.
• Stopwords: fuera artículos y preposiciones que no aportan nada.
• Transliteration: normaliza acentos para que "móvil" y "movil" no sean cosas distintas.
• Type boost: sube relevancia a tipos de contenido concretos.

El orden importa, y mucho. Primero limpieza, luego transformación, al final ajuste de relevancia. Cambiar ese orden te puede dejar resultados sin tildes pero con HTML dentro, y entonces toca reindexar.

Indexación inicial desde la interfaz o por Drush:

drush search-api:index nombre_del_indice

En sitios grandes, deja que cron haga la indexación incremental para que los nodos nuevos o editados entren al índice sin reindexar el corpus entero. Las reindexaciones completas en producción son uno de esos placeres que solo se disfrutan a las tres de la mañana.

Facetas personalizadas: filtrado dinámico para el usuario

Las facetas son lo que convierte una caja de búsqueda en una herramienta de exploración. El módulo Facets (facets) se enchufa a Search API y permite construir filtros laterales sobre cualquier campo indexado.

Instalación y configuración básica

composer require drupal/facets
drush en facets -y

En Configuración > Búsqueda y metadatos > Facets, creas una faceta asociada a tu Search API view. Eliges el campo a filtrar y un widget: enlaces, checkboxes, dropdown o rango.

Sobre la implementación de cómo implementar un sistema de búsqueda avanzada con Apache Solr y facetas personalizadas en Drupal, esta es la pieza donde Facets se nota más, sobre todo si combinas widgets distintos por contexto.

Facetas avanzadas y personalizadas

Más allá de lo básico, hay margen para hilar fino:

• Facetas jerárquicas: si la taxonomía tiene árbol (por ejemplo, "Servicios > Desarrollo > Drupal"), la faceta refleja esa estructura y permite drill-down.
• Facetas de rango: para precios, fechas o numéricos. El usuario fija mínimo y máximo.
• Facetas combinadas: varios filtros simultáneos con lógica AND u OR según convenga.
• Facetas dependientes: solo aparecen cuando otra faceta está activa, para no saturar la interfaz cuando el usuario aún no ha decidido nada.

Para algo realmente a medida, implementas un plugin extendiendo WidgetPluginBase del módulo Facets, y desde ahí controlas markup y presentación al milímetro.

Boosting: que lo relevante salga arriba

No todos los campos pesan lo mismo. Que un término aparezca en el título no es lo mismo que aparezca en el body, y Solr te deja afinarlo:

• Field boosting: multiplicador por campo, normalmente en el qf. Un título con boost 5.0 frente a un body con 1.0 prioriza coincidencias en el titular.
• Document boosting: empuja documentos enteros según tipo de contenido, fecha o un campo "destacado", típicamente vía bf con una función de decaimiento temporal (recip).
• Query-time boosting: reglas de elevación en elevate.xml para fijar resultados concretos arriba en consultas específicas. Útil para términos comerciales que la relevancia natural no acierta.

Esto no se ajusta a ojo: revisa las queries más frecuentes en los logs y verifica que los resultados que deberían salir primero salen primero. Iteración, no adivinación.

Autocompletado: resultados antes de soltar la tecla

El módulo Search API Autocomplete (search_api_autocomplete) añade sugerencias en tiempo real mientras el usuario teclea. Solr alimenta esas sugerencias desde el índice real, así que solo aparecen términos que de verdad tienen resultados detrás (nada de prometer lo que no hay).

composer require drupal/search_api_autocomplete
drush en search_api_autocomplete -y

Lo configuras en la vista de búsqueda correspondiente, eligiendo entre sugerencias basadas en contenido indexado o en historial de búsquedas previas.

Búsqueda multilingüe con Solr

Drupal trae un soporte multilingüe sólido, y Solr lo complementa con naturalidad. Search API Solr crea campos específicos por idioma y aplica el analizador lingüístico correcto a cada uno: text_es con el stemmer en español, text_en con el suyo, etc.

Para que el multilingüe se porte:

• Incluye el campo de idioma en el índice como filtro.
• Comprueba que los ficheros de configuración llevan los analizadores de cada idioma (el módulo los genera, pero conviene verificarlo tras regenerar).
• Configura facetas de idioma si quieres que el usuario filtre por lengua.
• Si tienes traducción parcial, define una estrategia de fallback para que las búsquedas en un idioma devuelvan resultados en el idioma por defecto cuando no haya traducción.

Rendimiento y optimización en producción

Un buscador avanzado pide cariño en rendimiento. Lo que suele marcar diferencia:

• Caché de consultas: Solr cachea filtros y queries frecuentes. Ajusta queryResultCache y filterCache en solrconfig.xml según el perfil de tu sitio, sin pasarte con la memoria.
• Estrategia de commit: nada de commits síncronos por documento. Configura autoSoftCommit cada pocos segundos para visibilidad rápida sin matar al servidor.
• Segmentos y merge: programa optimizaciones del índice en horarios de bajo tráfico, no en mitad del Black Friday.
• Réplicas de lectura: en escenarios de alta concurrencia, SolrCloud con varias réplicas reparte la carga de consultas.
• Lazy loading de facetas: cárgalas por AJAX para no bloquear el renderizado de la página de resultados.

Monitorización y diagnóstico

Una vez en producción, hace falta visibilidad:

• Panel de administración de Solr: estadísticas del core, uso de caché, queries lentas y estado de réplicas.
• Logs de consultas: activa el slow query log de Solr para detectar lo que se pasa de tiempo.
• Search API reports: el propio módulo te da el estado de la indexación, documentos pendientes y errores.
• Stack externo: integra Solr con Prometheus y Grafana para dashboards y alertas en tiempo real.

Y revisa con cierta frecuencia las búsquedas con cero resultados: te van a chivar contenido que falta, sinónimos que tendrías que estar configurando en synonyms_es.txt, o errores tipográficos recurrentes que el componente de sugerencias de Solr puede manejar sin despeinarse.

Búsqueda real: cuando el usuario encuentra lo que ni sabía que buscaba

Montar Apache Solr con facetas personalizadas en Drupal no es cambiar un módulo por otro: es replantear cómo la gente encuentra cosas en tu sitio. Pasas de una caja de texto pasiva a una herramienta de exploración que se adapta al contenido que ya tienes.

El trabajo de configuración se recupera en métricas: menos rebote, más tiempo en página y, en e-commerce, conversión directa. La regla es simple: el usuario que encuentra lo que busca, vuelve.

Si tu Drupal se ha quedado pequeño con su buscador nativo, hablemos del salto a Solr sin sorpresas en producción.