Migration des vers Elasticsearch

Vous avez plusieurs options pour migrer de la plateforme de recherche Solr vers la solution Elasticsearch version 9.1.

About this task

Le tableau suivant contient une instruction générale pour vous aider à migrer votre solution de recherche basée sur Solr vers la solution de recherche basée sur Elasticsearch.

Elément de migration Avec la recherche basée sur Solr Avec la recherche basée sur Elasticsearch Instruction de migration
Ingestion/Indexation
Schéma d'index Les définitions de schéma d'index (telles que les zones, les filtres et les analyseurs) sont définies dans les fichiers schema.xml et x-schema.xml.

Pour plus de détails, voir Fichier de schéma Solr (schema.xml).

 Définition dans la spécification de données pour chaque type d'objet (produit, catégorie, attribut, etc.) qui fait partie du connecteur du service NiFi Ingest. Les définitions de zone d'index qui se trouvaient précédemment dans Solr schema.xml sont désormais définies dans la spécification de données pour chaque type d'objet (produit, catégorie, attribut, etc.) qui fait partie du connecteur du service NiFi Ingest.

Pour les spécifications des différents connecteurs utilisés, voir Pipeline d'index Produit Ingest.
Configuration de prétraitement La configuration de prétraitement est définie dans des fichiers XML et les données sont traitées dans des tableaux et des vues de base de données temporaires.

Pour plus d'informations sur le prétraitement de recherche, voir Configuration du préprocesseur de recherche.

