Comparaison des cycles de vie d'index de Solr et Elasticsearch

Apache Solr et Elasticsearch ont des approches différentes pour mettre à jour votre index de recherche. Solr fait des mises à jour delta sur un horaire régulier, généralement toutes les cinq minutes. Elasticsearch effectue une mise à jour incrémentielle en temps quasi réel.

Une fois l'index de recherche complet généré, vous pouvez le mettre à jour rapidement au besoin. Les deux architectures de recherche disponibles dans HCL Commerce version 9.1 adoptent des approches légèrement différentes pour faire cette mise à jour. Apache Solr et Eslastsearch sont tous deux intégrés dans le système HCL Commerce plus large. Ainsi, ils partagent certains composants, principalement dans l'interface de la mise à jour du catalogue et de l'accès à la base de données. Leur différence réside dans la manière dont les nouveaux éléments sont ajoutés à l'index de travail. Elasticsearch lit également depuis CACHEIVL, mais transmet ensuite les données au service Ingest, où il permet un aperçu en temps quasi réel des mises à jour dans le Management Center.

Mises à jour delta à l'aide d'Apache Solr

Lorsque vous utilisez Apache Solr en tant que moteur de recherche, toutes les mises à jour de données métier effectuées dans Management Center d'abord écrites dans la base de données. La séquence est la suivante:

Un utilisateur professionnel travaillant dans l'environnement création de catalogue effectue des mises à jour de catalogue dans le Management Center. Ces modifications mettent à jour les bases de données.
La mise à jour de base de données déclenche une requête d'invalidation d'index, qui est insérée dans la table de base de données CACHEIVL.
Au cours de l'opération d'indexation suivante, généralement exécutée sur un cycle de cinq minutes, les tables TI_DELTA_CATENTRY et TI_DELTA_CATGROUP sont lues et l'index mis à jour en conséquence.
Note: La réindexation se produit également lorsqu'un utilisateur déclenche un aperçu de vitrine dans le Management Center. Il peut y avoir un délai avant que cela ne soit visible dans l'aperçu.
Pendant la mise à jour de l'index, CACHEIVL peut recevoir de nouvelles demandes d'invalidation, qui seront incorporées dans l'opération d'indexation planifiée suivante.

Push-to-live dans Solr

Lorsque la propagation de transfert démarre, l'opération de publication sur le serveur Création de transactions reproduit toutes les modifications prêtes pour la production entre la base de données Création et la base de données Actif. Cela déclenche une requête d'invalidation de cache, qui est insérée dans la table CACHEIVL de la base de données Actif.

Une fois la propagation de transfert terminée, le répéteur de recherche démarre l'opération IndexProp qui extrait la dernière version de tous les index de recherche depuis le maître de recherche vers le répéteur de recherche. Une minute plus tard, cette version est extraite par chaque subordonné de recherche en cours d'exécution dans l'environnement de production.

Une fois la réplication d'index terminée, une requête de redémarrage d'invalidation de cache est insérée dans la table CACHEIVL de la base de données Actif. Cette base de données exécute à nouveau toutes les requêtes d'invalidation du cache à partir d'un horodatage donné à l'aide de la commande IndexProp.

Mises à jour d'urgence dans Solr

Une fois qu'une mise à jour d'urgence a été approuvée dans l'environnement Solr, l'opération de validation planifiée sur le serveur Création de transactions enverra les mises à jour dans les bases de données Création et Actif. Cela déclenche le cache d'une invalidation pour les tables CACHEIVL des bases de données Création et Actif. Toutes les cinq minutes, un travail d'indexation du planificateur sur le serveur de transactions sur un environnement de production vérifie si une opération d'indexation est requise au niveau du répéteur de recherche. Alors que l'opération d'indexation est en cours d'exécution, des requêtes d'invalidation du cache plus précises sont insérées dans la table CACHEIVL de la base de données Actif. Toute mise à jour d'urgence de l'index au niveau du répéteur de recherche sera ensuite répliquée à chaque esclave de recherche chaque minute

Mises à jour incrémentielles à l'aide d'Elasticsearch

