Ricerca e indicizzazione dei contenuti

Modifiche in AEM as a Cloud Service

Con AEM as a Cloud Service, l’Adobe si sta spostando da un modello AEM incentrato sull’istanza a una visualizzazione basata sui servizi con contenitori AEM n-x, guidato dalle pipeline CI/CD in Cloud Manager. Invece di configurare e mantenere gli indici su singole istanze di AEM, è necessario specificare la configurazione dell'indice prima di una distribuzione. I cambiamenti di configurazione nella produzione stanno chiaramente interrompendo i criteri CI/CD. Lo stesso vale per le modifiche dell'indice in quanto può influire sulla stabilità e sulle prestazioni del sistema se non specificato testato e reindicizzato prima di introdurli nella produzione.

Di seguito è riportato un elenco delle modifiche principali rispetto a AEM 6.5 e versioni precedenti:

  1. Gli utenti non avranno più accesso a Index Manager di una singola istanza AEM per eseguire il debug, configurare o mantenere l'indicizzazione. Viene utilizzato solo per lo sviluppo locale e le distribuzioni on-premise.

  2. Gli utenti non cambieranno gli indici su una singola istanza AEM né dovranno più preoccuparsi dei controlli di coerenza o della reindicizzazione.

  3. In generale, le modifiche dell’indice vengono avviate prima di passare alla produzione per non aggirare i gateway di qualità nelle pipeline CI/CD di Cloud Manager e non influire sui KPI aziendali in produzione.

  4. Tutte le metriche correlate, comprese le prestazioni di ricerca in produzione, saranno disponibili per i clienti in fase di runtime al fine di fornire una visione olistica sugli argomenti di ricerca e indicizzazione.

  5. I clienti potranno impostare gli avvisi in base alle proprie esigenze.

  6. Gli SRE monitorano lo stato di salute del sistema 24/7 e intraprenderanno le azioni necessarie e il più presto possibile.

  7. La configurazione dell’indice viene modificata tramite le distribuzioni. Le modifiche alla definizione dell’indice sono configurate come altre modifiche al contenuto.

  8. Ad un livello elevato su AEM as a Cloud Service, con l'introduzione Modello di distribuzione Blue-Green esistono due serie di indici: un set per la versione precedente (blu) e uno per la nuova versione (verde).

  9. I clienti possono vedere se il processo di indicizzazione è completo nella pagina di compilazione di Cloud Manager e riceveranno una notifica quando la nuova versione è pronta per il traffico.

  10. Limiti:

  • Attualmente, la gestione degli indici su AEM as a Cloud Service è supportata solo per gli indici di tipo lucene.
  • Sono supportati solo gli analizzatori standard (ovvero quelli forniti con il prodotto). Gli analizzatori personalizzati non sono supportati.
  • Internamente, altri indici possono essere configurati e utilizzati per le query. Ad esempio, le query scritte rispetto al damAssetLucene index potrebbe, su Skyline, infatti, essere eseguito contro una versione Elasticsearch di questo indice. Questa differenza generalmente non è visibile all'applicazione e all'utente, tuttavia alcuni strumenti come explain report di un indice diverso. Per le differenze tra gli indici Lucene e gli indici Elastic, vedi la documentazione elastica in Apache Jackrabbit Oak. I clienti non devono e non possono configurare direttamente gli indici di Elasticsearch.

Guida all’uso

La definizione degli indici può comprendere i tre casi d’uso seguenti:

  1. Aggiunta di una nuova definizione dell'indice del cliente.
  2. Aggiornamento di una definizione di indice esistente. Ciò significa effettivamente aggiungere una nuova versione di una definizione di indice esistente.
  3. Rimozione di un indice esistente ridondante o obsoleto.

Per entrambi i punti 1 e 2 di cui sopra, devi creare una nuova definizione dell’indice come parte della base di codice personalizzata nella rispettiva pianificazione della versione di Cloud Manager. Per ulteriori informazioni, consulta la sezione Distribuzione AEM documentazione as a Cloud Service.

Nomi indice

Una definizione di indice può essere:

  1. Un indice preconfigurato. Un esempio è /oak:index/cqPageLucene-2.
  2. Personalizzazione di un indice preconfigurato. Tali personalizzazioni sono definite dal cliente. Un esempio è /oak:index/cqPageLucene-2-custom-1.
  3. Un indice completamente personalizzato. Un esempio è /oak:index/acme.product-1-custom-2. Per evitare conflitti di denominazione, è necessario che gli indici completamente personalizzati abbiano un prefisso, ad esempio acme.

