Comparación de los ciclos de vida de índice de Solr y Elasticsearch
Apache Solr y Elasticsearch tienen diferentes métodos para actualizar el índice de búsqueda. Solr realiza actualizaciones Delta en una planificación regular, normalmente cada cinco minutos. Elasticsearch realiza una actualización incremental casi en tiempo real.
Una vez creado el índice de búsqueda completo, podrá actualizarlo rápidamente según sea necesario. Las dos arquitecturas de búsqueda disponibles en HCL Commerce versión 9.1 tienen enfoques ligeramente diferentes para realizar esta actualización. Tanto Apache Solr como Elastsearch están integrados en el sistema más grande HCL Commerce, por lo que comparten determinados componentes, principalmente en el front-end de actualización de catálogo y acceso a la base de datos. Donde difieren en el modo en que se añaden nuevos elementos al índice de trabajo. Solr realiza una operación normal por lotes basada en actualizaciones de la tabla de base de datos CACHEIVL. Elasticsearch Lee también los datos de CACHEIVL, pero luego canales de información en el servicio de introducción, donde permite una vista previa en tiempo real de las actualizaciones en Management Center.
Actualizaciones Delta utilizando Apache Solr
- Un usuario de empresa que trabaja en el entorno de autoría realiza actualizaciones de catálogo en Management Center. Estos cambios actualizan la base de datos.
- La actualización de base de datos desencadena una solicitud de invalidación de índice, que se inserta en la tabla de base de datos CACHEIVL.
- Durante la siguiente operación de indexación, normalmente se ejecuta en un ciclo de cinco minutos, se leen las tablas TI_DELTA_CATENTRY y TI_DELTA_CATGROUP y se actualiza el índice en consecuencia.Note: La reindexación también se produce cuando un usuario desencadena una vista previa del escaparate en Management Center. Puede haber un retardo antes de que esté visible en la vista previa.
- Mientras se actualiza el índice, CACHEIVL puede recibir nuevas solicitudes de invalidación, que se incorporarán en la siguiente operación de indexación planificada.
Push-to-Live en Solr
Cuando se inicia la propagación de transición, la operación de publicación en el servidor de transacciones de autoría replica todos los cambios listos para producción de la base de datos de autoría en la base de datos en tiempo real. Esto desencadena una solicitud de invalidación de memoria caché, que se inserta en la tabla CACHEIVL de la base de datos en tiempo real.
Una vez que se ha completado la propagación de transición, el repetidor de búsqueda inicia la operación IndexProp que extrae la última versión de todos los índices de búsqueda del maestro de búsqueda en el repetidor de búsqueda. Un minuto más tarde, cada subordinado de búsqueda que se ejecuta en el entorno real extrae esta versión.
Una vez que se ha completado la réplica de índice, se inserta una solicitud de reinicio de invalidación de memoria caché en la tabla CACHEIVL de la base de datos en tiempo real. Una vez más, esta base de datos realiza todas las solicitudes de invalidación de memoria caché a partir de una indicación de fecha y hora determinada utilizando el mandato IndexProp.
Actualizaciones de emergencia en Solr
Después de que se haya aprobado una actualización de emergencia en el entorno de Solr, la operación de confirmación planificada en el servidor de transacciones de creación enviará actualizaciones a las bases de datos de autoría y de creación. Este desencadenante almacena en memoria caché una invalidación para las tablas CACHEIVL de las bases de datos de autoría y en tiempo. Cada cinco minutos un trabajo de planificador de indexación en el servidor de transacciones de entorno real comprueba si es necesaria alguna operación de indexación en el repetidor de búsqueda. Mientras se ejecuta la operación de indexación, se insertan solicitudes de invalidación de memoria caché de granulación en la tabla CACHEIVL de la base de datos en tiempo real. Cualquier actualización de índice de emergencia en el repetidor de búsqueda se replicará en cada minuto de búsqueda.
Actualizaciones incrementales utilizando Elasticsearch
Si bien la indexación completa es posible en Elasticsearch (y debe realizarse inicialmente), el enfoque recomendado es realizar actualizaciones incrementales. Si el delta es lo suficientemente pequeño, la cantidad de invalidación en una actualización incremental será relativamente pequeña en comparación con una invalidación completa y reindexación. Esto no significa que no pueda hacer una reindexación completa, simplemente no tiene que hacerlo con tanta frecuencia como lo haría con Solr. Esto se debe a que Solr no tiene invalidación impulsada por eventos y tiene una invalidación mucho más forzada, que requiere una reindexación más frecuente. Elasticsearch tiene una invalidación mucho más detallada y puede estar impulsada por eventos, lo que se puede aprovechar al máximo.
El proceso Elasticsearch se inicia de la misma manera que la reindexación de Solr, pero difiere significativamente tanto en cómo se actualiza el índice como en cómo se propaga la actualización a través de los centros de datos.
- Un usuario de empresa que trabaja en el entorno de autoría actualiza el catálogo en Management Center.
- La actualización desencadena una solicitud de invalidación que se envía a la tabla de base de datos CACHEIVL.
- Estos datos se propagan a lo largo del bus de Redis al servicio Ingest, que utiliza los conductos de Apache NiFi para analizar los datos y actualizar el índice Elastsearch.
- El usuario puede llamar al servicio de consulta para ver estas actualizaciones en el entorno de autoría de una forma eficaz en tiempo real. Para obtener más información, consulte la .API REST de consulta.
- Estos cambios de negocio incrementales de Management Center se representan como sucesos Redis y se vuelven a enviar al servicio Ingest. Aquí se pueden analizar y procesar más.
- Una vez que se ha actualizado el índice, todos los eventos de invalidación de memoria caché relacionados se envían al bus Redis, donde se pueden replicar en cualquier clúster o centro de datos que use.
Push-to-Live utilizando Elasticsearch
Cuando se inicia la propagación de transición, el servidor de transacciones de autoría replica todos los cambios listos para producción de la base de datos de autoría en la base de datos en tiempo real. También emite una solicitud de propagación transición al servicio de introducción para desencadenar una réplica de las actualizaciones aprobadas del índice de creación al índice activo.
Las caches REST y de objeto de datos utilizadas en el servicio de consulta de instancia en vivo también se invalidan. Si procede, las caché JSP utilizadas por el servidor de tienda en la instancia en vivo también se invalidarán.
Este proceso Push-to-Live no requiere la réplica en nodos subordinados, como con Solr. En su lugar, se crea una copia del nuevo índice en vivo en el entorno real y se intercambia en una vez que el nuevo índice está listo. La versión antigua se ha descargado de forma inmediata.
Restriction: Si los cambios de datos de catálogo no están disponibles en las tiendas en directo después de una operación push-to-live, desencadene una operación de invalidación WCT+ESINDEX cuando realice la actualización. Para obtener más información sobre las caché que se deben actualizar y el procedimiento, consulte Los cambios de índice no se reflejan en el escaparate después realizar la operación push-to-live de Elasticsearch.Actualizaciones coordinadas
Puede volver a crear todo el índice de búsqueda como un nuevo índice separado para minimizar el impacto de negocio de tiempo de actualización. Una vez que el nuevo índice se ha vuelto a crear completamente, inmediatamente después de que se haya emitido el suceso de indexación completa, el índice en directo actual se puede intercambiar con el índice recién creado. Esto se lleva a cabo simplemente sustituyendo el índice actual alias.
Si carga una gran cantidad de datos en un conector de introducción, puede insertarlo de forma opcional en una copia separada del índice de destino. Esto se parece a una reconstrucción de índice completa, pero los datos nuevos se cargan encima de una copia del índice de destino.
La estrategia de recuperación ante desastres de Elasticsearch implica la creación de instantáneas de índice de local ES regulares. Esto permite una recuperación de índice acelerada a la instantánea incremental más reciente. Una vez que el índice se ha restaurado por completo, el índice activo actual se puede intercambiar con él y se desencadena un suceso de indexación completada.