Recherche et indexation de contenu indexing

Changements dans AEM as a Cloud Service changes-in-aem-as-a-cloud-service

Avec AEM as a Cloud Service, Adobe s’éloigne d’un modèle centré sur les instances AEM pour passer à une vue basée sur les services avec des conteneurs n-x pilotés par des pipelines CI/CD dans Cloud Manager. Au lieu de configurer et de gérer les index sur des instances AEM uniques, la configuration d’index doit être spécifiée avant un déploiement. Les modifications de configuration dans la production enfreignent les politiques CI/CD. Il en va de même pour les modifications d’index, car celles-ci peuvent avoir un impact sur la stabilité et les performances du système si elles ne sont pas spécifiées, testées et réindexées avant leur mise en production.

Voici la liste des principaux changements par rapport à AEM 6.5 et les versions antérieures :

Restrictions :

Utilisation how-to-use

Les définitions d’index peuvent être classées en trois cas d’utilisation principaux, comme suit :

Pour les points 1 et 2 ci-dessus, vous devez créer une définition d’index dans le cadre de votre base de code personnalisé dans le planning de publication Cloud Manager correspondant. Pour plus d’informations, consultez la documentation Déploiement sur AEM as a Cloud Service.

Noms d’index index-names

Une définition d’index peut appartenir à l’une des catégories suivantes :

Préparation de la nouvelle définition d’index preparing-the-new-index-definition

Pour les personnalisations d’un index prêt à l’emploi, préparez un nouveau package contenant la définition d’index personnalisée. Le nom de l’index doit suivre le modèle de dénomination :

<indexName>-<productVersion>-custom-<customVersion>

Pour un index entièrement personnalisé, préparez un nouveau package de définition d’index contenant la définition d’index qui suit ce modèle de dénomination :

<prefix>.<indexName>-<productVersion>-custom-<customVersion>

Comme indiqué dans les sections sur les limites , la type de la définition d’index personnalisée doit toujours être définie sur lucene même si la définition d’index extraite à l’aide du gestionnaire de packages est d’un type différent (par exemple, elasticsearch).
La propriété async doit également être modifiée au cas où la définition d’index extraite est définie sur elastic-async. La propriété async doit être définie sur l’une des propriétés suivantes : [async], [async,nrt] ou [fulltext-async] pour la définition d’index personnalisée.

Déploiement de définitions d’index personnalisées deploying-custom-index-definitions

Pour illustrer le déploiement d’une version personnalisée du damAssetLucene-8 d’index prêt à l’emploi, nous vous fournirons un guide détaillé. Dans cet exemple, nous allons le renommer en damAssetLucene-8-custom-1. Le processus se présente alors comme suit :

Configuration du projet

Nous vous recommandons vivement d’utiliser la 1.3.2 version >= du Jackrabbit filevault-package-maven-plugin. Les étapes à suivre pour l’incorporer à votre projet sont les suivantes :

Après avoir ajouté la nouvelle définition d’index, déployez la nouvelle application à l’aide de Cloud Manager. Ce déploiement lance deux tâches, chargées d’ajouter (et de fusionner si nécessaire) les définitions d’index à MongoDB et Azure Segment Store pour la création et la publication, respectivement. Avant le changement, les référentiels sous-jacents sont réindexés avec les définitions d’index mises à jour.

Gestion des index à l’aide de déploiements en continu index-management-using-rolling-deployments

Qu’est-ce que la gestion des index ? what-is-index-management

La gestion des index consiste à ajouter, supprimer et modifier des index. Changer la définition d’un index est rapide, mais appliquer le changement (opération souvent appelée « création d’un index » ou, pour les index existants, « réindexation ») nécessite du temps. Cette opération n’est pas instantanée : le référentiel doit être analysé pour que les données soient indexées.

Que sont les déploiements en continu ? what-are-rolling-deployments

Un déploiement en continu permet des mises à niveau sans interruption de service et des restaurations rapides. L’ancienne version de l’application s’exécute en même temps que la nouvelle version.

Zones en lecture seule et en lecture-écriture read-only-and-read-write-areas

Certaines zones du référentiel (parties en lecture seule) peuvent être différentes dans l’ancienne version et dans la nouvelle version de l’application. Les zones en lecture seule du référentiel sont généralement /app et /libs. Dans l’exemple suivant, des italiques sont utilisés pour marquer les zones en lecture seule, tandis que du gras est utilisé pour les zones en lecture-écriture.

Les zones de lecture-écriture du référentiel sont partagées entre toutes les versions de l’application, tandis que pour chaque version de l’application, il existe un ensemble spécifique de /apps et /libs.

Gestion des index sans déploiements en continu index-management-without-rolling-deployments