Tieni presente che sia la personalizzazione di un indice predefinito sia gli indici completamente personalizzati devono contenere -custom-. Solo gli indici completamente personalizzati devono iniziare con un prefisso .

Preparazione della nuova definizione dell'indice

NOTA

Se si personalizza un indice predefinito, ad esempio damAssetLucene-6, copia l'ultima definizione di indice preconfigurata da un ambiente Cloud Service utilizzando il CRX DE Package Manager (/crx/packmgr/). Quindi rinominare la configurazione, ad esempio per damAssetLucene-6-custom-1e aggiungi le tue personalizzazioni in alto. In questo modo le configurazioni richieste non vengono rimosse inavvertitamente. Ad esempio, il tika nodo sotto /oak:index/damAssetLucene-6/tika è richiesto nell'indice personalizzato del servizio cloud. Non esiste nell'SDK di Cloud.

È necessario preparare un nuovo pacchetto di definizione dell'indice che contiene la definizione effettiva dell'indice, seguendo questo pattern di denominazione:

<indexName>[-<productVersion>]-custom-<customVersion>

che poi deve scendere ui.apps/src/main/content/jcr_root. Tutte le definizioni di indice personalizzate e personalizzate devono essere memorizzate in /oak:index.

Il filtro per il pacchetto deve essere impostato in modo da mantenere gli indici esistenti (preconfigurati). Nel file ui.apps/src/main/content/META-INF/vault/filter.xml, ogni indice personalizzato (o personalizzato) deve essere elencato, ad esempio <filter root="/oak:index/damAssetLucene-6-custom-1"/>. Se la versione dell’indice viene successivamente modificata, è necessario regolare il filtro.

Il pacchetto del campione di cui sopra è costruito come com.adobe.granite:new-index-content:zip:1.0.0-SNAPSHOT.

NOTA

Qualsiasi pacchetto di contenuto contenente le definizioni degli indici deve avere la seguente proprietà impostata nel file delle proprietà del pacchetto di contenuto, situato in /META-INF/vault/properties.xml:

noIntermediateSaves=true

Distribuzione delle definizioni degli indici

Le definizioni degli indici sono contrassegnate come personalizzate e con versione:

  • La definizione stessa dell'indice (ad esempio /oak:index/ntBaseLucene-custom-1)

Per distribuire un indice personalizzato o personalizzato, la definizione dell’indice (/oak:index/definitionname) deve essere fornita tramite ui.apps tramite Git e il processo di implementazione di Cloud Manager. Nel filtro FileVault, ad esempio ui.apps/src/main/content/META-INF/vault/filter.xml, elencare singolarmente ogni indice personalizzato e personalizzato, ad esempio <filter root="/oak:index/damAssetLucene-7-custom-1"/>. La definizione di indice personalizzata/personalizzata verrà quindi memorizzata nel file ui.apps/src/main/content/jcr_root/_oak_index/damAssetLucene-7-custom-1/.content.xml, come segue:

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:oak="http://jackrabbit.apache.org/oak/ns/1.0" xmlns:dam="http://www.day.com/dam/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:rep="internal"
        jcr:primaryType="oak:QueryIndexDefinition"
        async="[async,nrt]"
        compatVersion="{Long}2"
        ...
        </indexRules>
        <tika jcr:primaryType="nt:unstructured">
            <config.xml jcr:primaryType="nt:file"/>
        </tika>
</jcr:root>

L'esempio precedente contiene una configurazione per Apache Tika. Il file di configurazione Tika verrebbe memorizzato in ui.apps/src/main/content/jcr_root/_oak_index/damAssetLucene-7-custom-1/tika/config.xml.

Configurazione del progetto

A seconda della versione del plug-in pacchetto Maven Jackrabbit Filevault, è necessaria un’ulteriore configurazione del progetto. Quando si utilizza la versione del plug-in del pacchetto Maven Jackrabbit Filevault 1.1.6. o successivo, quindi il file pom.xml deve contenere la seguente sezione nella configurazione del plug-in per filevault-package-maven-plugin, in configuration/validatorsSettings (appena prima jackrabbit-nodetypes):