Bien que l'indexation complète soit possible dans Elasticsearch (et doit être effectuée initialement), l'approche recommandée consiste à effectuer des mises à jour incrémentielles. Si le delta est suffisamment petit, la quantité d'invalidation dans une mise à jour incrémentielle sera relativement faible par rapport à une invalidation et une réindexation complètes. Cela ne signifie pas que vous ne pouvez pas faire de réindexation complète, vous n'avez simplement pas besoin de le faire aussi souvent que vous le feriez avec Solr. En effet, Solr n'a pas d'invalidation pilotée par les événements et possède une invalidation beaucoup plus grossière, qui nécessite une réindexation plus fréquente. Elasticsearch a une invalidation beaucoup plus détaillée et peut être pilotée par des événements, dont vous pouvez pleinement tirer parti.

Le processus Elasticsearch démarre de la même manière que la réindexation Solr, mais diffère considérablement à la fois dans la façon dont l'index est mis à jour et dans la façon dont la mise à jour se propage dans vos centres de données.

Un utilisateur professionnel travaillant dans l'environnement Création met à jour le catalogue dans Management Center.
La mise à jour déclenche une requête d'invalidation qui est envoyée à la table de base de données CACHEIVL.
Ces données sont propagées via le bus Redis jusqu'au service Ingest, lequel utilise des canaux Apache NiFi pour analyser les données et mettre à jour l'index Elasticsearch.
L'utilisateur peut appeler le service Query pour afficher ces mises à jour dans l'environnement Création de façon efficace en temps réel. Pour plus d'informations, voir API REST de Query.
Ces changements professionnels progressifs effectués à partir de Management Center sont représentés comme des événements Redis et renvoyés au service Ingest. Ici, ils peuvent être analysés et traités plus en détail.
Une fois l'index mis à jour, tous les événements d'invalidation du cache associés sont envoyés au bus Redis, où ils sont alors répliqués à l'échelle de l'ensemble des clusters ou centres de données que vous utilisez.

Push-to-live via Elasticsearch

Lorsque la propagation de transfert démarre, le serveur Création de transactions reproduit toutes les modifications prêtes pour la production entre la base de données Création et la base de données Actif. Il émet également une requête de propagation de transfert au service Ingest pour le déclenchement d'une réplication des mises à jour approuvées depuis l'index Création vers l'index Actif.

L'objet de données et les caches REST utilisés dans le service Query d'instance active sont également invalidés. Le cas échéant, les caches JSP utilisés par le serveur de magasin dans l'instance active seront également invalidés.

Ce processus push-to-live ne nécessite pas de réplication pour subordonner les nœuds, comme avec Solr. Au lieu de cela, une copie du nouvel index actif est créée dans l'environnement de production et est échangée une fois que le nouvel index est prêt. L'ancienne version est immédiatement mise hors service.

Restriction: Si les modifications apportées aux données de catalogue ne sont pas disponibles dans vos magasins actifs après une opération push-to-live, déclenchez une opération d'invalidation WCT+ESINDEX lorsque vous faites la mise à jour. Pour plus d'informations sur les caches à mettre à jour et la procédure, voir Les modifications d'index ne sont pas reflétées dans la vitrine après le processus push-to-live Elasticsearch.

Mises à jour coordonnées

Vous pouvez regénérer l'ensemble de l'index de recherche sous la forme d'un nouvel index séparé afin de minimiser l'impact professionnel de la durée de la mise à jour. Une fois que le nouvel index est entièrement regénéré, immédiatement après l'émission de l'événement Indexation terminée, l'index actif actuel peut être échangé avec le nouvel index créé. Cela se fait simplement en remplaçant l'alias d'index actuel.

Si vous chargez une grande quantité de données dans un connecteur Ingest, il peut éventuellement les insérer dans une copie distincte de l'index cible. Cela ressemble à une regénération complète de l'index, mais les nouvelles données sont chargées au-dessus d'une copie de l'index cible.

La stratégie de reprise après sinistre d'Elasticsearch consiste à créer régulièrement des instantanés de l'index ES local. Cela permet de récupérer rapidement l'index depuis l'instantané incrémentiel le plus récent. Une fois l'index entièrement restauré, l'index actif actuel peut être échangé avec lui, et un événement Indexation terminée est déclenché.