Indexation du fichier Oak-run.jar – Scénarios d’utilisation oak-run-jar-indexing-use-cases

Oak-run prend en charge tous les scénarios d’indexation sur la ligne de commande, sans qu’il faille orchestrer l’exécution de ces scénarios par le biais de la console JMX d’AEM.

Les principaux avantages liés à l’utilisation de la commande d’index oak-run.jar pour la gestion des index Oak sont les suivants :

Les sections ci-dessous fournissent des exemples de commandes. La commande d’index Oak-run prend en charge toutes les configurations NodeStore et BlobStore. Les exemples fournis ci-dessous concernent des configurations comportant FileDataStore et SegmentNodeStore.

Cas d’utilisation 1 – Vérification de cohérence d’index usercase1indexconsistencycheck

Il s’agit d’un cas d’utilisation lié à la corruption d’index. Parfois, il n’était pas possible de déterminer lesquels des index étaient corrompus. Par conséquent, Adobe a fourni des outils offrant les fonctionnalités suivantes :

La recherche d’index corrompus peut être effectuée au moyen de l’opération --index-consistency-check :

java -jar oak-run*.jar index --fds-path=/path/to/datastore  /path/to/segmentstore/ --index-consistency-check

Cette opération génère un rapport dans indexing-result/index-consistency-check-report.txt. Voir ci-dessous pour un exemple de rapport :

Valid indexes :
        - /content/oak:index/enablementResourceName
        - /oak:index/cqProjectLucene
        - /oak:index/cqTagLucene
        - /oak:index/lucene
        - /oak:index/ntBaseLucene
        - /oak:index/socialLucene
    Invalid indexes :
        - /oak:index/atDamIndex
        - /oak:index/atIndex
        - /oak:index/cqPageLucene
        - /oak:index/damAssetLucene
        - /oak:index/groups
        - /oak:index/slingeventJob
        - /oak:index/users
        - /oak:index/workflowDataLucene
    Ignored indexes as these are not of type lucene:
        - /oak:index/acPrincipalName
        - /oak:index/active

Avantages uc1benefits

Cet outil peut désormais être utilisé par l’assistance et l’administrateur ou l’administratrice système pour déterminer rapidement quels index sont corrompus, puis les réindexer.

Cas d’utilisation 2 – Statistiques d’index usecase2indexstatistics

Pour diagnostiquer certains cas liés aux performances des requêtes, Adobe avait souvent besoin d’une définition d’index existante et de statistiques liées à l’index provenant de la configuration du client ou de la cliente. Jusqu’à présent, ces informations étaient dispersées sur plusieurs ressources. Pour faciliter le dépannage, Adobe a créé des outils qui :

Les opérations ci-dessus peuvent désormais être effectuées par le biais des commandes d’index d’opération suivantes :

Vous trouverez, ci-dessous, un exemple d’utilisation pratique des commandes :

java -jar oak-run*.jar index --fds-path=/path/to/datastore  /path/to/segmentstore/ --index-info --index-definitions --index-dump

Les rapports sont générés dans indexing-result/index-info.txt et dans indexing-result/index-definitions.json

De plus, les mêmes détails sont fournis via la console web et font partie du fichier zip de configuration. Ils se trouvent à l’emplacement suivant :

https://serverhost:serverport/system/console/status-oak-index-defn

Avantages uc2benefits

Cet outil permet de collecter rapidement tous les détails requis liés aux problèmes d’indexation ou de requête et de réduire le temps passé à extraire ces informations.

Cas d’utilisation 3 – Réindexation usecase3reindexing

En fonction des scénarios, une réindexation doit être parfois effectuée. Actuellement, la réindexation s’effectue en définissant l’indicateur reindex sur true dans le nœud de définition d’index via CRXDE ou via l’interface utilisateur du Gestionnaire d’index. Une fois l’indicateur défini, la réindexation est effectuée de manière asynchrone.

Voici quelques points à noter autour de la réindexation :

