Cycle de vie de l'index Elasticsearch

Structure d'un index multidimensionnel

Dans l'implémentation de HCL Commerce version 9.1 d'Elasticsearch, des schémas d'index sont fournis pour chaque schéma d'index de produit. Chaque schéma est ensuite subdivisé en plusieurs classifications. Par exemple, le schéma des produits est divisé par autorisation, prix, stock, navigation, attributs et propriétés. Chaque classification peut être indexée en plusieurs types de zones en fonction d'utilisations telles que l'affichage, la recherche, le filtrage, la création de facettes, la stimulation ou le tri. Pour examiner le schéma pour cet exemple, voir Pipeline d'index Produit Ingest.

Le service Ingest crée un document indexé distinct pour chaque langue prise en charge, pour chaque catalogue pris en charge et pour chaque magasin. Cela peut être important si vous vous attendez à ce que le résultat soit un index très volumineux et que la taille soit importante au départ lors de la configuration de l'index. Toutefois, la capacité d'Elasticsearch à faire des mises à jour incrémentielles modifie l'équation une fois l'index configuré. Si les modifications au jour le jour ne sont pas importantes, vous ne trouverez pas que les performances seront particulièrement affectées, comme c'est le cas si vous deviez faire une réindexation complète régulière. En outre, l'utilisation d'e-sites améliore également les performances. Chaque e-site dispose de son propre index, car chaque magasin peut avoir son propre cycle de vie des données. En option, si les e-sites partagent le cycle de vie des données et le catalogue, vous pouvez utiliser l'approche du catalogue principal avec les magasins.

Tout document indexé peut être utilisé dans plusieurs contextes, tels que approuvé (dépublié) et actif (publié). Ils peuvent avoir des valeurs en cours, mises à jour ou écrasées, chacune étant exprimée sous la forme d'un nouveau nom de zone d'index avec le préfixe approprié. Notez que les nouveaux documents (ou à supprimer) sont étiquetés comme nouveaux (ou supprimés) pour éviter d'être inclus dans l'index Actif.

Requêtes Push-To-Live

Lorsque la propagation de transfert démarre, l'opération de publication sur le Transaction server de création va pousser ou reproduire toutes les modifications prêtes pour la production de la base de données de création vers la base de données opérationnelle.

Cette approche Push-To-Live (PTL) n'a plus besoin d'une réplication vers les nœuds subordonnés. Au lieu de cela, une copie du nouvel index actif sera créée dans l'environnement Actif et est échangée une fois que le nouvel index est prêt. L'ancienne version sera immédiatement mise hors service.

Les caches d'objets de données et la mise en cache REST utilisés dans le service Query d'environnement actif sont invalidés.

Configuration d'index initiale

Pour effectuer une configuration d'index initiale, effectuez une opération de réindexation complète des indices de recherche pour le magasin spécifique. Le processus d'indexation commence par la création du schéma, de la base de données de produits et de STA. Les données sont chargées en explorant progressivement le catalogue, puis la catégorie. Ensuite, la boucle de flux principale prend le relais, en traitant les attributs, les produits, les URL de référencement et, enfin, à partir de cette boucle, le prix

Lors des opérations de réindexation complètes suivantes, le nouvel index est généré en parallèle avec l'index existant. Une fois le nouvel index prêt, l'alias de l'index est simplement mis à jour avec l'emplacement du nouvel index. A ce stade, le nouvel index devient l'index actif. Il existe également une cadence régulière des mises à jour de stock, par exemple, qui peut être programmée en tant que travaux réguliers. Ces mises à jour peuvent être réalisées via une "copie intelligente" dans l'index et le prix. La copie intelligente ne copie pas chaque mise à jour, car plusieurs n'auront pas changé entre les exécutions. La copie de l'intégralité déclencherait l'équivalent d'une invalidation complète.

Au cours de ce processus et par la suite, le traitement du langage naturel (NLP) est effectué et les relations de matchmaker telles que la mise en correspondance des couleurs sont construites. Ces éléments ne s'appuient pas sur l'index en cours de finalisation, mais complétera son contenu une fois qu'ils seront terminés. L'utilisation du NLP est coûteuse, mais certaines fonctions du jeu de données NLP, telles que la lemmatisation, changent rarement. La première exécution du NLP est un peu plus longue, car elle effectue une lemmatisation complète et écrit dans l'index.

Mises à jour en temps quasi réel (NRT) dans l'environnement de création

Toutes les mises à jour de données métier dans le Centre de gestion sont d'abord écrites dans la base de données. Ceci est suivi d'un événement de mise à jour incrémentielle (avec le contexte de création) effectué via Redis. Une logique métier intégrée au pipeline d'indexation Apache NiFi est utilisée pour analyser et traiter ces demandes de changement.

Agissant en tant que bus de messages, Redis diffuse cette demande de changement à tous les connecteurs NiFi qui surveillent ce type d'opération. Le résultat est la mise à jour incrémentielle des index de recherche appropriés. Le cache d'objet de données et la mise en cache REST utilisés dans le service de requête pour l'environnement de création sont invalidés.

Cette approche peut proposer une expérience de mise à jour en quasi-temps réel via le service Query, lors de la prévisualisation de la vitrine dans l'environnement de création.

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

Chargement de données avec la recherche basée sur Elasticsearch

L'pour l'utilitaire de chargement de données est un outil qui charge les données d'un fichier source vers une base de données cible. Il peut également supprimer des données d'une base de données. Dataload prend en charge les mises à jour incrémentielles des données du catalogue si le moteur de recherche Elasticsearch est activé.

Sauvegardes d'index

Lorsque vous générez un index, par défaut, les copies de sauvegarde des deux générations précédentes sont conservées. Ce paramètre n'affecte pas les performances, bien que, dans certaines circonstances, vous puissiez constater des incohérences apparentes dans vos journaux. Par exemple, si vous exécutez plusieurs régénérations d'index Store 1, Store 11 ou eSite dans une succession rapide, vous ne verrez qu'un seul index avec l'horodatage le plus récent. Etant donné que les sauvegardes sont conservées, dans ce cas, vous pouvez observer deux index présents qui ont le même horodatage. Cela indique simplement que des sauvegardes sont en cours de création et que la sauvegarde la plus récente a reçu le même horodatage que l'index opérationnel actuel.

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

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