<jackrabbit-packagetype>
    <options>
        <immutableRootNodeNames>apps,libs,oak:index</immutableRootNodeNames>
    </options>
</jackrabbit-packagetype>

Inoltre, in questo caso il vault-validation la versione deve essere aggiornata a una versione più recente:

<dependency>
    <groupId>org.apache.jackrabbit.vault</groupId>
    <artifactId>vault-validation</artifactId>
    <version>3.5.6</version>
</dependency>

Quindi, in ui.apps.structure/pom.xml e ui.apps/pom.xml, la configurazione filevault-package-maven-plugin deve avere allowIndexDefinitions nonché noIntermediateSaves abilitato. Opzione noIntermediateSaves assicura che le configurazioni dell'indice vengano aggiunte atomicamente.

<groupId>org.apache.jackrabbit</groupId>
    <artifactId>filevault-package-maven-plugin</artifactId>
    <configuration>
        <allowIndexDefinitions>true</allowIndexDefinitions>
        <properties>
            <cloudManagerTarget>none</cloudManagerTarget>
            <noIntermediateSaves>true</noIntermediateSaves>
        </properties>
    ...

In ui.apps.structure/pom.xml, filters per questo plug-in deve contenere una radice di filtro come segue:

<filter><root>/oak:index</root></filter>

Una volta aggiunta la nuova definizione dell’indice, la nuova applicazione deve essere distribuita tramite Cloud Manager. All’avvio della distribuzione vengono avviati due processi, responsabili dell’aggiunta (e dell’unione, se necessario) delle definizioni dell’indice a MongoDB e Azure Segment Store rispettivamente per l’authoring e la pubblicazione. Gli archivi sottostanti vengono reindicizzati con le nuove definizioni dell'indice, prima che si verifichi lo switch Blue-Green.

SUGGERIMENTO

Per ulteriori dettagli sulla struttura del pacchetto richiesta per AEM as a Cloud Service, vedere il documento AEM struttura del progetto.

Gestione dell'indice utilizzando le implementazioni Blue-Green

Gestione dell'indice

La gestione degli indici riguarda l’aggiunta, la rimozione e la modifica degli indici. Modifica della definizione di un indice è veloce, ma l'applicazione della modifica (spesso chiamata "creazione di un indice", o, per gli indici esistenti, "reindicizzazione") richiede tempo. Non è istantaneo: l’archivio deve essere analizzato per individuare i dati da indicizzare.

Installazione Blue-Green

L'implementazione Blue-Green può ridurre i tempi di inattività. Consente inoltre di eseguire senza tempi di inattività gli aggiornamenti e offre rapidi rollback. La vecchia versione dell'applicazione (blu) viene eseguita contemporaneamente alla nuova versione dell'applicazione (verde).

Aree di sola lettura e di lettura/scrittura

Alcune aree dell’archivio (parti di sola lettura dell’archivio) possono essere diverse nella vecchia versione (blu) e nella nuova versione (verde) dell’applicazione. Le aree di sola lettura dell'archivio sono tipicamente "/app" e "/libs". Nell’esempio seguente, il corsivo viene utilizzato per contrassegnare le aree di sola lettura, mentre il grassetto viene utilizzato per le aree di lettura/scrittura.

  • /
  • /apps (sola lettura)
  • /content
  • /libs (sola lettura)
  • /oak:index
  • /oak:index/acme.
  • /jcr:system
  • /system
  • /var

Le aree di lettura-scrittura dell'archivio sono condivise tra tutte le versioni dell'applicazione, mentre per ogni versione dell'applicazione, esiste un set specifico di /apps e /libs.

Gestione degli indici senza implementazione Blue-Green

Durante lo sviluppo o quando si utilizzano installazioni locali, gli indici possono essere aggiunti, rimossi o modificati in fase di runtime. Gli indici vengono utilizzati non appena sono disponibili. Se un indice non deve ancora essere utilizzato nella vecchia versione dell'applicazione, l'indice viene generalmente generato durante un downtime pianificato. Lo stesso si verifica quando si rimuove un indice o si modifica un indice esistente. Quando si rimuove un indice, questo diventa non disponibile non appena viene rimosso.

Gestione dell'indice con implementazione Blue-Green