Pour atteindre ces objectifs, l’outil d’index oak-run prend en charge différents modes de réindexation qui peuvent être utilisés selon les besoins. La commande d’index oak-run offre les avantages suivants :

Réindexation – DocumentNodeStore reindexdocumentnodestore

Pour les installations DocumentNodeStore, la réindexation peut être effectuée au moyen d’une seule commande oak-run :

java -jar oak-run*.jar index --reindex --index-paths=/oak:index/lucene --read-write --fds-path=/path/to/datastore mongodb://server:port/aem

Cela offre les avantages suivants :

Réindexation – SegmentNodeStore reindexsegmentnodestore

Pour les installations SegmentNodeStore, la réindexation peut être effectuée de l’une des façons suivantes :

Réindexation en ligne – SegmentNodeStore onlinereindexsegmentnodestore

Suivez la méthode habituelle où la réindexation est effectuée en définissant l’indicateur reindex.

Réindexation en ligne – SegmentNodeStore – L’instance AEM est en cours d’exécution. onlinereindexsegmentnodestoretheaeminstanceisrunning

Dans le cas des installations SegmentNodeStore, un seul processus peut accéder à des fichiers de segment en mode lecture/écriture. Pour cette raison, certaines opérations d’indexation oak-run nécessitent des étapes manuelles supplémentaires.

Cela impliquerait les opérations suivantes :

Dans ce scénario, vous n’avez pas besoin d’arrêter le serveur AEM ni de configurer une nouvelle instance. Cependant, comme l’indexation implique la traversée de l’ensemble du référentiel, cela augmenterait la charge d’E/S sur l’installation, ce qui aurait un impact négatif sur les performances d’exécution.

Réindexation en ligne – SegmentNodeStore – L’instance AEM est arrêtée onlinereindexsegmentnodestoreaeminstanceisdown

Pour les installations SegmentNodeStore, la réindexation peut être effectuée au moyen d’une seule commande oak-run. Toutefois, l’instance AEM doit être arrêtée.

Vous pouvez déclencher la réindexation avec la commande suivante :

java -jar oak-run*.jar index --reindex --index-paths=/oak:index/lucene --read-write --fds-path=/path/to/datastore  /path/to/segmentstore/

La différence entre cette approche et celle expliquée ci-dessus est que la création de points de contrôle et l'importation d’index s’effectuent automatiquement. L’inconvénient est qu’AEM doit être arrêté pendant le processus.

Réindexation hors bande – SegmentNodeStore outofbandreindexsegmentnodestore

Dans ce cas d’utilisation, vous pouvez effectuer une réindexation sur une configuration clonée pour minimiser l’impact sur l’instance AEM en cours d’exécution :

Dans ce scénario d’utilisation, on part du principe que le magasin de données est accessible sur une autre instance, ce qui peut s’avérer impossible si FileDataStore est placé sur une solution de stockage cloud telle qu’EBS. Cela exclut le scénario dans lequel FileDataStore est également cloné. Si la définition d’index n’effectue pas d’indexation du texte intégral, il n’est pas nécessaire d’accéder à DataStore.

Cas d’utilisation 4 – Mise à jour des définitions d’index usecase4updatingindexdefinitions

Actuellement, vous pouvez envoyer des modifications de définition d’index via le package ACS Ensure Index. Cela permet d’envoyer les définitions d’index au moyen du package de contenu, ce qui exigera, par la suite, que la réindexation soit effectuée en définissant l’indicateur reindex sur true.

Cela fonctionne bien sur des petites installations pour lesquelles la réindexation prend peu de temps. . Cependant, pour les référentiels volumineux, la réindexation est effectuée dans un délai considérablement plus long. Pour de tels cas, nous pouvons désormais utiliser l’outil d’indexation oak-run.

Oak-run prend désormais en charge la fourniture de définitions d’index au format JSON et la création d’index en mode hors bande où aucune modification n’est effectuée sur une instance active.

Le processus à prendre en compte pour ce cas d’utilisation est le suivant :