Lors du développement ou de l’utilisation d’installations on-premise, les index peuvent être ajoutés, supprimés ou modifiés au moment de l’exécution. Les index sont utilisés lorsqu’ils sont disponibles. Si un index n’est pas encore utilisé dans l’ancienne version de l’application, il est généralement créé lors d’un temps d’arrêt planifié. Il en va de même lors de la suppression d’un index ou de la modification d’un index existant. Lors de la suppression d’un index, il cesse d’être disponible dès sa suppression.

Gestion des index avec déploiements en continu index-management-with-rolling-deployments

Avec des déploiements en continu, il n’existe pas de temps d’arrêt. Pendant un certain temps lors d’une mise à jour, l’ancienne version (par exemple, la version 1) de l’application et la nouvelle version (la version 2) s’exécutent simultanément sur le même référentiel. Si la version 1 nécessite la disponibilité d’un certain index, celui-ci ne doit pas être supprimé dans la version 2. L’index doit être supprimé ultérieurement, par exemple dans la version 3. À ce stade, il est garanti que la version 1 de l’application n’est plus en cours d’exécution. En outre, les applications doivent être écrites de manière à ce que la version 1 fonctionne correctement, même si la version 2 est en cours d’exécution et si des index de la version 2 sont disponibles.

Une fois la mise à niveau vers la nouvelle version terminée, les anciens index peuvent être récupérés par le système. Les anciens index sont généralement conservés pendant une semaine afin d’accélérer les restaurations (si une restauration doit être nécessaire).

Le tableau suivant présente cinq définitions d’index : l’index cqPageLucene est utilisé dans les deux versions tandis que index damAssetLucene-custom-1 l’est uniquement dans la version 2.

Le numéro de version est incrémenté chaque fois que l’index est modifié. Pour éviter que des noms d’index personnalisés n’entrent en conflit avec des noms d’index du produit lui-même, les index personnalisés et les modifications apportées aux index prêts à l’emploi doivent se terminer par -custom-<number>.

Modifications apportées aux index prêts à l’emploi changes-to-out-of-the-box-indexes

Après qu’Adobe a modifié un index prêt à l’emploi tel que damAssetLucene ou cqPageLucene, un nouvel index nommé damAssetLucene-2 ou cqPageLucene-2 est créé. Ou, si l’index a déjà été personnalisé, la définition d’index personnalisé est fusionnée avec les modifications de l’index prêt à l’emploi, comme illustré ci-dessous. La fusion des modifications se produit automatiquement. Cela signifie que vous n’avez rien à faire si un index prêt à l’emploi change. Cependant, il est possible de personnaliser à nouveau l’index ultérieurement. Dans ce cas, il est important d’utiliser la dernière version (fusionnée) comme ligne de base.

Il est important de noter que les environnements peuvent se trouver dans différentes versions d’AEM. Par exemple : dev environnement est en version X+1 alors que l’évaluation et la production sont toujours en version X et attendent d’être mises à niveau vers la version X+1 après que les tests requis sur les dev ont été effectués. Si la version X+1 est fournie avec une version plus récente d’un index de produit qui a été personnalisé et qu’une nouvelle personnalisation de cet index est requise, le tableau suivant explique les versions à définir sur les environnements basés sur la version AEM :

Limites actuelles current-limitations

La gestion des index n’est prise en charge que pour les index de type lucene, avec la compatVersion définie sur 2. En interne, d’autres index peuvent être configurés et utilisés pour les requêtes, par exemple les index Elasticsearch. Les requêtes écrites sur l’index damAssetLucene peuvent, sur AEM as a Cloud Service, être exécutées sur une version Elasticsearch de cet index. Cette différence n’est pas visible par l’utilisateur de l’application, mais certains outils tels que la fonctionnalité explain signalent un index différent. Pour connaître les différences entre les index Lucene et Elasticsearch, consultez la documentation d’Elasticsearch dans Apache Jackrabbit Oak. Les index Elasticsearch ne peuvent pas et n’ont pas besoin d’être configurés directement par les client(e)s.

Seuls les analyseurs intégrés sont pris en charge (c’est-à-dire les analyseurs fournis avec le produit). Les analyseurs personnalisés ne sont pas pris en charge.

Actuellement, l’indexation du contenu des /oak:index n’est pas prise en charge.

Pour de meilleures performances opérationnelles, les index ne doivent pas être trop volumineux. La taille totale de tous les index peut servir de guide. Si cette taille augmente de plus de 100 % après l’ajout d’index personnalisés et si les index standard ont été ajustés sur un environnement de développement, les définitions d’index personnalisées doivent être ajustées. AEM as a Cloud Service peut empêcher le déploiement de ou supprimer des index qui auraient un impact négatif sur la stabilité et les performances du système.

Ajouter un index adding-an-index

Pour ajouter un index entièrement personnalisé nommé « /oak:index/acme.product-1-custom-1 » à utiliser dans une nouvelle version de l’application et ultérieurement, l’index doit être configuré comme suit :

acme.product-1-custom-1

