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 les configurations avec FileDataStore et SegmentNodeStore.

Cas d’utilisation 1 - Contrôle de cohérence de l’index usercase1indexconsistencycheck

Il s’agit d’un cas d’utilisation lié à la corruption d’index. Dans certains cas, il n’était pas possible de déterminer les index corrompus. Par conséquent, Adobe a fourni des outils qui :

La recherche d’index altérés 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 le fichier indexing-result/index-consistency-check-report.txt. Voir ci-dessous 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 système pour déterminer rapidement les index corrompus, puis les réindexer.

Cas d’utilisation 2 - Statistiques des index usecase2indexstatistics

Pour diagnostiquer certains cas concernant l’Adobe des performances des requêtes, une définition d’index existante était souvent requise, les statistiques relatives aux index issues de la configuration du client. Jusqu'à présent, ces informations ont été réparties 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

En outre, les mêmes détails sont fournis par le biais de la console web et feraient partie du fichier zip de vidage de configuration. Ils sont accessibles à 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 relatifs aux problèmes d’indexation ou de requête et de réduire le temps consacré à l’extraction de ces informations.

Cas d’utilisation 3 - Réindexation usecase3reindexing

En fonction des scénarios, une réindexation doit être effectuée dans certains cas. 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.

Certains points à noter concernant 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

Les avantages suivants sont proposés :

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 dans l’indexation exécutée par Oak nécessitent des étapes manuelles supplémentaires.

Cela impliquerait les éléments suivants :

Dans ce scénario, il n’est pas nécessaire 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, elle 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 à l’aide de 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 sont effectués automatiquement. L'inconvénient, c'est que AEM doit être en panne pendant le processus.

Réindexation hors bande - SegmentNodeStore outofbandreindexsegmentnodestore

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

Dans ce scénario d’utilisation, on part du principe que l’entrepôt 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 via le 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 pour les installations plus petites où la réindexation ne prend pas beaucoup de temps. Toutefois, pour les référentiels très volumineux, la réindexation sera effectuée dans un laps de temps considérablement plus long. Dans ce cas, nous pouvons désormais utiliser l’outil d’index 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 en direct.

Le processus à prendre en compte pour ce cas pratique est le suivant :