Migrar a Elasticsearch
Tiene varias opciones para migrar desde la plataforma de búsqueda Solr a la solución Elasticsearch Versión 9.1.
About this task
La tabla siguiente contiene las directrices generales para ayudarle a migrar la solución de búsqueda basada en Solr a la solución de búsqueda basada en web Elasticsearch.
| Elemento de migración | Con la búsqueda basada en Solr | Con la solución basada en Elasticsearch | Directriz de migración |
| Ingesta / Indexación | |||
| Esquema del índice | Las definiciones de esquema de índice (como campos, filtro y analizadores) se definen en los archivos schema.xml y x-schema.xml. Para obtener detalles, consulte Archivo de esquema de Solr (schema.xml). |
Definido en la especificación de datos para cada tipo de objeto (producto, categoría, atributo, etc.) que forma parte del conector de servicio de ingesta NiFi. | Las definiciones de campos de índice que se encontraban anteriormente en schema.xml Solr están ahora definidas en la especificación de datos para cada tipo de objeto (producto, categoría, atributo, etc.) que forma parte del conector de servicio de ingesta NiFi. Para obtener las especificaciones de los distintos conectores que se utilizan, consulte Canalizaciones de índice de productos de Ingest. |
| Configuración del proceso previo | La configuración del proceso previo se define en XML y los datos se procesan en tablas y vistas de base de datos temporales. Para obtener más información sobre el procesamiento previo de búsqueda, consulte Configurar el preprocesador de búsqueda. El comando di-preprocess está disponible para iniciar el procesamiento previo para el índice de búsqueda en las versiones 7 y 8 de WebSphere Commerce. Este comando se ha eliminado de la versión 9 de HCL Commerce y el procesamiento previo ahora se procesa automáticamente como parte del índice. |
Definido en el conector de servicio de ingesta NiFi (que consta de canalizaciones de entrada, correlación, proceso y salida). | El enfoque para preprocesar datos para el índice ha cambiado significativamente con la nueva arquitectura de la versión 9.1 de HCL Commerce. La configuración del proceso previo no está definida en XML y no hay tablas de base de datos temporales necesarias para aplanar los datos de índice. El nuevo servicio de incorporación maneja la extracción o la recepción y tiene la flexibilidad para procesar datos de diferentes fuentes y para transformar los datos en memoria en un clúster Apache NiFi de alto rendimiento. Los procesos de extracción, transformación y carga (ETL) se definen en el conector de servicio de ingesta NiFi (que consta de procesos de entrada, correlación, procesamiento y salida). Para obtener más información, consulte Canalizaciones de índice de productos de Ingest. |
| Indices de extensión | Algunos datos, como inventario y precio, se pueden crear en un índice independiente para que se puedan actualizar por separado con su propia frecuencia. Para obtener un ejemplo de cómo configurar un índice de inventario independiente, consulte Configurar el preprocesador de búsqueda. |
No es necesario con la nueva función de actualización de índice incremental. | Los índices de extensión ya no son necesarios. Esta solución se ha introducido para utilizarla en la solución de búsqueda basada en Solr para evitar volver a crear todo el documento de índice de entrada de catálogo (producto) base cuando solo se actualizan determinados campos que han cambiado con frecuencia, como inventario y precio. Ahora con la capacidad de actualizar el índice incremental, solo es posible actualizar los campos deseados en cualquier documento indexado existente. Las limitaciones de los índices de extensión, incluida la capacidad de realizar la ordenación, la creación de facetas y la agrupación ahora se mejoran con HCL Commerce 9.1 gracias a la solución de búsqueda basada en Elasticsearch. Esto se debe al hecho de que todos los campos están ahora en el mismo índice de productos. |
| Índices de contenido no estructurado | El contenido no estructurado, como archivos PDF o archivos adjuntos para productos, se puede indexar y categorizar bajo el índice de búsqueda de entradas de catálogo. Para obtener información sobre la indexación de contenido no estructurado con la solución de búsqueda basada en Solr, consulte Contenido no estructurado y contenido del sitio. |
Es necesario crear un único conector de ingesta para cada origen de documentos. | En HCL Commerce 9.1, este proceso se ha simplificado. Es necesario crear un único conector de ingesta para cada origen de documentos. Este proceso le permite personalizar más fácilmente las extensiones que consumirán los datos y cargarlos en los índices del componente de búsqueda. |
| Rastreador del contenido de sitio | El contenido del sitio no administrado del almacén se puede rastrear e indizar en el índice Solr mediante la API REST del rastreador. | Se puede usar un procesador de rastreadores para recopilar e indexar direcciones URL de página web y/o raspar y eliminar contenido de página de índice. Se pueden utilizar más de 250 procesadores NiFi de libre acceso para manejar diferentes escenarios de recepción. También hay muchos ejemplos de casos de uso disponibles de forma gratuita para facilitar su implementación. |
Con HCL Commerce 9.1, el rastreador de sitio puede seguir utilizándose para recopilar los URL de las páginas, pero no cargará automáticamente los datos en el índice de búsqueda. Sin embargo, se puede crear un conector personalizado y una canalización para cargar los datos. En los siguientes artículos se resalta cómo crear una canalización de rastreador web con NiFi: |
| Iniciar creación de índice | El comando di-buildindex está disponible para iniciar creaciones de índice para las versiones 7 y 8 de WebSphere Commerce. La API de creación REST de índice está disponible en la versión 9 y 9.1 de HCL Commerce para iniciar creaciones de índice. Para obtener detalles, consulte Creación del índice de HCL Commerce Search. |
La salida de proceso de NiFi desencadenará una compilación o actualización de índice de Elasticsearch. | En HCL Commerce 9.1, el índice de búsqueda se puede crear desencadenando un trabajo de conector NiFi. Consulte Crear el índice de Elasticsearch para obtener más detalles. |
| Consulta/Tiempo de ejecución | |||
| Configuración de tiempo de ejecución de búsqueda | La configuración relacionada con las características de la aplicación de búsqueda, como el perfil de búsqueda, las expresiones de consulta, las facetas, etc. se pueden definir en wc-server.xml. Para obtener detalles, consulte HCL Commerce Search archivo de configuración (wc-search.xml). Se puede definir en el archivo wc-component.xml la configuración relacionada con el servidor de búsqueda, como la comprobación ortóntica, relevancia, propiedades de tiempo de ejecución de búsqueda, etc. Para obtener detalles, consulte Propiedades de búsqueda en el archivo de configuración de componente (wc-component.xml). |
En general, las configuraciones de búsqueda se almacenan en zookeeper con servicios de consulta REST. |
En HCL Commerce 9.1, ZooKeeper se utiliza para almacenar las configuraciones personalizadas. Durante la ejecución, todos los microservicios examinan ZooKeeper en busca de configuraciones personalizadas para anular automáticamente los comportamientos predeterminados, como las respuestas a las consultas. Para el servicio de Ingest, ZooKeeper almacena descriptores de conectores que se utilizan para cargar nuevos conectores NiFi personalizados. Para obtener más información sobre la configuración de perfiles personalizados en ZooKeeper, así como la implementación de opciones de búsqueda personalizadas, consulte Configuración de servicios de consulta en ZooKeeper.
|
| Perfiles de búsqueda | Los perfiles de búsqueda controlan el comportamiento de la búsqueda en el escaparate manipulando la consulta de búsqueda final y formateando las respuestas de búsqueda. El perfil de búsqueda está definido en wc-search.xml y contiene los campos en los que se están realizando búsquedas, proveedores de expresiones, preprocesadores y postprocesadores de consulta que se van a utilizar y otra información relevante. |
Los perfiles de búsqueda siguen definiendo el comportamiento del tiempo de ejecución de búsqueda. Sin embargo, la información de perfil se almacena ahora en el servicio de configuración dinámica utilizando ZooKeeper y se puede gestionar utilizando REST. | Deben evaluarse los perfiles de búsqueda basados en Solr existentes, junto con los proveedores de expresiones definidos, y los preprocesadores y postprocesadores de consulta personalizados en los perfiles. La introducción del proceso de lenguaje natural (NLP) en la nueva solución de búsqueda basada en Elasticsearch de la versión 9.1 de HCL Commerce puede proporcionar una oportunidad de eliminar personalizaciones de tiempo de ejecución definidas en los perfiles de búsqueda basados en Solr. Para configurar perfiles de búsqueda en ZooKeeper, consulte Configuración de servicios de consulta en ZooKeeper. |
| Proveedores de expresiones de consulta | Los proveedores de expresiones permiten realizar modificaciones en las consultas antes de ser leídos por los preprocesadores de consulta y añadidos a la consulta de búsqueda. Esto permite un mayor control sobre los valores de los parámetros de búsqueda. | La infraestructura de programación de extensiones de proveedor de expresiones de consulta existente también se proporciona con la solución de búsqueda basada en Elasticsearch. Note: El servicio de consulta no proporciona acceso directo a la base de datos. Se deben indexar datos o se deben crear microservicios adicionales para exponer los datos personalizados que son necesarios.
|
Los proveedores de expresiones personalizados relacionados con la relevancia y clasificación de búsqueda deben evaluarse teniendo en cuenta la adición del procesamiento de lenguaje natural (NLP). |
| Preprocesadores de consulta | Los preprocesadores de consulta se usan para modificar la consulta antes de su procesamiento por parte de Solr. Puede utilizar parámetros de control que se proporcionan para la solicitud de búsqueda para añadir datos a la consulta. Por ejemplo, puede añadir un parámetro de ordenación basado en el valor en el parámetro de control de |
La infraestructura de programación de extensiones del proveedor del preprocesador de consulta existente también se proporciona con la solución de búsqueda basada en Elasticsearch. Note: El servicio de consulta no proporciona acceso directo a la base de datos. Se deben indexar datos o se deben crear microservicios adicionales para exponer los datos personalizados que son necesarios.
|
La solución de búsqueda basada en Elasticsearch proporciona mejoras significativas en la coincidencia y clasificación de búsqueda con la introducción de NLP (Procesamiento de lenguaje natural) que puede proporcionar una oportunidad de eliminar la relevancia de búsqueda relacionada con las personalizaciones de tiempo de ejecución. Los preprocesadores de consulta personalizados relacionados con la relevancia y clasificación de búsqueda deben valorarse y evaluarse teniendo en cuenta la adición de NLP. |
| Posprocesadores de consulta | Los posprocesadores de consulta se usan para modificar los resultados de consulta antes de ser devueltos como respuesta de búsqueda. | El índice Elasticsearch y la estructura de la respuesta de búsqueda se estructuran de forma diferente a Solr. Por ello, las dos soluciones también utilizan posprocesadores diferentes. Los posprocesadores personalizados tendrán que volver a crearse para ajustarse a la solución Elasticsearch. Note: El servicio de consulta no proporciona acceso directo a la base de datos. Se deben indexar datos o se deben crear microservicios adicionales para exponer los datos personalizados que son necesarios. |
Los posprocesadores de consulta personalizados deben evaluarse para determinar si la personalización se puede volver a crear en un conector de servicio de ingesta NiFi y utilizarse para estructurar el índice de Elasticsearch estático. Los posprocesadores personalizados que no se pueden mover al tiempo de índice tendrán que volver a crearse, ya que la respuesta de búsqueda de Elasticsearch está en un formato diferente de la respuesta de búsqueda Solr. |
| API REST del escaparate de | HCL Commerce REST API V1 | HCL Commerce REST API V1 y V2 | Los escaparates deben evaluarse por razones de compatibilidad y actualizarse para utilizar la API REST V1 de HCL Commerce. |
| Configuración | |||
| Configuraciones específicas de Solr | Algunas configuraciones de Solr están en archivos de configuración específicos de Solr. Por ejemplo, las propiedades de configuración principales y las URL de solicitud están en solr.xml; y la correlación del manejador de peticiones de Solr y los parámetros de Solr están en el archivo solrconfig.xml. | Estas configuraciones son específicas de Solr y no son necesarias para la solución de búsqueda basada en Elasticsearch. | Estas configuraciones no son necesarias en la solución de búsqueda basada en Elasticsearch. |
| Configuraciones de búsqueda en STORECONF | Algunas propiedades de búsqueda, como la modalidad de precio y la autorización, se configuran como una entrada en la tabla de base de datos STORECONF. | Las propiedades existentes que se configuran en STORECONF siguen siendo válidas. Algunas propiedades nuevas también se almacenan en STORECONF. Por ejemplo, una propiedad para saber si una tienda es desatendida o no. |
No es necesaria ninguna migración. |
| Buscar comercialización y relevancia | |||
| Reglas de búsqueda | Las reglas de búsqueda pueden definirse en la herramienta Marketing en Management Center for HCL Commerce. | Las reglas de búsqueda existentes siguen siendo válidas. | No es necesaria ninguna migración. |
| Asociaciones de términos de búsqueda | Las asociaciones de términos de búsqueda se definen en la herramienta Catálogos en Management Center for HCL Commerce. | Las asociaciones de términos de búsqueda existentes siguen siendo válidas. | No es necesaria ninguna migración. |
| Ajuste de la relevancia | La relevancia de búsqueda se puede ajustar en Management Center for HCL Commerce con la combinación de reglas de búsqueda, asociación de términos de búsqueda y otras funciones de ajuste de búsqueda. | La relevancia de búsqueda se puede ajustar con la característica de NLP (Procesamiento natural del lenguaje). | La relevancia de la búsqueda en la solución de búsqueda basada en Elasticsearch proporciona mejoras significativas en la concordancia de la búsqueda y en la clasificación con la inclusión del Procesamiento del Lenguaje Natural (NLP) y el etiquetado de parte del lenguaje. Se han añadido nuevos filtros NLP que ofrecen más oportunidades para mejorar la experiencia de búsqueda. |
| Imagen principal del producto | La funcionalidad de imagen principal del producto devuelve el artículo más representativo para una búsqueda de productos. | La funcionalidad de imagen principal del producto devuelve el artículo más representativo para una búsqueda de productos. | No es necesaria ninguna migración. |
| Implementación | |||
| Almacenamiento en memoria caché de la búsqueda | El almacenamiento en memoria caché de búsqueda utiliza una memoria caché de objetos de datos utilizando Dynacache con Kafka y ZooKeeper para la invalidación de memoria caché. | HCL Cache, con Redis como proveedor de memoria caché, proporciona almacenamiento en memoria caché de REST y objetos que ofrece invalidación de memoria caché basada en eventos y genérica. La invalidación de memoria caché basada en tiempo (TTL) se proporciona como reserva. | Los microservicios del cliente para exponer datos personalizados deben ser evaluados en cuanto a los requisitos de caché e invalidación. Los sucesos Kafka personalizados (bus de sucesos) deben migrarse a Redis. |
| Tienda local | Una tienda local, es decir, una tienda que se ejecuta en Transaction server, funciona con la búsqueda basada en Solr. | Una tienda local basada en REST puede funcionar con la plataforma de búsqueda basada en Elasticsearch. Una tienda local basada en BOD no funcionará con la solución de búsqueda basada en Elasticsearch. |
Se recomienda utilizar una tienda remota o una tienda sin conexión para trabajar con la solución de búsqueda basada en Elasticsearch. |
| Fragmentación y escalabilidad | Escalado de índice limitado. Sin fragmentación o escalado de tiempo de ejecución o consulta. |
Microservicios escalables de servicio de ingesta. El servicio de consulta proporciona escalabilidad dinámica de tiempo de ejecución y servicios de búsqueda distribuidos utilizando la agrupación en clúster de Elasticsearch. |
No es necesaria ninguna migración. |
Existen varios escenarios para migrar a la solución HCL Commerce Search modernizada en Versión 9.1. Se introducen a continuación.
Procedure
-
Escenario A: (búsqueda antigua + antigua tienda local)
Cuando el cliente existente migra de V7 o V8 a v9.1, se migrará a V9.1 con la búsqueda antigua + tienda Aurora local.
-
Escenario B: (búsqueda antigua + antigua tienda local)
Cuando el cliente de v9.0 existente se actualiza a v 9.1, si este cliente está utilizando la tienda Aurora local (migrada desde V7 o V8), se migrará a V9.1 con la búsqueda antigua + tienda Aurora local.
-
Escenario C: (búsqueda antigua + tienda remota antigua)
Cuando el cliente de v9.0 existente se actualiza a v9.1, si este cliente utiliza la tienda Aurora remota, se migrará a v9.1 con búsqueda de Solr + tienda Aurora remota en v9.1. Nueva fase de implementación x
Una vez que los clientes se han migrado a v9.1 con la búsqueda de Solr y la tienda Aurora (local o remota), le recomendamos que vuelva a implementar la personalización de búsqueda y la tienda con la búsqueda basada en ES y la tienda de React para consumir la tecnología y las características más recientes proporcionadas por la v9.1. Si, por cualquier motivo, no pueden ir a la tienda ES + Tienda de React de inmediato en un solo movimiento, hay las siguientes opciones:
- Siga utilizando la búsqueda de Solr e implemente la tienda Aurora remota, si tiene una tienda Aurora local (búsqueda antigua + tienda antigua)
- Una vez que utilice la tienda remota, implemente la búsqueda basada en ES (nueva búsqueda + tienda remota antigua)
- Finalmente, implemente la tienda de React con búsqueda basada en ES (nueva búsqueda + nueva tienda)
- Durante la transición, es posible que algunas tiendas sigan basándose en Aurora, por lo que podrían tener la tienda Aurora y la tienda React desplegadas en ese momento (nueva búsqueda + nueva tienda + tienda antigua)
-
Nuevo cliente en v9.1
Utilice la búsqueda ES y las tiendas React (nueva búsqueda + nueva tienda).