Con le implementazioni blu-verde, non si verificano tempi di inattività. Durante un aggiornamento, per un certo periodo di tempo, sia la vecchia versione (ad esempio, la versione 1) dell’applicazione, sia la nuova versione (versione 2), vengono eseguite contemporaneamente sullo stesso archivio. Se la versione 1 richiede la disponibilità di un determinato indice, questo non deve essere rimosso nella versione 2: l'indice deve essere rimosso in un secondo momento, ad esempio nella versione 3, nel quale è garantito che la versione 1 dell'applicazione non è più in esecuzione. Inoltre, le applicazioni devono essere scritte in modo che la versione 1 funzioni bene, anche se la versione 2 è in esecuzione, e se sono disponibili indici della versione 2.

Al termine dell'aggiornamento alla nuova versione, i vecchi indici possono essere raccolti dal sistema. I vecchi indici potrebbero restare ancora per un po' di tempo, al fine di velocizzare i rollback (se dovesse essere necessario un rollback).

La tabella seguente mostra cinque definizioni di indice: index cqPageLucene viene utilizzato in entrambe le versioni mentre index damAssetLucene-custom-1 viene utilizzato solo nella versione 2.

NOTA

<indexName>-custom-<customerVersionNumber> è necessario per AEM as a Cloud Service per contrassegnare questo come sostitutivo di un indice esistente.

Indice Indice predefinito Usa nella versione 1 Usa nella versione 2
/oak:index/damAssetLucene No
/oak:index/damAssetLucene-custom-1 Sì (personalizzato) No
/oak:index/acme.product-custom-1 No No
/oak:index/acme.product-custom-2 No No
/oak:index/cqPageLucene

Il numero di versione viene incrementato ogni volta che l’indice viene modificato. Per evitare che i nomi di indice personalizzati si scontrino con i nomi di indice del prodotto stesso, gli indici personalizzati e le modifiche agli indici predefiniti devono terminare con -custom-<number>.

Modifiche agli indici predefiniti

Una volta che Adobe cambia un indice predefinito come "damAssetLucene" o "cqPageLucene", un nuovo indice denominato damAssetLucene-2 o cqPageLucene-2 viene creato oppure, se l'indice è già stato personalizzato, la definizione di indice personalizzato viene unita alle modifiche nell'indice predefinito, come mostrato di seguito. L'unione delle modifiche avviene automaticamente. Ciò significa che non è necessario eseguire alcuna operazione se un indice predefinito cambia. Tuttavia, è possibile personalizzare di nuovo l'indice in un secondo momento.

Indice Indice predefinito Usa nella versione 2 Usa nella versione 3
/oak:index/damAssetLucene-custom-1 Sì (personalizzato) No
/oak:index/damAssetLucene-2-custom-1 Sì (unito automaticamente da damAssetLucene-custom-1 e damAssetLucene-2) No
/oak:index/cqPageLucene No
/oak:index/cqPageLucene-2 No

Limitazioni attuali

La gestione degli indici è attualmente supportata solo per gli indici di tipo lucene. Internamente, altri indici possono essere configurati e utilizzati per le query, ad esempio indici elastici.

Aggiunta di un indice

Per aggiungere un indice completamente personalizzato denominato /oak:index/acme.product-custom-1 per essere utilizzato in una nuova versione dell'applicazione e successivamente, l'indice deve essere configurato come segue:

acme.product-1-custom-1

Questo funziona precedendo un identificatore personalizzato al nome dell'indice, seguito da un punto (.). La lunghezza dell'identificatore deve essere compresa tra 2 e 5 caratteri.

Come sopra, questo assicura che l'indice sia utilizzato solo dalla nuova versione dell'applicazione.

Modifica di un indice

Quando viene modificato un indice esistente, è necessario aggiungere un nuovo indice con la modifica della definizione dell'indice. Ad esempio, considera l'indice esistente /oak:index/acme.product-custom-1 viene modificato. Il vecchio indice è memorizzato in /oak:index/acme.product-custom-1e il nuovo indice è memorizzato in /oak:index/acme.product-custom-2.

La vecchia versione dell'applicazione utilizza la seguente configurazione:

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

La nuova versione dell’applicazione utilizza la seguente configurazione (modificata):

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

NOTA