La commande di-preprocess est disponible pour lancer le prétraitement pour l'index de recherche dans WebSphere Commerce versions 7 et 8. Cette commande a été supprimée de la version 9 de HCL Commerce et le prétraitement est désormais automatiquement traité dans le cadre de l'index.

 Définition dans le connecteur du service NiFi Ingest (composé de pipelines d'entrée, de mappage, de traitement et de sortie). L'approche du prétraitement des données pour l'index a considérablement changé avec la nouvelle architecture de HCL Commerce version 9.1.

La configuration du prétraitement n'est plus définie dans les fichiers XML et aucun tableau de base de données temporaire n'est nécessaire pour mettre à plat les données d'index. Le nouveau service Ingest gère l'extraction ou l'ingestion et dispose de la flexibilité nécessaire pour traiter les données provenant de nombreuses sources différentes et transformer les données en mémoire dans un cluster Apache NiFi à hautes performances. Les processus d'extraction, de transformation et de chargement (ETL) sont définis dans le connecteur du service NiFi Ingest (composé de pipelines d'entrée, de mappage, de traitement et de sortie). Pour plus d'informations, voir Pipeline d'index Produit Ingest.
Index d'extension Certaines données, telles que le stock et le prix, peuvent être intégrées dans un index distinct afin de pouvoir être mises à jour séparément à leur propre fréquence.

Pour obtenir un exemple de configuration d'un index de stock distinct, voir Configuration du préprocesseur de recherche.

 Non requis avec la nouvelle fonction de mise à jour incrémentielle de l'index. Les index d'extension ne sont plus nécessaires. Cette solution a été introduite pour être utilisée dans la solution de recherche basée sur Solr afin d'éviter la reconstruction de l'intégralité du document d'index d'entrée de catalogue (produit) de base lorsque seules certaines zones fréquemment modifiées, telles que le stock et le prix, sont mises à jour. Désormais, avec la possibilité de mettre à jour l'index incrémentiel, il est possible de mettre à jour uniquement les zones souhaitées dans tout document indexé existant. Les limitations des index d'extension, y compris l'impossibilité d'effectuer le tri, la création de facettes et le regroupement sont désormais levées avec HCL Commerce 9.1 avec la solution de recherche basée sur Elasticsearch. Cela est dû au fait que toutes les zones se trouvent maintenant dans le même index de produit.
Index de contenu non structuré Le contenu non structuré, tel que les fichiers PDF ou les fichiers joints pour les produits, peut être indexé et catégorisé dans l'index de recherche d'entrée de catalogue.

Pour plus d'informations sur l'indexation de contenu non structuré avec la solution de recherche basée sur Solr, voir Contenu non structuré et de site.

 Un connecteur Ingest unique doit être créé pour chaque source de documents. Dans HCL Commerce 9.1, ce processus a été simplifié. Un connecteur Ingest unique doit être créé pour chaque source de documents. Ce processus vous permet de personnaliser plus facilement les extensions qui consommeront les données et de les charger dans les index du composant de recherche.
Explorateur de contenu de site Le contenu de site non géré du magasin peut être exploré et indexé dans l'index Solr à l'aide de l'API REST du moteur de balayage. Un processeur du moteur de balayage peut être utilisé pour collecter et indexer des URL de page Web et/ou supprimer et indexer le contenu de la page.

Plus de 250 processeurs NiFi disponibles gratuitement peuvent être utilisés pour gérer différents scénarios d'ingestion.

Il existe également de nombreux exemples de cas d'utilisation disponibles gratuitement pour faciliter leur implémentation.

 Avec HCL Commerce 9.1, le moteur de recherche de site peut continuer à être utilisé pour collecter les URL des pages, mais il ne chargera pas automatiquement les données dans l'index de recherche.

Toutefois, un connecteur et un pipeline personnalisés peuvent être créés pour charger les données.

Les articles suivants mettent en évidence la façon de créer un pipeline de moteur de balayage du Web avec NiFi :
Lancement de la génération de l'index La commande di-buildindex est disponible pour lancer des générations d'index pour WebSphere Commerce versions 7 et 8.

L'API REST d'index de génération est disponible dans HCL Commerce versions 9 et 9.1 pour lancer des générations d'index. Pour plus de détails, voir Génération de l'index HCL Commerce Search.

 La sortie du pipeline NiFi déclenchera une mise à jour ou une génération d'index Elasticsearch. Dans HCL Commerce 9.1, l'index de recherche peut être créé en déclenchant un travail de connecteur NiFi.

Voir Création de l'index Elasticsearch pour plus d'informations.
Requête/Exécution
Configuration de l'exécution de recherche La configuration associée aux fonctions d'application de recherche, telles que le profil de recherche, les expressions de requête, les facettes, etc., peut être définie dans wc-server.xml. Pour plus de détails, voir HCL Commerce Search fichier de configuration (wc-search.xml).

La configuration liée au serveur de recherche, telle que la vérification orthographique, la pertinence, les propriétés d'exécution de la recherche, etc. peut être définie dans le fichier wc-component.xml. Pour plus de détails, voir Propriétés de recherche dans le fichier de configuration de composant (wc-component.xml).

 En général, les configurations de recherche sont stockées dans ZooKeeper avec les services REST de Query.

Dans HCL Commerce 9.1, ZooKeeper est utilisé pour stocker vos configurations personnalisées. Lors de l'exécution, chaque microservice interroge ZooKeeper pour obtenir des configurations personnalisées afin de remplacer automatiquement les comportements par défaut, tels que les réponses aux requêtes. Pour le service Ingest, ZooKeeper stocke les descripteurs de connecteur utilisés pour charger de nouveaux connecteurs NiFi personnalisés.

Pour plus d'informations sur la configuration de profils personnalisés dans ZooKeeper, ainsi que sur l'implémentation d'options de recherche personnalisées, voir Configuration des services Query dans ZooKeeper.
Rechercher dans les profils Les profils de recherche contrôlent le comportement de la recherche dans la vitrine en manipulant la requête de recherche finale et en formatant les réponses de recherche.

Le profil de recherche est défini dans wc-search.xml et contient les zones recherchées, les fournisseurs d'expression, les préprocesseurs et les postprocesseurss de requêtes à utiliser, ainsi que d'autres informations pertinentes.

 Les profils de recherche définissent toujours le comportement d'exécution de la recherche. Toutefois, les informations de profil sont maintenant stockées dans le service de configuration dynamique à l'aide de ZooKeeper et peuvent être gérées à l'aide de REST. Les profils de recherche basés sur Solr existants doivent être évalués, avec les fournisseurs d'expression définis, ainsi que tous les préprocesseurs et les postprocesseurss de requêtes personnalisés dans les profils.

L'introduction du traitement du langage naturel (NLP) dans la solution de recherche basée sur Elasticsearch de la nouvelle version 9.1 de HCL Commerce peut fournir une opportunité de supprimer les personnalisations d'exécution définies dans vos profils de recherche basés sur Solr.

Pour configurer des profils de recherche dans ZooKeeper, voir Configuration des services Query dans ZooKeeper.
Fournisseurs d'expressions de requête Les fournisseurs d'expressions de requête permettent de modifier les requêtes avant qu'elles ne soient lues par les préprocesseurs de requête et ajoutées à la requête de recherche. Cela permet de mieux contrôler les valeurs des paramètres de recherche. La structure de programmation d'extension du fournisseur d'expressions de requête existante est également fournie avec la solution de recherche basée sur Elasticsearch.
Note: Le service Query ne fournit pas d'accès direct à la base de données. Les données doivent être indexées ou des microservices supplémentaires doivent être générés pour exposer les données personnalisées requises.
 Les fournisseurs d'expressions personnalisées liés à la pertinence de la recherche et au classement doivent être évalués en tenant compte de l'ajout du traitement du langage naturel (NLP).
Préprocesseurs de requête Les préprocesseurs de requête sont utilisés pour modifier la requête avant qu'elle ne soit traitée par Solr. Vous pouvez utiliser les paramètres de contrôle fournis pour la requête de recherche afin d'ajouter des données à la requête.

Par exemple, vous pouvez ajouter un paramètre de tri basé sur la valeur dans le paramètre de contrôle _wcf.search.sort.

 La structure de programmation d'extension du fournisseur de prétraitement de requête existante est également fournie avec la solution de recherche basée sur Elasticsearch.
Note: Le service Query ne fournit pas d'accès direct à la base de données. Les données doivent être indexées ou des microservices supplémentaires doivent être générés pour exposer les données personnalisées requises.
 La solution de recherche basée sur Elasticsearch fournit des améliorations significatives à la mise en correspondance et au classement de la recherche avec l'introduction du traitement du langage naturel (NLP), qui peut donner la possibilité de supprimer la pertinence de recherche liée aux personnalisations de l'exécution. Les préprocesseurs de requête personnalisés liés à la pertinence de la recherche et au classement doivent être évalués en tenant compte de l'ajout du traitement du langage naturel (NLP).
Postprocesseurss de requêtes Les postprocesseurss de requêtes sont utilisés pour modifier les résultats de la requête avant qu'ils ne soient renvoyés en tant que réponse de la recherche. L'index Elasticsearch et la structure de la réponse de la recherche sont structurés différemment par rapport à Solr. Par conséquent, les deux solutions utilisent également des postprocesseurss différents.

Tous les postprocesseurss personnalisés devront être recréés pour se conformer à la solution Elasticsearch.

Note: Le service Query ne fournit pas d'accès direct à la base de données. Les données doivent être indexées ou des microservices supplémentaires doivent être générés pour exposer les données personnalisées requises.
 Les postprocesseurss de requête personnalisés doivent être évalués pour déterminer si la personnalisation peut être recréée en tant que connecteur du service NiFi Ingest et utilisée pour structurer l'index Elasticsearch statique.

Les postprocesseurss personnalisés qui ne peuvent pas être déplacés vers l'heure d'indexation devront être recréés, car la réponse de recherche Elasticsearch est dans un format différent de la réponse de recherche Solr.

API REST de vitrine HCL Commerce API REST V1 HCL Commerce API REST V1 et V2 Les vitrines doivent être évaluées pour la compatibilité et mises à jour pour utiliser l'API REST HCL Commerce V1.
Configuration
Configurations spécifiques à Solr Certaines configurations Solr se trouvent dans des fichiers de configuration spécifiques à Solr. Par exemple, les propriétés de configuration principales et les mappages d'URL de requête se trouvent dans solr.xml, tandis que le mappage du gestionnaire de requête Solr et les paramètres Solr se trouvent dans le fichier solrconfig.xml. Ces configurations sont spécifiques à Solr et ne sont pas nécessaires pour la solution de recherche basée sur Elasticsearch. Ces configurations ne sont pas nécessaires dans la solution de recherche basée sur Elasticsearch.
Configurations de recherche dans STORECONF Certaines propriétés de recherche, telles que le mode de prix et l'autorisation, sont configurées en tant qu'entrée dans le tableau de base de données STORECONF. Les propriétés existantes configurées dans STORECONF sont toujours valides.

Certaines nouvelles propriétés sont également stockées dans STORECONF. Par exemple, une propriété qui sert à indiquer si un magasin est sans interface graphique ou non.

 Aucune migration n'est nécessaire.
Recherche de marchandisage et pertinence
Règles de recherche Les règles de recherche peuvent être définies dans l'outil Marketing dans Management Center for HCL Commerce. Les règles de recherche existantes sont toujours valides. Aucune migration n'est nécessaire.
Associations de termes recherchés Les associations de termes de recherche sont définies dans l'outil Catalogues dans Management Center for HCL Commerce. Les associations de termes de recherche existantes sont toujours valides. Aucune migration n'est nécessaire.
Réglage de la pertinence La pertinence de la recherche peut être réglée dans Management Center for HCL Commerce avec la combinaison de règles de recherche, d'association de termes de recherche et d'autres fonctions de réglage de la recherche. La pertinence de la recherche peut être réglé avec la fonction de traitement du langage naturel (NLP). La pertinence de la recherche dans la solution de recherche basée sur Elasticsearch fournit des améliorations significatives en termes de classement et de correspondance de recherche avec l'inclusion du traitement du langage naturel (NLP) et de l'étiquetage morpho-syntaxique. De nouveaux filtres NLP ont été ajoutés pour fournir des opportunités étendues d'améliorer l'expérience de recherche.
Image du produit Hero La fonctionnalité d'image de produit Hero renvoie l'article le plus représentatif pour une recherche de produit. La fonctionnalité d'image de produit Hero renvoie l'article le plus représentatif pour une recherche de produit. Aucune migration n'est nécessaire.
Déploiement
Mise en cache de la recherche La mise en cache de la recherche utilise un cache d'objets de données à l'aide de Dynacache avec Kafka et ZooKeeper pour l'invalidation du cache. HCL Cache, avec Redis comme fournisseur de cache, fournit la mise en cache REST et d'objet de données qui offre l'invalidation du cache basée sur les événements à grosse granularité. L'invalidation du cache basée sur le temps (TTL) est proposée en tant que rétromigration. Les microservices client pour exposer des données personnalisées doivent être évalués pour les exigences de mise en cache et d'invalidation.

Les événements Kafka personnalisés (bus d'événements) doivent être migrés vers Redis.
Magasin local Un magasin local, c'est-à-dire un magasin s'exécutant sur le Transaction server, fonctionne avec la recherche basée sur Solr. Un magasin local basé sur REST peut fonctionner avec la plateforme de recherche basée sur Elasticsearch.

Un magasin local basé sur BOD ne fonctionne pas avec la solution de recherche basée sur Elasticsearch.

 Il est recommandé d'utiliser un magasin distant ou un magasin sans interface graphique pour travailler avec la solution de recherche basée sur Elasticsearch.
Fragmentation et évolutivité Mise à l'échelle d'index limitée.

Pas de fragmentation ou de mise à l'échelle de requête ou d'exécution.

 Microservices du service Ingest évolutifs.

Le service Query fournit une évolutivité dynamique d'exécution et des services de recherche distribués à l'aide de la création de clusters Elasticsearch.

 Aucune migration n'est nécessaire.

Il existe plusieurs scénarios de migration vers la solution HCL Commerce Search modernisée dans la version 9.1. Ils sont présentés ci-dessous.

Procedure

  • Scénario A : (ancienne recherche + ancien magasin local)

    Lorsque les clients existants migrent depuis V7 ou V8 vers v9.1, ils seront migrés vers V9.1 avec l'ancien magasin aurora de recherche + local.

  • Scénario B : (ancienne recherche + ancien magasin local)

    Lorsqu'un client v9.0 existant effectue une mise à jour vers v9.1, si ce client utilise un magasin aurora local (migré à partir de v7 ou v8), il sera migré vers V9.1 avec l'ancien magasin aurore de recherche + locale.

  • Scénario C : (ancienne recherche + ancien magasin distant)

    Lorsqu'un client v9.0 existant effectue une mise à jour vers v9.1, si ce client utilise le magasin aurora distant, il sera migré vers v9.1 avec le magasin aurora recherche solr + distant vers v9.1. Nouvelle phase d'implémentation x

    Une fois que les clients ont migré vers v9.1 avec la recherche solr et le magasin aurora (local ou distant), nous leur recommandons d'implémenter à nouveau la personnalisation et le magasin de recherche avec une recherche basée sur ES et un magasin React pour consommer les dernières technologies et fonctions fournies par v9.1. Si, pour une raison quelconque ils ne peuvent pas passer à ES + magasin React immédiatement en une seule fois, les options suivantes s'offrent à eux :

    • Continuez à utiliser la recherche solr, et implémentez le magasin aurore distant, s'ils disposent du magasin aurora local (ancienne recherche + ancien magasin)
    • Une fois que vous utilisez le magasin distant, implémentez la recherche basée sur ES (nouvelle recherche + ancien magasin distant)
    • Implémentez éventuellement le magasin React avec la recherche basée sur ES (nouvelle recherche + nouveau magasin)
    • Pendant la transition, il se peut que certains magasins soient encore basés sur aurora. Ils pourraient avoir à la fois le magasin aurora et le magasin React déployé à ce moment-là (nouvelle recherche + nouveau magasin + ancien magasin)
  • Nouveau client sur v9.1

    Utilisez la recherche ES et les magasins React (nouvelle recherche + nouveau magasin).