Cette opération consiste à ajouter un identifiant personnalisé au nom de l’index, suivi d’un point (.). L’identifiant doit comporter de 2 à 5 caractères.

Comme ci-dessus, cette configuration garantit que l’index n’est utilisé que par la nouvelle version de l’application.

Modifier un index changing-an-index

Lorsqu’un index existant est modifié, un nouvel index doit être ajouté avec la définition d’index modifiée. Par exemple, imaginons que l’index existant « /oak:index/acme.product-1-custom-1 » a été modifié. L’ancien index est stocké sous /oak:index/acme.product-1-custom-1 et le nouvel index sous /oak:index/acme.product-1-custom-2.

L’ancienne version de l’application utilise la configuration suivante :

/oak:index/acme.product-1-custom-1

La nouvelle version de l’application utilise la configuration suivante (modifiée) :

/oak:index/acme.product-1-custom-2

Annuler une modification undoing-a-change

Parfois, il est nécessaire d’annuler une modification dans une définition d’index, par exemple en raison d’une erreur ou parce que la modification n’est plus nécessaire. Par exemple, si la définition d’index damAssetLucene-8-custom-3 contient une erreur, vous pouvez revenir à la définition précédente, damAssetLucene-8-custom-2. Pour ce faire, créez un index nommé damAssetLucene-8-custom-4 qui est une copie de l’index précédent, damAssetLucene-8-custom-2.

Suppression d’un index removing-an-index

Les éléments suivants s’appliquent uniquement aux personnalisations des index prêts à l’emploi et aux index entièrement personnalisés. Notez que les index prêts à l’emploi d’origine ne peuvent pas être supprimés, car ils sont utilisés par AEM.

Pour garantir l’intégrité et la stabilité du système, les définitions d’index doivent être traitées comme immuables une fois déployées. Si vous devez supprimer un index personnalisé ou une personnalisation, créez une nouvelle version de cet index avec une définition qui simule efficacement la suppression
(voir les exemples ci-dessous).

Une fois qu’une nouvelle version d’un index est déployée, l’ancienne version du même index ne sera plus utilisée par les requêtes.
L’ancienne version ne sera pas immédiatement supprimée de l’environnement.
mais deviendra éligible à la récupération de l’espace mémoire par un mécanisme de nettoyage qui s’exécute périodiquement.
Après une période de grâce conçue pour permettre la récupération en cas d'erreurs
(actuellement, 7 jours à compter de la date de suppression de l’indexation, mais sous réserve de modifications),
ce mécanisme de nettoyage supprimera les données d’index inutilisées,
et désactivent ou suppriment l’ancienne version de l’index de l’environnement.

Vous trouverez ci-dessous une description des deux cas possibles : suppression des personnalisations d’un index prêt à l’emploi et suppression d’un index entièrement personnalisé.

Suppression des personnalisations d’un index prêt à l’emploi

Suivez les étapes décrites dans Annulation d’une modification en utilisant les définitions de l’index prêt à l’emploi en tant que nouvelle version. Par exemple, si vous avez déjà déployé damAssetLucene-8-custom-3, mais que vous n’avez plus besoin des personnalisations et que vous souhaitez revenir à l’index damAssetLucene-8 par défaut, vous devez ajouter un damAssetLucene-8-custom-4 d’index contenant la définition d’index de damAssetLucene-8.

Suppression d’un index entièrement personnalisé

Suivez les étapes décrites dans Annulation d’une modification en utilisant un index factice comme nouvelle version. Un index factice n’est jamais utilisé pour les requêtes et ne contient aucune donnée. L’effet est donc le même que si l’index n’existait pas. Par exemple, vous pouvez le nommer /oak:index/acme.product-1-custom-3. Ce nom remplace l’index /oak:index/acme.product-1-custom-2. Voici un exemple d’index factice :

<acme.product-1-custom-3
        jcr:primaryType="oak:QueryIndexDefinition"
        async="async"
        compatVersion="2"
        includedPaths="/dummy"
        queryPaths="/dummy"
        type="lucene">
        <indexRules jcr:primaryType="nt:unstructured">
            <rep:root jcr:primaryType="nt:unstructured">
                <properties jcr:primaryType="nt:unstructured">
                    <dummy
                        jcr:primaryType="nt:unstructured"
                        name="dummy"
                        propertyIndex="{Boolean}true"/>
                </properties>
            </rep:root>
        </indexRules>
</acme.product-1-custom-3>

Optimisations des index et des requêtes index-query-optimizations

Apache Jackrabbit Oak offre des configurations d’index flexibles pour gérer efficacement les requêtes de recherche. Les index sont particulièrement importants pour les référentiels les plus volumineux. Assurez-vous que toutes les requêtes sont soutenues par un index approprié. Les requêtes sans index approprié peuvent lire des milliers de nœuds qui sont ensuite consignés en tant qu’avertissements.

Veuillez consulter ce document pour en savoir plus sur la manière dont les requêtes et les index peuvent être optimisés.