El ciclo de vida del índice de Elasticsearch

Estructura, ventajas y ciclo de vida de la versión 9.1. Sistema de Elasticsearch.

Estructura de un índice multidimensional

En la implementación de HCL Commerce versión 9.1 de Elasticsearch, los esquemas de índice se proporcionan para cada esquema de índice. Cada esquema se subdivide adicionalmente en varias clasificaciones. Por ejemplo, el esquema de productos se divide en derecho, precio, inventario, navegación, atributos y propiedades. Cada clasificación se puede indexar Adicionalmente en varios tipos de campo basándose en los usos, como la visualización, la búsqueda, el filtrado, las facetas, el aumento o la clasificación. Para examinar el esquema para este ejemplo, consulte Canalizaciones de índice de productos de Ingest.

El servicio Ingest crea un documento indexado separado para cada idioma soportado, para cada catálogo soportado y para cada tienda. Esto puede ser preocupante si espera que el resultado sea un índice muy grande, y el tamaño sí importa inicialmente cuando configura el índice. Sin embargo, la capacidad de Elasticsearch para realizar actualizaciones incrementales cambia la ecuación una vez que se configura el índice. Si los cambios diarios no son grandes, no verá que el rendimiento se vea afectado en gran medida, como lo estaría si tuviera que hacer una reindexación completa regular. Además, el uso de esites también mejora el rendimiento. Cada sitio electrónico tiene su propio índice, porque cada tienda puede tener su propio ciclo de vida de datos. Opcionalmente, si los sitios web comparten el ciclo de vida de los datos y comparten el catálogo, puede utilizar el enfoque del catálogo maestro con las tiendas.

Cualquier documento indexado se puede utilizar en varios contextos, como aprobado (no publicado) o activo (publicado). Estos pueden tener valores de trabajo en curso, actualizados o sobrescritos, expresados cada uno como un nuevo Campo de índice Nombre con el prefijo adecuado. Tenga en cuenta que los documentos nuevos (o que se deben eliminar) se etiquetan como nuevos (o suprimidos) para evitar que se incluyan en el índice activo.

Solicitudes Push-To-Live

Cuando se inicia la propagación por etapas, la operación de publicación en el Transaction server de creación enviará o replicará todos los cambios listos para producción desde la base de datos de creación a la base de datos activa.

Este método Push-To-Live (PTL) ya no necesita replicarse en nodos subordinados. En su lugar, se creará una copia del nuevo índice en vivo en la base de datos en vivo y se intercambiará una vez que el nuevo índice esté listo. La versión anterior se retirará de inmediato.

Las cachés de objetos de datos y el almacenamiento en caché REST que se utilizan en el servicio de consulta del entorno en vivo se invalidan; el almacenamiento en caché JSP utilizado en el servidor de la tienda también puede invalidarse si corresponde.

Note: Cuando trabaje en el entorno real, compile el índice de inventario activo antes de ejecutar Push-to-live. Para obtener más información sobre esto e información general sobre PTL, consulte Push to Live en la búsqueda.

Configuración inicial del índice

Para hacer una configuración inicial del índice, realice una operación de reindexación completa de los índices de búsqueda para el almacén específico. El proceso de indexación comienza con la creación del esquema, la base de datos del producto y STA. Los datos se cargan desglosando progresivamente en el catálogo y luego en la categoría. Luego, el ciclo de flujo principal asume el mando, procesando los atributos de los productos en las URL de SEO y finalmente emergiendo de ese ciclo, hasta el precio.

En operaciones posteriores de reindexación completa, el nuevo índice se construye en paralelo al existente. Una vez que el nuevo índice está listo, el alias del índice simplemente se actualiza con la ubicación del nuevo. En ese momento, el nuevo índice se convierte en el activo. También hay una cadencia regular de, por ejemplo, actualizaciones de inventario que se pueden programar como trabajos regulares. Estas actualizaciones se pueden realizar mediante una "copia inteligente" en el índice y el precio. La copia inteligente no copia todas las actualizaciones, ya que muchas no habrán cambiado entre ejecuciones. Si se copia todo, se desencadenará el equivalente a una invalidación completa; por lo tanto, la copia inteligente solo mueve los elementos que se han cambiado al índice y solo ellos activarán una invalidación.