Le definizioni degli indici su AEM as a Cloud Service potrebbero non corrispondere completamente alle definizioni degli indici su un'istanza di sviluppo locale. L'istanza di sviluppo non dispone di una configurazione Tika, mentre AEM istanze as a Cloud Service ne hanno una. Se si personalizza un indice con una configurazione Tika, si prega di mantenere la configurazione Tika.

Annullamento di una modifica

A volte, è necessario ripristinare una modifica nella definizione di un indice. Le ragioni potrebbero essere che un cambiamento è stato fatto per errore, o che non è più necessario un cambiamento. Ad esempio, la definizione dell'indice damAssetLucene-8-custom-3 è stato creato per errore ed è già distribuito. Per questo motivo, potrebbe essere utile ripristinare la precedente definizione dell'indice damAssetLucene-8-custom-2. A questo scopo, devi aggiungere un nuovo indice denominato damAssetLucene-8-custom-4 che contiene la definizione dell'indice precedente, damAssetLucene-8-custom-2.

Rimozione di un indice

Il seguente si applica solo agli indici personalizzati. Gli indici di prodotto non possono essere rimossi in quanto sono utilizzati da AEM.

Se un indice deve essere rimosso in una versione successiva dell'applicazione, è possibile definire un indice vuoto (un indice vuoto che non viene mai utilizzato e non contiene dati) con un nuovo nome. Ai fini di questo esempio, è possibile denominarlo /oak:index/acme.product-custom-3. Questo sostituisce l'indice /oak:index/acme.product-custom-2. Una volta /oak:index/acme.product-custom-2 viene rimosso dal sistema, l'indice vuoto /oak:index/acme.product-custom-3 possono quindi essere rimossi. Un esempio di tale indice vuoto è:

<acme.product-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-custom-3>

Se non è più necessario avere una personalizzazione di un indice predefinito, è necessario copiare la definizione di indice preconfigurata. Ad esempio, se hai già distribuito damAssetLucene-8-custom-3, ma non sono più necessarie le personalizzazioni e desiderano tornare al valore predefinito damAssetLucene-8 indice, quindi devi aggiungere un indice damAssetLucene-8-custom-4 che contiene la definizione dell'indice di damAssetLucene-8.

Ottimizzazioni degli indici

Apache Jackrabbit Oak consente configurazioni di indice flessibili per gestire in modo efficiente le query di ricerca. Gli indici sono particolarmente importanti per gli archivi più grandi. Assicurati che tutte le query siano supportate da un indice appropriato. Le query senza un indice appropriato possono leggere migliaia di nodi, che vengono quindi registrate come avviso. Tali query devono essere identificate analizzando i file di registro, in modo da ottimizzare le definizioni degli indici. Vedi questa pagina per ulteriori informazioni.

Indice full text Lucene su AEM as a Cloud Service

Indice fulltext /oak:index/lucene-2 può diventare molto grande perché indicizza tutti i nodi nell’archivio AEM per impostazione predefinita. In seguito ai piani dell’Adobe di ritirarlo, questo indice non verrà più utilizzato sul lato prodotto in AEM as a Cloud Service e non dovrebbe essere richiesto di eseguire il codice cliente. Per AEM ambienti as a Cloud Service con indici Lucene comuni, Adobe sta lavorando con i clienti singolarmente per un approccio coordinato per compensare questo indice e per utilizzare indici migliori e ottimizzati. I clienti non devono effettuare alcuna azione senza ulteriore preavviso da parte dell’Adobe. AEM clienti as a Cloud Service saranno informati per Adobe quando è necessario intervenire in merito a questa ottimizzazione. Se questo indice è necessario per le query personalizzate, come soluzione temporanea, una copia di questo indice deve essere creata utilizzando un nome diverso, ad esempio /oak:index/acme.lucene-1-custom-1, come descritto qui.
Questa ottimizzazione non si applica per impostazione predefinita ad altri ambienti AEM ospitati on-premise o gestiti da Adobe Managed Services.

Ottimizzazioni delle query

La Prestazioni query lo strumento ti consente di osservare query JCR sia popolari che lente. Inoltre, è in grado di analizzare le query e visualizzare varie informazioni su, soprattutto se viene utilizzato un indice per questa query o meno.

A differenza di AEM on-premise, AEM as a Cloud Service non visualizza il Prestazioni query nell'interfaccia utente. È ora disponibile tramite la Console per sviluppatori (in Cloud Manager) nella sezione Query scheda .

In questa pagina