Avec la transition vers Oak dans AEM 6, certains changements majeurs ont été apportés à la façon dont les requêtes et les index sont gérés. Sous Jackrabbit 2, tout le contenu était indexé par défaut et pouvait être interrogé librement. Dans Oak, les index doivent être créés manuellement sous le nœud oak:index
. Une requête peut être exécutée sans index, mais pour les jeux de données volumineux, elle l’est très lentement et risque même d’être abandonnée.
Cet article contient les informations suivantes : quand créer des index et dans quels cas ils ne sont pas nécessaires ; des astuces pour ne pas utiliser de requêtes lorsqu’elles ne sont pas indispensables ; des conseils pour optimiser les index et les requêtes.
De plus, assurez-vous de lire la documentation Oak sur l’écriture de requêtes et d’index. En plus du nouveau concept d’index dans AEM 6, il existe des différences syntaxiques dans les requêtes Oak qui doivent être prises en compte lors de la migration du code à partir d’une installation AEM précédente.
Lors de la conception de la taxonomie d’un référentiel, plusieurs facteurs doivent être pris en compte. Il s’agit notamment des contrôles d’accès, de la localisation, de l’héritage des composants et des propriétés de page.
Lors de la conception d’une taxonomie qui tient compte de ces facteurs, il est également important de penser à la « traversabilité » de la conception de l’indexation. Dans ce contexte, la traversabilité est la capacité d’une taxonomie qui permet un accès prévisible au contenu en fonction de son chemin. Cela permet d’obtenir un système plus performant, plus facile à gérer qu’un système nécessitant de nombreuses requêtes à exécuter.
De plus, lors de la conception d’une taxonomie, il faut considérer si l’ordre importe. Dans les cas où un ordre explicite n’est pas nécessaire et qu’un grand nombre de nœuds frères est attendu, il est préférable d’utiliser un type de nœud non ordonné tel que sling:Folder
ou oak:Unstructured
. Dans les cas où un ordre est obligatoire, nt:unstructured
et sling:OrderedFolder
serait plus approprié.
Comme les requêtes peuvent être l’une des opérations les plus taxatrices effectuées sur un système AEM, il est préférable de les éviter dans vos composants. L’exécution de plusieurs requêtes à chaque rendu d’une page peut souvent dégrader les performances du système. Deux stratégies sont conseillées pour éviter l’exécution de requêtes lors du rendu de composants : le parcours transversal des nœuds et la pré-récupération des résultats.
Si le référentiel est conçu de manière à permettre une connaissance préalable de l’emplacement des données requises, le code qui récupère ces données des chemins nécessaires peut être déployé sans avoir à exécuter de requêtes pour les trouver.
Par exemple, le rendu du contenu correspondant à une certaine catégorie. Une méthode consiste à organiser le contenu avec une propriété de catégorie qui peut être interrogée pour renseigner un composant qui affiche des éléments dans une catégorie.
Une meilleure approche serait de structurer ce contenu dans une taxonomie par catégorie afin qu’il puisse être récupéré manuellement.
Par exemple, si le contenu est stocké dans une taxonomie similaire à :
/content/myUnstructuredContent/parentCategory/childCategory/contentPiece
Le nœud /content/myUnstructuredContent/parentCategory/childCategory
peut simplement être récupéré ; ses tâches enfants peuvent être analysées et utilisées pour le rendu du composant.
En outre, lorsque vous traitez un jeu de résultats petit ou homogène, il peut être plus rapide de parcourir le référentiel et de rassembler les noeuds requis, plutôt que de concevoir une requête pour renvoyer le même jeu de résultats. En règle générale, les requêtes doivent être évitées lorsque cela est possible.
Parfois, le contenu ou les exigences autour du composant ne permettent pas l’utilisation de la traversée de noeuds comme méthode de récupération des données requises. Dans ce cas, les requêtes requises doivent être exécutées avant le rendu du composant afin que les performances optimales soient garanties pour l’utilisateur final.
Si les résultats requis pour le composant peuvent être calculés au moment de sa création et qu’il n’y a aucune espérance de modification du contenu, la requête peut être exécutée lorsque l’auteur applique les paramètres dans la boîte de dialogue.
Si les données ou le contenu changent régulièrement, la requête peut être exécutée selon un planning ou via un écouteur pour la mise à jour des données sous-jacentes. Ensuite, les résultats peuvent être écrits à un emplacement partagé dans le référentiel. Tous les composants qui ont besoin de ces données peuvent ensuite extraire les valeurs de ce nœud unique sans avoir à exécuter une requête lors de l’exécution.
Lors de l’exécution d’une requête qui n’utilise pas d’index, des avertissements sont consignés concernant la traversée de noeuds. S’il s’agit d’une requête qui va être exécutée fréquemment, un index doit être créé. Pour déterminer l’index qu’utilise une requête donnée, l’outil Expliquer la requête est recommandé. Pour plus d’informations, la journalisation DEBUG peut être activée pour les API de recherche pertinentes.
Après avoir modifié une définition d’index, l’index doit être reconstruit (réindexé). Selon la taille de l’index, cette opération peut prendre un certain temps.
Lors de l’exécution de requêtes complexes, la ventilation de la requête en plusieurs requêtes plus petites et la jonction des données par du code après coup est plus performante, dans certains cas. Dans ce cas, il est recommandé de comparer les performances des deux approches afin de déterminer quelle option serait la meilleure pour le cas d’utilisation en question.
AEM permet d’écrire des requêtes de trois façons :
Bien que toutes les requêtes soient converties en SQL2 avant d’être exécutées, la surcharge liée à la conversion des requêtes est minime et, par conséquent, la plus grande préoccupation lors du choix d’un langage de requête sera la lisibilité et le niveau de confort de l’équipe de développement.
Si QueryBuilder est utilisé, il détermine le nombre de résultats par défaut, opération qui est plus lente dans Oak par rapport aux versions précédentes de Jackrabbit. Pour compenser cela, vous pouvez utiliser la variable paramètre guessTotal.
Comme pour tout langage de requête, la première étape pour optimiser une requête consiste à comprendre comment elle sera exécutée. Pour effectuer cette activité, vous pouvez utiliser l’outil Expliquer la requête qui fait partie du tableau de bord des opérations. Grâce à cet outil, une requête peut être expliquée. Un avertissement s’affiche si la requête entraîne des problèmes avec un référentiel volumineux, ainsi que le temps d’exécution et les index qui seront utilisés. L’outil peut également charger une liste de requêtes lentes et populaires qui peuvent ensuite être expliquées et optimisées.
Pour obtenir des informations supplémentaires sur la manière dont Oak choisit l’index à utiliser et sur la manière dont le moteur de requête exécute réellement une requête, une DEBUG la configuration de journalisation peut être ajoutée pour les packages suivants :
Assurez-vous de supprimer cet enregistreur lorsque vous avez terminé le débogage de votre requête, car il génère beaucoup d’activité et peut éventuellement remplir votre disque avec des fichiers journaux.
Pour plus d’informations sur la procédure à suivre, voir Documentation de journalisation.
Lucene enregistre un bean JMX qui fournit des détails sur le contenu indexé, y compris la taille et le nombre de documents présents dans chacun des index.
Vous pouvez le consulter en accédant à la console JMX à l’adresse https://server:port/system/console/jmx
.
Une fois connecté à la console JMX, recherchez Statistiques de l’index Lucene pour le trouver. D’autres statistiques d’index sont disponibles dans la variable IndexStats MBean.
Pour les statistiques de requête, consultez le MBean nommé Statistiques de requête Oak.
Si vous souhaitez explorer vos index à l’aide d’un outil comme Luke, vous devez utiliser la console Oak pour vider l’index de la NodeStore
à un répertoire de système de fichiers. Pour obtenir des instructions sur la façon de procéder, veuillez lire le Documentation Lucene.
Vous pouvez également extraire les index de votre système au format JSON. Pour ce faire, accédez à https://server:port/oak:index.tidy.-1.json
.
Pendant le développement
Définir des seuils bas pour oak.queryLimitInMemory
(p. ex. 10000) et oak. queryLimitReads
(par ex. 5000) et optimisez les requêtes coûteuses lorsque vous obtenez une exception UnsupportedOperationException indiquant : « la requête lit plus de x nœuds… » ("The query read more than x nodes…").
Cela permet d’éviter les requêtes gourmandes en ressources (c’est-à-dire n’est soutenu par aucun index ou soutenu par un index moins couvrant). Par exemple, une requête qui lit 1 million de nœuds entraînerait une augmentation des E/S et aurait un impact négatif sur les performances globales de l’application. Toute requête qui échoue en raison des limites ci-dessus doit être analysée et optimisée.
Surveillez les journaux à la recherche de requêtes déclenchant une traversée de nœuds importante ou une consommation élevée de mémoire de tas : ``
*WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.
Surveillez les journaux à la recherche de requêtes déclenchant une consommation importante de mémoire de tas :
*WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped
Pour les versions AEM 6.0 à 6.2, vous pouvez ajuster le seuil du parcours transversal des nœuds à l’aide des paramètres JVM du script de démarrage AEM pour éviter que les requêtes volumineuses ne surchargent l’environnement.
Les valeurs recommandées sont les suivantes :
-Doak.queryLimitInMemory=500000
-Doak.queryLimitReads=100000
Dans AEM 6.3, les 2 paramètres ci-dessus sont préconfigurés OOTB et peuvent être conservés dans les paramètres OSGi QueryEngineSettings.
Plus d’informations disponibles sous : https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limits
La première question à poser lors de la création ou de l’optimisation des index est de savoir s’ils sont réellement nécessaires pour une situation donnée. Si vous n’exécutez la requête en question qu’une seule fois ou seulement occasionnellement et à une heure creuse pour le système par le biais d’un traitement par lots, il peut être préférable de ne pas créer d’index du tout.
Une fois un index créé, chaque fois que les données indexées sont mises à jour, l’index doit également l’être. Étant donné que cela se répercute sur les performances du système, les index ne doivent être créés que s’ils sont indispensables.
En outre, les index ne sont utiles que si les données contenues dans l’index sont suffisamment uniques pour le justifier. Examinez un index dans un livre et les sujets qu’il aborde. Lors de l’indexation d’un ensemble de rubriques dans un texte, il y a généralement des centaines ou des milliers d’entrées, ce qui vous permet d’accéder rapidement à un sous-ensemble de pages pour trouver rapidement les informations que vous recherchez. Si cet index ne comportait que deux ou trois entrées, chacune indiquant plusieurs centaines de pages, l’index ne serait pas très utile. Ce même concept s’applique aux index de base de données. S’il n’y a que quelques valeurs uniques, l’index est inutile. Cela étant, s’il est trop volumineux, l’index risque également d’être inutile. Pour consulter les statistiques d’index, voir Statistiques d’index ci-dessus.
Les index Lucene ont été introduits dans Oak 1.0.9 et offrent de puissantes optimisations par rapport aux index de propriété introduits lors du lancement initial d’AEM 6. Lorsque vous décidez d’utiliser des index Lucene ou des index de propriété, tenez compte des points suivants :
En règle générale, il est recommandé d’utiliser les index Lucene à moins qu’il ne soit absolument nécessaire d’utiliser les index de propriété afin de bénéficier de performances et de souplesse accrues.
AEM fournit également la prise en charge de l’indexation Solr par défaut. Elle sert principalement à prendre en charge la recherche de texte intégral, mais aussi tout type de requête JCR. Solr doit être pris en compte lorsque les instances d’AEM n’ont pas la capacité du processeur pour gérer le nombre de requêtes requises dans les déploiements intensifs en recherche, tels que les sites web pilotés par la recherche avec un grand nombre d’utilisateurs simultanés. Alternativement, Solr peut être implémenté dans une approche basée sur un robot de recherche pour tirer parti de certaines des fonctionnalités les plus avancées de la plateforme.
Les index Solr peuvent être configurés pour s’exécuter de manière intégrée sur le serveur AEM pour les environnements de développement ou peuvent être déchargés sur une instance distante afin d’améliorer l’évolutivité de la recherche dans les environnements de production et d’évaluation. Bien que le déchargement de la recherche améliore l’évolutivité, il introduit une latence et, pour cette raison, n’est pas recommandé sauf si nécessaire. Pour plus d’informations sur la configuration de l’intégration Solr et sur la création d’index Solr, voir Documentation sur les requêtes et l’indexation Oak.
En adoptant l’approche de recherche Solr intégrée, il est possible de décharger l’indexation sur un serveur Solr. Si les fonctionnalités plus avancées du serveur Solr sont utilisées selon une approche de robot d’exploration, un travail de configuration supplémentaire est nécessaire.
L’inconvénient de cette approche est que, bien que par défaut, AEM requêtes respectent les listes de contrôle d’accès et masquent ainsi les résultats auxquels un utilisateur n’a pas accès, l’externalisation de la recherche sur un serveur Solr ne prend pas en charge cette fonctionnalité. Si la recherche doit être externalisée de cette manière, une attention particulière doit être accordée à ce que les utilisateurs ne reçoivent pas de résultats qu’ils ne devraient pas voir.
Les cas d’utilisation potentiels où cette approche peut être appropriée sont les cas où les données de recherche provenant de plusieurs sources peuvent nécessiter un regroupement. Prenons l’exemple d’un site hébergé sur AEM et d’un second site hébergé sur une plateforme tierce. Solr peut être configuré pour analyser le contenu des deux sites et les stocker dans un index agrégé. Cela permet des recherches intersites.
La documentation Oak pour les index Lucene répertorie plusieurs points à prendre en compte lors de la conception des index :
Si la requête utilise des restrictions de chemin différentes, utilisez evaluatePathRestrictions
. Cela permet à la requête de renvoyer le sous-ensemble de résultats sous le chemin spécifié, puis de les filtrer selon la requête. Sinon, la requête recherchera tous les résultats correspondant aux paramètres de requête du référentiel, puis les filtrera en fonction du chemin d’accès.
Si la requête utilise le tri, définissez une propriété explicite pour la propriété triée et définissez ordered
sur true
. Cela permet d’ordonner les résultats en tant que tels dans l’index et d’économiser sur les opérations de tri coûteuses au moment de l’exécution de la requête.
Ne placez que ce qui est nécessaire dans l’index. L’ajout de fonctionnalités ou de propriétés inutiles entraîne la croissance de l’index et ralentit les performances.
Dans un index de propriété, un nom de propriété unique contribue à réduire la taille de l’index, mais dans le cas des index Lucene, l’utilisation de nodeTypes
et mixins
est conseillée pour obtenir des index cohérents. L’interrogation d’une propriété nodeType
ou mixin
spécifique est plus performante que celle d’une propriété nt:base
. Si vous suivez cette approche, définissez indexRules
pour les nodeTypes
en question.
Si vos requêtes sont exécutées uniquement sous certains chemins, créez ces index sous ces chemins. Les index ne sont pas nécessaires pour vivre à la racine du référentiel.
Il est recommandé d’utiliser un seul index lorsque toutes les propriétés indexées sont liées pour permettre à Lucene d’évaluer autant de restrictions de propriété que possible en mode natif. En outre, une requête n’utilise qu’un seul index, même lors de l’exécution d’une jointure.
Dans les cas où le NodeStore
est stocké à distance, une option appelée CopyOnRead
peut être activée. L’option entraîne l’écriture de l’index distant sur le système de fichiers local lors de sa lecture. Cela peut contribuer à améliorer les performances des requêtes qui sont souvent exécutées sur ces index distants.
Vous pouvez le configurer dans la console OSGi sous LuceneIndexProvider et est activé par défaut à partir de Oak 1.0.13.
Lors de la suppression d’un index, il est toujours recommandé de le désactiver temporairement en définissant la propriété type
sur disabled
et de vérifier que votre application fonctionne correctement avant de le supprimer. Notez qu’un index n’est pas mis à jour lorsqu’il est désactivé. Il se peut donc qu’il ne dispose pas du contenu correct s’il est réactivé et qu’il doit être réindexé.
Après la suppression d’un index de propriété sur une instance TarMK, le compactage doit être exécuté pour récupérer tout l’espace disque utilisé. Pour les index Lucene, le contenu réel de l’index réside dans le BlobStore, de sorte qu’un nettoyage de la mémoire d’entrepôt de données est nécessaire.
Lors de la suppression d’un index sur une instance MongoDB, le coût de suppression est proportionnel au nombre de noeuds dans l’index. La suppression d’un index volumineux pouvant entraîner des problèmes, l’approche recommandée consiste à désactiver l’index et à le supprimer uniquement pendant une fenêtre de maintenance, à l’aide d’un outil tel que oak-mongo.js. Notez que cette approche ne doit pas être utilisée pour le contenu de noeud normal, car elle peut introduire des incohérences de données.
Pour plus d’informations sur oak-mongo.js, consultez Outils de ligne de commande de la documentation Oak.
Pour prendre en charge la création de requêtes JCR et de définitions d’index efficaces, l’Aide-mémoire sur les requêtes JCR peut être téléchargé et utilisé comme référence pendant le développement. Il contient des exemples de requêtes pour QueryBuilder, XPath et SQL-2, couvrant plusieurs scénarios qui se comportent différemment en termes de performances des requêtes. Il fournit également des recommandations sur la création ou la personnalisation d’index Oak. Le contenu de cet aide-mémoire s’applique à AEM 6.5 et à AEM as a Cloud Service.
Cette section présente les seules raisons valables qui justifient une réindexation des index Oak.
En dehors des raisons exposées ci-dessous, la réindexation des index Oak ne change pas le comportement et ne résout aucun problème, mais augmente indiscutablement la charge sur AEM.
La réindexation des index Oak doit être évitée à moins d’être justifiée par l’une des raisons décrites dans les tableaux ci-dessous.
Avant de consulter les tableaux ci-dessous pour déterminer si une réindexation est utile, vérifiez toujours que :
Les seules conditions de non-erreur acceptables pour la réindexation des index Oak sont si la configuration d’un index Oak a changé.
La réindexation doit toujours être envisagée en tenant compte de son impact sur les performances globales d’AEM et être réalisée pendant les périodes de faible activité ou de maintenance.
Problèmes possibles et solutions :
S’applique pour/si :
Symptômes :
Comment vérifier :
jcr:created
ou jcr:lastModified
de tous les nœuds manquants par rapport à l’heure de modification de l’index.Mode de résolution :
Réindexez l’index Lucene
Vous pouvez également toucher (effectuer une opération d’écriture bénigne) aux noeuds manquants.
S’applique pour/si :
Symptômes :
Comment vérifier :
diffStoredIndexDefinition
.Mode de résolution :
Versions Oak antérieures à la version 1.6 :
Oak versions 1.6+
Si le contenu existant n’est pas affecté par les modifications, seule une actualisation est nécessaire.
Sinon, re-index l’index lucene
Le tableau suivant décrit les seules situations d’erreur et d’exception acceptables dans lesquelles la réindexation des index Oak résoudra le problème.
Si un problème survient sur AEM qui ne correspond pas aux critères décrits ci-dessous, not réindexez les index, car cela ne résoudra pas le problème.
Problèmes possibles et solutions :
S’applique pour/si :
Symptômes :
Comment vérifier :
Mode de résolution :
Effectuez une vérification du référentiel de traversée ; par exemple :
http://localhost:4502/system/console/repositorycheck
La traversée du référentiel détermine si d’autres fichiers binaires (à part les fichiers lucene) sont manquants.
Si des binaires autres que les index Lucene sont manquants, restaurez à partir de la sauvegarde.
Sinon, réindexez tous les index Lucene.
Remarque :
cette condition indique qu’un magasin de données est mal configuré, ce qui peut engendrer l’absence de TOUT type de binaire (par ex. des binaires de ressources).
Dans ce cas, restaurez la dernière version fonctionnelle connue du référentiel pour récupérer tous les binaires manquants.
S’applique pour/si :
Symptômes :
Comment vérifier :
La requête AsyncIndexUpdate
(toutes les 5 s) échoue avec une exception dans le fichier error.log :
...a Lucene index file is corrupt...
Mode de résolution :
Supprimer la copie locale de l’index Lucene
crx-quickstart/repository/index
.Si cela ne résout pas le problème et que les exceptions AsyncIndexUpdate
persistent, alors :
Dans AEM 6.5, la méthode oak-run.jar constitue la SEULE méthode prise en charge pour effectuer une réindexation sur des référentiels MongoMK ou RDBMK.
Utilisation oak-run.jar pour réindexer l’index de propriété
Définissez la propriété async-reindex sur true dans l’index de propriété
[oak:queryIndexDefinition]@reindex-async=true
Réindexez l’index de propriété de manière asynchrone à l’aide de la console web via le MBean PropertyIndexAsyncReindex ;
par exemple,
Utilisation oak-run.jar à réindexer Index de la propriété Lucene.
Définissez la propriété async-reindex sur true dans l’index de propriété lucene
[oak:queryIndexDefinition]@reindex-async=true
La section précédente résume et encadre les conseils de réindexation Oak à partir de la fonction Documentation Apache Oak dans le contexte de l’AEM.
La pré-extraction de texte est le processus d’extraction et de traitement de texte à partir de binaires, directement à partir de l’entrepôt de données par le biais d’un processus isolé, et d’exposition directe du texte extrait aux réindexations/réindexation ultérieures des index Oak.
/oak:index/damAssetLucene
.Réindexation d’un existant index Lucene avec extraction binaire activée
Prise en charge du déploiement d’un new index Lucene vers AEM avec l’extraction binaire activée
La pré-extraction de texte ne peut pas être utilisée pour un nouveau contenu ajouté au référentiel, et elle n’est pas nécessaire non plus.
Le nouveau contenu est ajouté au référentiel ; il sera indexé de manière naturelle et incrémentielle par le processus d’indexation de texte intégral asynchrone (par défaut, toutes les 5 secondes).
Si AEM fonctionne normalement, par exemple en chargeant des ressources via l’interface utilisateur web ou en programmant l’ingestion des ressources, AEM indexe automatiquement et progressivement le nouveau contenu binaire. Étant donné que la quantité de données est incrémentielle et relativement petite (environ la quantité de données pouvant être conservées dans le référentiel en 5 secondes), AEM peut effectuer l’extraction de texte intégral à partir des binaires pendant l’indexation sans affecter les performances globales du système.
Vous réindexerez un index Lucene qui effectue une extraction binaire en texte intégral ou déployera un nouvel index qui servira de binaires d’index en texte intégral du contenu existant.
Le contenu (binaires) à partir duquel pré-extraire le texte doit se trouver dans le référentiel.
Fenêtre de maintenance pour générer le fichier CSV ET effectuer la réindexation finale
Version Oak : 1.0.18+, 1.2.3+
oak-run.jarversion 1.7.4+
Un dossier/partage de système de fichiers pour stocker le texte extrait accessible depuis les instances AEM d’indexation
Les commandes oak-run.jar décrites ci-dessous sont entièrement énumérées sur https://jackrabbit.apache.org/oak/docs/query/pre-extract-text.html
Le schéma ci-dessus et les étapes ci-dessous servent à expliquer et à compléter les étapes de pré-extraction de texte technique décrites dans la documentation d’Apache Oak.
Génération de la liste du contenu à pré-extraire
Exécutez l’étape 1 (a-b) au cours d’une fenêtre de maintenance/période de faible utilisation lorsque le magasin de noeuds est parcouru pendant cette opération, ce qui peut entraîner une charge importante sur le système.
1a. Exécutez oak-run.jar --generate
pour créer une liste de nœuds dont le texte sera pré-extrait.
1b. La liste des noeuds (1a) est stockée dans le système de fichiers sous la forme d’un fichier CSV.
Notez que l’intégralité du magasin de nœuds est parcouru transversalement (comme spécifié par les chemins dans la commande oak-run) chaque fois que --generate
est exécuté, et qu’un nouveau fichier CSV est créé. Le fichier CSV n’est pas réutilisé entre les exécutions discrètes du processus de pré-extraction de texte (étapes 1 et 2).
Pré-extraction de texte dans le système de fichiers
L’étape 2 (a-c) peut être exécutée pendant le fonctionnement normal d’AEM, car elle interagit uniquement avec l’entrepôt de données.
2a. Exécutez oak-run.jar --tika
pour pré-extraire le texte des nœuds binaires énumérés dans le fichier CSV généré dans (1b).
2b. Le processus lancé à l’étape (2a) accède directement aux nœuds binaires définis dans le fichier CSV du magasin de données et extrait le texte.
2c. Le texte extrait est stocké sur un système de fichiers dans un format que peut acquérir le processus de réindexation d’Oak (3a).
Le texte pré-extrait est identifié dans le fichier CSV par l’empreinte binaire. Si le fichier binaire est le même, le même texte pré-extrait peut être utilisé sur les instances AEM. Comme la publication AEM est généralement un sous-ensemble de l’auteur AEM, le texte préextrait de l’auteur AEM peut souvent être utilisé pour réindexer également la publication AEM (en supposant que la publication AEM dispose d’un accès au système de fichiers aux fichiers texte extraits).
Le texte pré-extrait peut être ajouté de manière incrémentielle au fil du temps. La pré-extraction du texte ignore l’extraction pour les binaires précédemment extraits. Il est donc recommandé de conserver le texte pré-extrait au cas où la réindexation devrait se reproduire dans le futur (en supposant que le contenu extrait ne soit pas trop volumineux. Si c’est le cas, évaluez la compression du contenu entre temps, car le texte se compresse bien).
Réindexation des index Oak, source du texte intégral à partir de fichiers texte extraits
Exécutez la réindexation (étapes 3a-b) au cours d’une période de maintenance/faible utilisation, car le magasin de noeuds est parcouru pendant cette opération, ce qui peut entraîner une charge importante sur le système.
3a. Réindexation des index Lucene sont appelés dans AEM
3b. La configuration OSGi d’Apache Jackrabbit Oak DataStore PreExtractedTextProvider (configurée pour pointer sur le texte extrait via un chemin de système de fichiers) indique à Oak d’extraire le texte intégral des fichiers extraits et évite de toucher directement aux données stockées dans le référentiel et de les traiter.