Durante este proceso y después, se está haciendo el proceso de lenguaje natural (NLP) y se construyen relaciones de coincidencia, como la coincidencia de colores. Estos elementos no dependen de que el índice esté terminado, sino que complementarán su contenido cuando estén completos. La NLP es costosa de ejecutar, sin embargo, hay características del conjunto de datos de NLP, como la lematización, que rara vez cambian. La primera ejecución de NLP es un poco más larga porque realiza una lematización completa y escribe en el índice; las iteraciones posteriores que se ejecutan son más rápidas, porque no tienen que repetir operaciones ya completadas.

Actualizaciones en tiempo casi real (NRT) en el entorno de autoría

Todas las actualizaciones de datos de negocio en el Centro de gestión se escriben primero en la base de datos. Esto va seguido de un suceso de actualización incremental (junto con el contexto de creación) realizado a través de Redis. Hay lógica de negocio incorporada en la canalización de indexación de Apache NiFi que se utiliza para analizar y procesar estas solicitudes de cambio.

Al actuar como bus de mensajes, Redis difunde esta solicitud de cambio a todos los conectores NiFi que supervisan este tipo de operación. El resultado son actualizaciones incrementales que se realizan en los índices de búsqueda adecuados. La memoria caché de objetos de datos y la memoria caché REST utilizadas en el entorno del Servicio de consulta para la autoría se invalidan; la memoria caché JSP utilizada en el servidor de la tienda también puede invalidarse, si procede.

Este enfoque puede proporcionar una experiencia de actualización en tiempo casi real a través del servicio de consultas, al obtener una vista previa del escaparate en el entorno de creación.

Después de las actualizaciones de NRT puede comprobar el estado del índice de búsqueda para la tienda específica utilizando el siguiente punto final:

http://<HOSTNAME>:<port>/search/resources/api/v2/data/status?storeId=1

Hay una interfaz de Swagger para este punto final, V2-Data-Status, disponible en la API de REST de consultas.

Note: El parámetro envType para este punto final es un parámetro opcional. De forma predeterminada, su valor es auth.

Carga de datos con la búsqueda basada en Easticsearch

Carga de datos, programa de utilidad es una herramienta que carga datos de un archivo fuente en una base de datos de destino. También puede eliminar datos de una base de datos. Dataload admite actualizaciones incrementales de los datos del catálogo si el motor de búsqueda Elasticsearch está habilitado.

: configuración

Configure Dataload para activar actualizaciones de índice incrementales. Para obtener más información, consulte Carga de datos, programa de utilidad.

Proceso de actualización de índices

Después de que el proceso Dataload actualice la base de datos de Commerce con datos empresariales, el historial de cambios correspondiente se escribe en las dos tablas de base de datos TI_DELTA, como es el caso del proceso Solr correspondiente. Una vez que la operación de carga se ha completado con éxito, se envía un evento a través de Redis a NiFi para lanzar un flujo de indexación en NiFi.

La caché de objeto de datos y las cachés REST usadas en el servicio de consulta para el entorno de creación están invalidados. Cualquier almacenamiento en caché JSP utilizado en el servidor de la Tienda también puede invalidarse si corresponde.

Note: Debido a que Dataload se ejecuta como un proceso por lotes no interactivo y puede contener una gran cantidad de actualizaciones de datos, los índices de búsqueda pueden tardar más en completarse y los cambios solo son visibles después de que se realiza la invalidación de la caché.

Consideraciones al utilizar NRT con Dataload:

