Características de los índices de las tiendas con elementos de catálogo
La indexación en el modelo de tienda con elementos de catálogo (CAS) es diferente del enfoque de los eSites. También tiene un índice de URL y mejoras en tiempo casi real (NRT) que reducen la carga del procesamiento y mejoran la eficiencia.
Etapas de la indexación
El proceso de indexación de los eSites heredados utiliza el flujo del conector de reindexación para indexar tiendas de eSite. Hay una canalización del proceso principal y etapas laterales opcionales donde se puede producir un proceso de datos adicional.
Cada flujo de proceso solo puede gestionar una tienda y un idioma a la vez. Un componente del control de flujo se utiliza para realizar flujos de datos internos recurrentes con el objetivo de gestionar los idiomas compatibles adicionales.
Las URL de SEO y otros metadatos relacionados se indexan en un índice de URL independiente para las búsquedas durante la consulta.
Cada etapa de flujo lateral se construye de forma similar a partir de un diseño del contenedor modelo, con un módulo de entrada, un módulo de proceso principal y un módulo de salida. La etapa se conecta mediante un enlace a la siguiente etapa, y también invoca un proceso de registro. Dentro de esta estructura, puede personalizar el proceso de acuerdo con los objetivos de la empresa.
El flujo de indexación CAS es ligeramente diferente. Procesa todos los sitios ampliados subyacentes y todos los idiomas compatibles en un único flujo de datos.
El flujo de proceso principal CAS es muy similar al modelo de eSite, excepto en que la etapa de URL se sustituye ahora por una etapa de página que solo indexa la plantilla SEO asociada con cada palabra clave. Para obtener más información, consulte Mejoras del índice de URL a continuación. Todas las URL de SEo se indexan en el índice de categorías y productos.
El flujo de canalización de la indexación CAS es muy similar al modelo de eSite, pero el diseño del flujo de datos interno es bastante diferente:
Ya no se graban graba actualizaciones incrementales en Elasticsearch en cada etapa. En su lugar, cada etapa transmite el documento de trabajo en curso hasta la siguiente etapa, donde se pueden fusionar los datos adicionales del negocio. Este proceso se repite hasta llegar al final de la canalización de la indexación en un canal de producto final.
Al final de cada canalización (es decir, una serie de etapas y canalizaciones), el documento de trabajo en curso se convertirá en un documento listo para indexarlo en Elasticsearch. Este documento completado se enviará a Elasticsearch una sola vez.
Todos los archivos de flujo son autónomos. Contienen toda la información y los datos que se han utilizado para ensamblar su contenido. Este enfoque elimina la dependencia en cualquier almacenamiento temporal externo entre etapas, evita la necesidad de coordinar archivos de flujo entre etapas (es decir, WaitLink) e incluso facilita la resolución de problemas.
Es mucho más sencillo utilizar un SQL para extraer los datos del negocio de la fuente de datos, como una base de datos. Los ID se pasan como atributos de archivo de flujo, por lo que las etapas en sentido descendente ya no necesitan volver a compilar el contexto para volver a delimitar la fuente del conjunto de datos.
Personalizar Ingest es más fácil. No es necesario que comprenda cómo se han creado los documentos predeterminados. Para realizar una personalización general de cualquier documento de indexación, todo lo que debe hacer es etiquetarla al final de nuestra canalización predeterminada y realizar los cambios personalizados necesarios antes de enviarlos a Elasticsearch.
Mejoras del índice de URL
- Nuevo índice de página
- El índice de URL predeterminado, que se utiliza en el modelo de indexación eSite, incluye todos los productos, categorías y páginas. La mayor parte de esta información está duplicada en el índice de productos y en el de categorías. Como resultado, el índice de URL es muy grande y puede tardar mucho tiempo en procesarse y sincronizarse.
- Nueva etapa de página
- En el modelo de indexación de eSite, la indexación de URL incluye tres etapas en las que se procesan productos, categorías y páginas. En el modelo de tienda con elementos, estas etapas se sustituyen por una etapa de página, que procesa los tres tipos juntos. Esto simplifica en gran medida el proceso de indexación y mejora el rendimiento.
- Servicio de consulta de URL
- Un distintivo a nivel de sitio en el servicio de consulta indica qué modelo de índice se está utilizando. Durante la ejecución, el servicio de consulta de URL consulta el índice de páginas para obtener la plantilla de la página y, a continuación, consulta el índice de productos o el de categorías para recuperar la información necesaria para rellenar la plantilla. Si hay un token de descripción completo en la plantilla de la página, el servicio de consulta de URL también consulta el índice de descripciones para obtener descripciones largas de los productos o las categorías.
A continuación, el servicio de consulta de URL invoca al Transaction server para obtener información sobre el diseño de la página.
Hay un perfil independiente para el modelo de índice de tienda con elementos. El perfil puede definir las diferentes clases de proveedores, preprocesadores y posprocesadores del modelo de índice de tienda con elementos. De este modo, se puede utilizar el mismo proceso de servicio de consulta para dar soporte a ambos modelos de índice.
Mejoras en tiempo casi real (NRT)
- Reducir el número de flujos
- En el modelo de índice de tienda de eSite, cada combinación de eSite e idiomas genera un flujo NRT. Por lo tanto, el número de flujos es igual al número de eSites por el número de idiomas. Cuando se indexan más que solo unos pocos idiomas, el tiempo de la indexación aumenta en una de manera sustancial.
En el modelo de índice de tienda con elementos, solo un flujo compila todas las tiendas eSite y todos los idiomas. Esto mejora de forma sustancial el rendimiento sobre el modelo eSite.
- Jerarquía de categorías
- Cuando cambia el padre de una categoría, se vuelve a compilar la jerarquía de categorías. En el modelo de tienda de eSite sitio electrónico se actualizan todas las jerarquías de categorías, incluso si solo se vuelve a asignar una categoría.
En el modelo de índice tienda con elementos, solo se actualiza la jerarquía de las categorías padre, la categoría que se vuelve a asignar y sus subcategorías. Como resultado, se envían menos actualizaciones al servidor de Elasticsearch.
- No es necesario actualizar el índice de URL
- Cuando cambia productos o categorías en el modelo de tienda eSite, se vuelve a compilar el índice de URL para estos productos o categorías. En total hay seis etapas relacionadas con el índice URL.
Ajuste del rendimiento sencillo
El número de entradas de catálogo en cada archivo de flujo se controla mediante la variable scroll.bucket.size en la etapa auth.reindex.cas - Product Stage 1a (Main Document). Puede establecer un valor entre 100 y 1000, en función del tamaño del catálogo. Si el tamaño de catálogo es grande, establezca el scroll.bucket.size en un número más pequeño, como, por ejemplo, 200. Además, la variable scroll.page.size también se puede establecer en un número más pequeño, como, por ejemplo, 10000.
Si encuentra que hay muchos flujos atascados en una etapa determinada, puede aumentar el número en el campo Tareas simultáneas de la pestaña Planificación de la ventana Configurar procesador y el Número máximo de conexiones totales en la pestaña Propiedades de la Agrupación de conexiones de bases de datos.
Limitaciones
- Reserva del idioma
- La reserva del idioma no es compatible actualmente con el modelo de índice de tienda con elementos de catálogo. El valor predeterminado del parámetro flow.language.fallback es "true", y esto permanece sin cambios cuando se activa la CAS a pesar de la limitación. Puede dejarlo establecido en "true". Para obtener más información sobre cómo establecer flow.language.fallback y los parámetros relacionados, consulte Configuración de Ingest a través de REST.