En la arquitectura Solr, para cambiar el nombre de un producto se necesita un proceso de indexación delta para volver a crear el documento completo del producto especificado. Esto se debe a que Solr no tiene una lógica incorporada para identificar el cambio específico que se está aplicando. Cuando utiliza NRT con Elasticsearch, campos como Producto se actualizan directamente. Esto puede suponer mejoras de rendimiento con respecto a Solr.
La carga de datos sin conexión es el método preferido, ya que utiliza conectividad JDBC directa y es más rápida en comparación con la carga del catálogo. Utilice la carga de datos sin conexión para cargar grandes volúmenes de datos.
Los datos actualizados a través de Dataload se procesarán de la misma manera que con la búsqueda basada en Solr. El programa de utilidad usa las tablas de bases de datos TI_DELTA_CATENTRY y CATGROUP para realizar un seguimiento de qué producto o categoría se ha actualizado.
Elasticsearch se diferencia de Solr en que Dataload enviará un evento "Completo" a través de Redis a NiFi una vez que se complete la operación de carga de datos. Este evento puede tardar hasta cuatro minutos, ya que el trabajo del planificador que se ejecuta en el Transaction server se repite solo una vez a cada intervalo habitual.
Una vez que este evento "Completo" llega a NiFi, el conector auth.dataload procesa aquellos productos o categorías identificados en TI_DELTA_CATENTRY y TI_DETLTA_CATGROUP.
Cuando los espacios de trabajo están habilitados, los datos se pueden cargar directamente en el esquema de contenido aprobado o en el esquema del espacio de trabajo. El conector auth.dataload en NiFi puede realizar la introducción en el esquema de base de datos adecuado según el contexto del espacio de trabajo especificado.
Independientemente de si utiliza espacios de trabajo o no, una vez que Dataload haya cargado correctamente los datos en el entorno de creación, se puede utilizar Push-To-Live para mover los cambios indexados al entorno activo. Consulte los pasos de Push-To-Live para obtener detalles sobre cómo realizar esta tarea. Ejecute StagingProp antes de enviar los datos indexados del entorno de creación al activo.
Cuando se realiza Push-To-Live, el índice de creación se clonará en el entorno activo (con la excepción de todos los documentos y metadatos relacionados con el espacio de trabajo), lo que vendrá seguido posteriormente por una serie de eventos de invalidación de memoria caché relevantes. Esta invalidación de memoria caché detallada se basa únicamente en productos o categorías que se hayan actualizado como resultado de la propagación por etapas y Push-To-Live.

Copias de seguridad de índices

Al compilar un índice, de forma predeterminada se guardan copias de seguridad de las dos compilaciones anteriores. Este valor no afecta al rendimiento, aunque en determinadas circunstancias puede observar incoherencias aparentes en los registros. Por ejemplo, si ejecuta varias reconstrucciones del índice de tienda 1, tienda 11 o eSite en una sucesión rápida, esperaría ver solo un índice con la indicación de fecha y hora más reciente. No obstante, dado que las copias de seguridad se quedan guardadas, es posible que vea dos índices con la misma indicación de fecha y hora. Esto simplemente indicaría que se están creando copias de seguridad y que a la copia de seguridad más reciente se le ha otorgado la misma indicación de fecha y hora que al índice activo actual.

Puede controlar el comportamiento de la copia de seguridad del índice mediante el valor de configuración alias.keep.backup. En primer lugar, puede comprobar el valor actual emitiendo una solicitud GET al siguiente endpoint de REST:

https://Data-Query:Port/search/resources/api/v2/configuration?nodeName=ingest&envType=auth

Busque el parámetro alias.keep.backup. Su valor predeterminado es 2.

Para cambiar el valor, emita una solicitud PATCH al mismo endpoint. Por ejemplo, para establecer el número de copias de seguridad en cero (el comportamiento predeterminado anterior a la versión 9.1.13), emita una solicitud PATCH con el cuerpo siguiente:

Body: { "global": { "connector": [ { "name": "attribute", "property": [ { "name": "alias.keep.backup", "value": "0" } ] } ] } }

En este ejemplo, como resultado no se crea ningún índice de copias de seguridad. Puede ajustar el número de copias de seguridad según corresponda a su entorno.