Best practice per query e indicizzazione

Oltre alla transizione a Oak nell’AEM 6, sono state apportate alcune modifiche importanti al modo in cui vengono gestite le query e gli indici. In Jackrabbit 2, tutto il contenuto era indicizzato per impostazione predefinita e poteva essere interrogato liberamente. In Oak, gli indici devono essere creati manualmente sotto oak:index nodo. Una query può essere eseguita senza un indice, ma per i set di dati di grandi dimensioni verrà eseguita molto lentamente o verrà interrotta.

Questo articolo illustra quando creare indici e quando non sono necessari, trucchi per evitare di utilizzare le query quando non sono necessarie e suggerimenti per ottimizzare indici e query in modo da ottenere le migliori prestazioni possibili.

Inoltre, leggi le Documentazione Oak sulla scrittura di query e indici. Oltre al fatto che gli indici sono un nuovo concetto nell’AEM 6, esistono differenze sintattiche nelle query Oak che devono essere prese in considerazione durante la migrazione del codice da una precedente installazione dell’AEM.

Quando utilizzare le query

Struttura dell’archivio e della tassonomia

Durante la progettazione della tassonomia di un archivio, occorre tenere conto di diversi fattori, Ad esempio, controlli di accesso, localizzazione, ereditarietà di componenti e proprietà di pagina.

Durante la progettazione di una tassonomia che tenga conto di questi problemi, è importante anche considerare la “fruibilità” del design di indicizzazione. In questo contesto, la navigabilità è la capacità di una tassonomia che consente l’accesso prevedibile al contenuto in base al suo percorso. In questo modo si otterrà un sistema più performante e più semplice da gestire di uno che richiederà l’esecuzione di molte query.

Inoltre, durante la progettazione di una tassonomia, è importante considerare l’importanza dell’ordinamento. Nei casi in cui non è richiesto un ordinamento esplicito e si prevede un numero elevato di nodi di pari livello, è preferibile utilizzare un tipo di nodo non ordinato come sling:Folder o oak:Unstructured. Nei casi in cui è richiesto l’ordinamento, nt:unstructured e sling:OrderedFolder potrebbero essere più adatti.

Query nei componenti

Poiché le query possono essere una delle operazioni più gravose su un sistema AEM, è consigliabile evitarle nei componenti. Spesso, l’esecuzione di più query ogni volta che viene eseguito il rendering di una pagina può compromettere le prestazioni del sistema. Esistono due strategie che possono essere utilizzate per evitare l’esecuzione di query durante il rendering dei componenti: navigazione dei nodi e preacquisizione dei risultati.

Navigazione dei nodi

Se l’archivio è progettato in modo tale da consentire una conoscenza preventiva della posizione dei dati richiesti, il codice che recupera tali dati dai percorsi necessari può essere utilizzato senza dover eseguire query per trovarli.

Un esempio potrebbe essere il rendering di contenuti che rientrano a una determinata categoria. Un approccio consiste nell’organizzare i contenuti con una proprietà di categoria su cui è possibile eseguire una query per compilare un componente che mostra gli elementi in una categoria.

Un approccio migliore consisterebbe nello strutturare i contenuti in una tassonomia per categoria, in modo da poterli recuperare manualmente.

Ad esempio, se il contenuto viene memorizzato in una tassonomia simile a:

/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

il /content/myUnstructuredContent/parentCategory/childCategory nodo può essere semplicemente recuperato, i relativi nodi secondari possono essere analizzati e utilizzati per eseguire il rendering del componente.

Inoltre, quando si tratta di un set di risultati piccolo o omogeneo, navigare l’archivio e raccogliere i nodi richiesti può essere una soluzione più veloce rispetto alla creazione di una query per restituire lo stesso set di risultati. In generale, occorre evitare le query laddove possibile.

Preacquisizione dei risultati

A volte il contenuto o i requisiti relativi al componente non consentono l’utilizzo della navigazione dei nodi come metodo per recuperare i dati richiesti. In questi casi, è necessario eseguire le query richieste prima di eseguire il rendering del componente in modo da garantire prestazioni ottimali per l’utente finale.

Se i risultati richiesti per il componente possono essere calcolati al momento della creazione e non c’è alcuna aspettativa che il contenuto cambi, la query può essere eseguita quando l’autore applica le impostazioni nella finestra di dialogo.

Se i dati o il contenuto vengono modificati regolarmente, la query può essere eseguita secondo una pianificazione o tramite un listener per gli aggiornamenti dei dati sottostanti. Dopodiché, i risultati possono essere scritti in una posizione condivisa nell’archivio. Tutti i componenti che necessitano di questi dati possono quindi richiamare i valori da questo singolo nodo senza dover eseguire una query in fase di esecuzione.

Ottimizzazione query

Quando si esegue una query che non utilizza un indice, vengono registrati avvisi relativi all’attraversamento dei nodi. Se si tratta di una query che verrà eseguita spesso, è necessario creare un indice. Per determinare quale indice viene utilizzato da una determinata query, Strumento Spiega query è consigliato. Per ulteriori informazioni, la registrazione DEBUG può essere abilitata per le API di ricerca pertinenti.

Durante l’esecuzione di query complesse, possono verificarsi casi in cui la query viene suddivisa in più query più piccole e i dati vengono uniti tramite il codice dopo che il fatto è più performante. Per questi casi si raccomanda di confrontare le prestazioni dei due approcci per determinare quale opzione sarebbe migliore per il caso d’uso in questione.

L’AEM consente di scrivere le query in uno dei tre modi seguenti:

• Attraverso il API QueryBuilder (consigliato)
• Utilizzo di XPath (consigliato)
• Utilizzo di SQL2

Anche se tutte le query vengono convertite in SQL2 prima di essere eseguite, il sovraccarico della conversione delle query è minimo e, di conseguenza, la principale preoccupazione quando si sceglie un linguaggio di query sarà la leggibilità e il livello di comfort dal team di sviluppo.

Strumento Spiega query

Come per qualsiasi linguaggio di query, il primo passaggio per ottimizzare una query consiste nel capire come verrà eseguita. Per abilitare questa attività, puoi utilizzare Strumento Spiega query che fa parte del dashboard operazioni. Con questo strumento, è possibile collegare e spiegare una query. Verrà visualizzato un avviso se la query causerà problemi con un archivio di grandi dimensioni, nonché con il tempo di esecuzione e gli indici che verranno utilizzati. Lo strumento può anche caricare un elenco di query lente e popolari che possono quindi essere spiegate e ottimizzate.

Registrazione DEBUG per query

Per ottenere ulteriori informazioni sulla scelta dell’indice da utilizzare da parte di Oak e sul modo in cui il motore di query esegue effettivamente una query, si consiglia di: DEBUG è possibile aggiungere la configurazione di registrazione per i seguenti pacchetti:

• org.apache.jackrabbit.oak.plugins.index
• org.apache.jackrabbit.oak.query
• com.day.cq.search

Assicurati di rimuovere questo logger una volta completato il debug della query, in quanto restituirà molta attività e alla fine potrà riempire il disco con i file di registro.

Per ulteriori informazioni, vedere Documentazione sulla registrazione.

Statistiche indice

Lucene registra un bean JMX che fornirà dettagli sul contenuto indicizzato, incluse le dimensioni e il numero di documenti presenti in ciascuno degli indici.

Puoi raggiungerlo accedendo alla console JMX all’indirizzo https://server:port/system/console/jmx

Dopo aver effettuato l’accesso alla console JMX, cerca Statistiche indice Lucene per trovarlo. Altre statistiche di indice sono disponibili nella sezione IndexStats MBean.

Per le statistiche delle query, osserva il codice MBean denominato Statistiche query Oak.

Se desideri esplorare gli indici utilizzando uno strumento come Luke, è necessario utilizzare la console Oak per scaricare l’indice dal NodeStore in una directory del file system. Per istruzioni su come eseguire questa operazione, leggere il Documentazione di Lucene.

Puoi anche estrarre gli indici nel sistema in formato JSON. A questo scopo, devi accedere a https://server:port/oak:index.tidy.-1.json

Limiti per le query

Durante lo sviluppo

Imposta soglie basse per oak.queryLimitInMemory (es. 10000) e quercia. queryLimitReads (es. 5000) e ottimizzano la costosa query quando si preme un UnsupportedOperationException che indica "La query legge più di x nodi…"

Questo consente di evitare query che richiedono molte risorse (ad esempio non supportato da alcun indice o supportato da un indice di copertura inferiore). Ad esempio, una query che legge 1 milione di nodi porterebbe a un aumento dell’I/O e avrebbe un impatto negativo sulle prestazioni complessive dell’applicazione. Qualsiasi query che non riesce a causa di limiti superiori deve essere analizzata e ottimizzata.

Post-distribuzione

• Monitora i registri per le query che attivano l’attraversamento di nodi di grandi dimensioni o il consumo di memoria heap di grandi dimensioni: "

  • *WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.
  • Ottimizza la query per ridurre il numero di nodi attraversati

• Monitora i registri per le query che attivano un consumo elevato di memoria heap:

  • *WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped
  • Ottimizza la query per ridurre il consumo di memoria heap

Per le versioni da AEM 6.0 a 6.2, è possibile regolare la soglia per l’attraversamento dei nodi tramite i parametri JVM nello script di avvio dell’AEM per evitare che le query di grandi dimensioni sovraccarichi l’ambiente.

I valori consigliati sono:

• -Doak.queryLimitInMemory=500000
• -Doak.queryLimitReads=100000

In AEM 6.3, i due parametri di cui sopra sono OOTB preconfigurati e possono essere mantenuti tramite OSGi QueryEngineSettings.

Ulteriori informazioni sono disponibili su: https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limits

Suggerimenti per la creazione di indici efficienti

È necessario creare un indice?

La prima domanda da porsi durante la creazione o l’ottimizzazione degli indici è se siano effettivamente necessari per una determinata situazione. Se la query in questione verrà eseguita una sola volta o solo occasionalmente e in un momento non di picco per il sistema tramite un processo batch, potrebbe essere preferibile non creare alcun indice.

Dopo aver creato un indice, ogni volta che i dati indicizzati vengono aggiornati, anche l’indice deve essere aggiornato. Poiché questo comporta implicazioni in termini di prestazioni per il sistema, gli indici devono essere creati solo quando sono effettivamente necessari.

Inoltre, gli indici sono utili solo se i dati contenuti nell’indice sono sufficientemente univoci da giustificarlo. Considera un indice in un libro e gli argomenti trattati. Quando si indicizza un set di argomenti in un testo, in genere sono presenti centinaia o migliaia di voci, che consentono di passare rapidamente a un sottoinsieme di pagine per trovare rapidamente le informazioni desiderate. Se quell'indice avesse solo due o tre voci, ognuna delle quali indicasse diverse centinaia di pagine, l'indice non sarebbe molto utile. Lo stesso concetto si applica agli indici di database. Se sono presenti solo due valori univoci, l’indice non sarà molto utile. Detto questo, un indice può anche diventare troppo grande per essere utile. Per esaminare le statistiche dell’indice, vedi Statistiche indice sopra.

Indici Lucene o di proprietà?

Gli indici Lucene sono stati introdotti in Oak 1.0.9 e offrono alcune potenti ottimizzazioni rispetto agli indici di proprietà introdotti nel lancio iniziale dell’AEM 6. Quando decidi se utilizzare gli indici Lucene o gli indici di proprietà, prendi in considerazione quanto segue:

• Gli indici Lucene offrono molte più funzioni degli indici di proprietà. Ad esempio, un indice delle proprietà può indicizzare solo una singola proprietà, mentre un indice Lucene può includere molte. Per ulteriori informazioni su tutte le funzioni disponibili negli indici Lucene, consulta la documentazione.
• Gli indici Lucene sono asincroni. Questo offre un notevole miglioramento delle prestazioni, ma può anche indurre un ritardo tra la scrittura dei dati nell’archivio e l’aggiornamento dell’indice. Se è fondamentale che le query restituiscano risultati accurati al 100%, è necessario un indice delle proprietà.
• Poiché sono asincroni, gli indici Lucene non possono applicare vincoli di univocità. Se necessario, è necessario impostare un indice delle proprietà.

In generale, si consiglia di utilizzare gli indici Lucene a meno che non vi sia la necessità urgente di utilizzare gli indici di proprietà in modo da poter beneficiare di prestazioni e flessibilità più elevate.

Indicizzazione Solr

Per impostazione predefinita, l’AEM supporta anche l’indicizzazione Solr. Questa viene utilizzata principalmente per supportare la ricerca full-text, ma può anche essere utilizzata per supportare qualsiasi tipo di query JCR. Solr deve essere preso in considerazione quando le istanze AEM non hanno la capacità della CPU per gestire il numero di query necessarie in implementazioni che richiedono un uso intensivo della ricerca, come i siti web basati sulla ricerca con un numero elevato di utenti simultanei. In alternativa, Solr può essere implementato in un approccio basato su crawler per sfruttare alcune delle funzioni più avanzate della piattaforma.

Gli indici Solr possono essere configurati per l’esecuzione incorporata sul server AEM per gli ambienti di sviluppo oppure possono essere scaricati su un’istanza remota per migliorare la scalabilità della ricerca negli ambienti di produzione e di staging. Anche se l'offload della ricerca migliorerà la scalabilità, introdurrà latenza e, per questo motivo, non è consigliato a meno che non sia necessario. Per ulteriori informazioni su come configurare l'integrazione Solr e creare indici Solr, vedere Documentazione su query e indicizzazione Oak.

L’inconveniente di questo approccio è che, anche se per impostazione predefinita, le query AEM rispetteranno gli ACL e quindi nasconderanno i risultati a cui un utente non ha accesso, l’esternalizzazione della ricerca a un server Solr non supporterà questa funzione. Se la ricerca deve essere esternalizzata in questo modo, è necessario prestare particolare attenzione affinché agli utenti non vengano presentati risultati che non dovrebbero vedere.

Potenziali casi d’uso in cui questo approccio può essere appropriato sono i casi in cui può essere necessario aggregare i dati di ricerca provenienti da più fonti. Ad esempio, puoi avere un sito ospitato sull’AEM e un secondo sito ospitato su una piattaforma di terze parti. Solr può essere configurato per eseguire la ricerca per indicizzazione del contenuto di entrambi i siti e memorizzarli in un indice aggregato. Questo consentirebbe ricerche intersito.

Considerazioni sulla progettazione

Nella documentazione Oak per gli indici Lucene sono elencate diverse considerazioni da tenere in considerazione durante la progettazione degli indici:

• Se la query utilizza restrizioni di percorso diverse, utilizza evaluatePathRestrictions. In questo modo la query restituirà il sottoinsieme di risultati nel percorso specificato e quindi li filtrerà in base alla query. In caso contrario, la query cercherà tutti i risultati che corrispondono ai parametri della query nell’archivio e quindi li filtrerà in base al percorso.

• Se la query utilizza l'ordinamento, impostare una definizione di proprietà esplicita per la proprietà ordinata e ordered a true per quello. In questo modo i risultati potranno essere ordinati come tali nell’indice e sarà possibile risparmiare su costose operazioni di ordinamento al momento dell’esecuzione della query.

• Inserisci solo il necessario nell’indice. L’aggiunta di funzioni o proprietà non necessarie causerà la crescita dell’indice e rallenterà le prestazioni.

• In un indice delle proprietà, l’utilizzo di un nome di proprietà univoco aiuterebbe a ridurre le dimensioni di un indice, ma per gli indici Lucene l’utilizzo di nodeTypes e mixins Per ottenere indici coesivi. Query di uno specifico nodeType o mixin sarà più performante rispetto alla query nt:base. Quando si utilizza questo approccio, definire indexRules per nodeTypes in questione.

• Se le query vengono eseguite solo in determinati percorsi, crea tali indici in tali percorsi. Non è necessario che gli indici risiedano nella directory principale dell’archivio.

• Si consiglia di utilizzare un singolo indice quando tutte le proprietà in fase di indicizzazione sono correlate in modo da consentire a Lucene di valutare il maggior numero possibile di restrizioni delle proprietà in modo nativo. Inoltre, una query utilizzerà un solo indice, anche quando si esegue un join.

CopyOnRead

Nei casi in cui NodeStore è memorizzato in remoto, un'opzione denominata CopyOnRead possono essere abilitati. L'opzione consente di scrivere l'indice remoto nel file system locale quando viene letto. Questo può aiutare a migliorare le prestazioni per le query che vengono spesso eseguite su questi indici remoti.

Questo può essere configurato nella console OSGi in LuceneIndexProvider ed è abilitato per impostazione predefinita a partire da Oak 1.0.13.

Rimozione degli indici

Quando si rimuove un indice, si consiglia sempre di disattivarlo temporaneamente impostando il type proprietà a disabled ed esegui dei test per garantire il corretto funzionamento dell’applicazione prima di eliminarla effettivamente. Tieni presente che un indice non viene aggiornato se disabilitato, pertanto potrebbe non avere il contenuto corretto se viene riabilitato e potrebbe dover essere reindicizzato.

Dopo aver rimosso un indice di proprietà in un'istanza TarMK, sarà necessario eseguire la compattazione per recuperare lo spazio su disco in uso. Per gli indici Lucene, il contenuto effettivo dell’indice si trova nel BlobStore, pertanto sarebbe necessaria una raccolta di oggetti inattivi dell’archivio dati.

Quando si rimuove un indice in un’istanza MongoDB, il costo dell’eliminazione è proporzionale al numero di nodi nell’indice. Poiché l’eliminazione di un indice di grandi dimensioni può causare problemi, l’approccio consigliato consiste nel disattivare l’indice e eliminarlo solo durante una finestra di manutenzione, utilizzando uno strumento come oak-mongo.js. Tieni presente che questo approccio non dovrebbe essere utilizzato per il contenuto dei nodi regolari, in quanto può introdurre incongruenze nei dati.

Scheda di riferimento rapido per le query JCR

Per supportare la creazione di query JCR e le definizioni degli indici efficienti, la Scheda di riferimento rapido per le query JCR è disponibile per il download e l’utilizzo come riferimento durante lo sviluppo. Contiene query di esempio per QueryBuilder, XPath e SQL-2, che coprono più scenari che si comportano in modo diverso in termini di prestazioni delle query. Fornisce inoltre consigli su come creare o personalizzare gli indici Oak. Il contenuto di questa Scheda di riferimento rapido si applica a AEM 6.5 e AEM as a Cloud Service.

Reindicizzazione

Questa sezione illustra solo motivi accettabili per reindicizzare gli indici Oak.

Al di fuori dei motivi descritti di seguito, l’avvio della reindicizzazione degli indici Oak non modificare il comportamento o risolvere i problemi e aumentare inutilmente il carico di lavoro sull’AEM.

La reindicizzazione degli indici Oak deve essere evitata a meno che non sia coperta da un motivo nelle tabelle seguenti.

Modifiche alla configurazione dell’indice Oak

L’unica condizione non errata accettabile per la reindicizzazione degli indici Oak è che la configurazione di un indice Oak sia cambiata.

La reindicizzazione deve sempre essere affrontata tenendo in debita considerazione il suo impatto sulle prestazioni complessive dell’AEM ed eseguita durante i periodi di bassa attività o le finestre di manutenzione.

Di seguito sono riportati i possibili problemi relativi alle risoluzioni:

• Modifica definizione indice proprietà
• Modifica definizione indice Lucene

Modifica definizione indice proprietà

• Si applica per/se:

  • Tutte le versioni Oak
  • Solo indici di proprietà

• Sintomi:

  • Nodi esistenti prima dell’aggiornamento della definizione dell’indice delle proprietà mancanti nei risultati

• Come verificare:

  • Determina se i nodi mancanti sono stati creati/modificati prima della distribuzione della definizione di indice aggiornata.
  • Verificare la jcr:created o jcr:lastModified proprietà di eventuali nodi mancanti rispetto all’ora di modifica dell’indice

• Come risolvere:

  • Reindicizza l’indice di lucene

  • In alternativa, toccare (eseguire un’operazione di scrittura benigna) i nodi mancanti

    • Richiede contatti manuali o codice personalizzato
    • Richiede che il set di nodi mancanti sia noto
    • Richiede la modifica di qualsiasi proprietà sul nodo

Modifica definizione indice Lucene

• Si applica per/se:

  • Tutte le versioni Oak
  • Solo indici lucene

• Sintomi:

  • L’indice Lucene non contiene i risultati previsti
  • I risultati della query non riflettono il comportamento previsto della definizione dell’indice
  • Il piano di query non segnala l’output previsto in base alla definizione dell’indice

• Come verificare:

  • Verificare che la definizione dell'indice sia stata modificata utilizzando il metodo JMX Mbean (LuceneIndex) delle statistiche dell'indice di Lucene diffStoredIndexDefinition.

• Come risolvere:

  • Versioni Oak precedenti alla versione 1.6:

    • Reindicizza l’indice di lucene

  • Oak versioni 1.6+

    • Se il contenuto esistente non è influenzato dalle modifiche, è necessario solo un aggiornamento

      • Aggiorna l'indice lucene impostando [oak:queryIndexDefinition]@refresh=true

    • Altrimenti, reindicizzare l’indice di lucene

      • Nota: lo stato dell’indice dall’ultima reindicizzazione valida (o indicizzazione iniziale) verrà utilizzato fino a quando non viene attivata una nuova reindicizzazione

Errori e situazioni eccezionali

La tabella seguente descrive l’unico errore accettabile e le situazioni eccezionali in cui la reindicizzazione degli indici Oak risolverà il problema.

Se si verifica un problema relativo all’AEM che non soddisfa i criteri descritti di seguito, non reindicizza eventuali indici, poiché non risolverà il problema.

Di seguito sono riportati i possibili problemi relativi alle risoluzioni:

• Manca il binario dell'indice Lucene
• Il file binario dell'indice di Lucene è danneggiato

Manca il binario dell'indice Lucene

• Si applica per/se:

  • Tutte le versioni Oak
  • Solo indici lucene

• Sintomi:

  • L’indice Lucene non contiene i risultati previsti

• Come verificare:

  • Il file di log degli errori contiene un'eccezione che indica che manca un binario dell'indice Lucene

• Come risolvere:

  • Eseguire una verifica dell’archivio di attraversamento, ad esempio:

    http://localhost:4502/system/console/repositorycheck

    l’attraversamento dell’archivio determina se mancano altri file binari (oltre ai file lucene)

  • Se mancano dati binari diversi dagli indici Lucene, eseguire il ripristino dal backup

  • Altrimenti, reindicizzare tutto indici lucene

  • Nota:

    Questa condizione è indicativa di un datastore configurato in modo errato che può causare ANY binary (ad esempio assets binari) per andare perduti.

    In questo caso, ripristina l’ultima versione valida nota dell’archivio per recuperare tutti i file binari mancanti.

Il file binario dell'indice di Lucene è danneggiato

• Si applica per/se:

  • Tutte le versioni Oak
  • Solo indici lucene

• Sintomi:

  • L’indice Lucene non contiene i risultati previsti

• Come verificare:

  • Il AsyncIndexUpdate (ogni 5 secondi) avrà esito negativo con un’eccezione nel registro degli errori:

    ...a Lucene index file is corrupt...

• Come risolvere:

  • Rimuovi la copia locale dell’indice Lucene

    1. Interrompere l’AEM
    2. Elimina la copia locale dell’indice Lucene in crx-quickstart/repository/index
    3. Riavvia AEM

  • Se questo non risolve il problema, e AsyncIndexUpdate le eccezioni persistono:

    1. Reindicizza l'indice di errore
    2. File anche Supporto Adobe ticket

Reindicizzare

Reindicizzazione degli indici delle proprietà

• Utilizzare oak-run.jar per reindicizzare l'indice delle proprietà

• Impostare la proprietà async-reindex su true nell'indice della proprietà

  • [oak:queryIndexDefinition]@reindex-async=true

• Reindicizza l’indice delle proprietà in modo asincrono utilizzando la console web tramite PropertyIndexAsyncReindex MBean;

  ad esempio,

  http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Dasync%2Ctype%3DPropertyIndexAsyncReindex

Reindicizzazione degli indici della proprietà Lucene

• Utilizzare oak-run.jar per reindicizzare l'indice della proprietà Lucene.

• Impostare la proprietà async-reindex su true nell'indice della proprietà Lucene

  • [oak:queryIndexDefinition]@reindex-async=true

Pre-estrazione del testo dei dati binari

La pre-estrazione del testo è il processo di estrazione ed elaborazione del testo dai dati binari, direttamente dall’archivio dati tramite un processo isolato ed esponendo direttamente il testo estratto a successive re/indicizzazioni degli indici Oak.

• La pre-estrazione del testo Oak è consigliata per la re/indicizzazione degli indici Lucene negli archivi con grandi volumi di file (binari) che contengono testo estraibile (ad esempio PDF, documenti Word, PPT, TXT, ecc.) che sono idonee per la ricerca full-text tramite indici Oak distribuiti; ad esempio /oak:index/damAssetLucene.
• La pre-estrazione del testo è utile solo per la re/indicizzazione degli indici Lucene e NON degli indici di proprietà Oak, poiché gli indici di proprietà non estraggono il testo dai binari.
• La pre-estrazione del testo ha un forte impatto positivo quando la reindicizzazione full-text di file binari contenenti molto testo (PDF, Doc, TXT, ecc.), dove come archivio di immagini non godrà delle stesse efficienze dal momento che le immagini non contengono testo estraibile.
• La pre-estrazione del testo esegue l’estrazione del testo completo relativo alla ricerca in modo molto efficiente e lo espone al processo di re/indicizzazione Oak in modo molto efficiente.

Quando può essere utilizzata la pre-estrazione del testo?

Reindicizzazione di un esistente indice lucene con estrazione binaria abilitata

• Reindicizzazione dell’elaborazione tutto contenuto candidato nell’archivio; quando i dati binari da cui estrarre il testo completo sono numerosi o complessi, l’AEM è soggetto a un onere di calcolo maggiore per eseguire l’estrazione del testo completo. La pre-estrazione del testo sposta il "lavoro computazionalmente costoso" dell’estrazione del testo in un processo isolato che accede direttamente all’archivio dati dell’AEM, evitando il sovraccarico e il conflitto di risorse nell’AEM.

Sostenere l'implementazione di un nuovo indice Lucene per AEM con estrazione binaria abilitata

• Quando un nuovo indice (con estrazione binaria abilitata) viene distribuito in AEM, Oak indicizza automaticamente tutto il contenuto candidato alla successiva esecuzione dell’indice full-text asincrono. Per le stesse ragioni descritte nella reindicizzazione di cui sopra, ciò potrebbe comportare un carico eccessivo sull’AEM.

Quando NON è possibile utilizzare la pre-estrazione del testo?

La pre-estrazione del testo non può essere utilizzata per i nuovi contenuti aggiunti all’archivio, né è necessaria.

Il nuovo contenuto aggiunto all’archivio viene indicizzato naturalmente e in modo incrementale dal processo di indicizzazione full-text asincrono (per impostazione predefinita, ogni 5 secondi).

In caso di normale funzionamento dell’AEM, ad esempio per il caricamento di risorse tramite l’interfaccia web o l’acquisizione programmatica di risorse, l’AEM indicizzerà in modo automatico e incrementale il nuovo contenuto binario. Poiché la quantità di dati è incrementale e relativamente piccola (approssimativamente la quantità di dati che può essere mantenuta nell’archivio in 5 secondi), l’AEM può eseguire l’estrazione full-text dai dati binari durante l’indicizzazione senza influire sulle prestazioni complessive del sistema.

Prerequisiti per l’utilizzo della pre-estrazione del testo

• Reindicizzazione di un indice Lucene che esegue l'estrazione binaria full-text o distribuzione di un nuovo indice che indicizzerà i file binari full-text del contenuto esistente

• Il contenuto (binari) da cui estrarre il testo in anteprima deve trovarsi nell’archivio

• Una finestra di manutenzione per generare il file CSV E per eseguire la reindicizzazione finale

• Oak versione: 1.0.18+, 1.2.3+

• oak-run.jarversione 1.7.4+

• Una cartella/condivisione del file system per memorizzare il testo estratto accessibile dalle istanze AEM di indicizzazione

  • La configurazione OSGi di pre-estrazione del testo richiede un percorso del file system per i file di testo estratti, quindi devono essere accessibili direttamente dall’istanza AEM (unità locale o montaggio con condivisione file)

Come eseguire la pre-estrazione del testo

Genera elenco di contenuti da pre-estrarre

Eseguire il passaggio 1 (a-b) durante un intervallo di manutenzione/periodo di basso utilizzo mentre l'archivio nodi viene attraversato durante questa operazione, che può causare un carico significativo sul sistema.

1a. Esegui oak-run.jar --generate per creare un elenco di nodi in cui verrà preestratto il testo.

1b. L'elenco dei nodi (1a) viene archiviato nel file system come file CSV

L’intero archivio nodi viene attraversato ogni volta (come specificato dai percorsi nel comando oak-run ) --generate viene eseguito, e nuovo Viene creato il file CSV. Il file CSV è non riutilizzato tra esecuzioni discrete del processo di pre-estrazione del testo (passaggi 1-2).

Pre-estrarre il testo nel file system

La fase 2(a-c) può essere eseguita durante il normale funzionamento dell’AEM se interagisce solo con l’archivio dati.

2a. Esegui oak-run.jar --tika per preestrarre il testo per i nodi binari enumerati nel file CSV generato in (1b)

2b. Il processo avviato in (2a) accede direttamente ai nodi binari definiti nel file CSV in Data Store ed estrae il testo.

2 quater. Il testo estratto viene memorizzato nel file system in un formato che può essere acquisito dal processo di reindicizzazione Oak (3a)

Il testo pre-estratto viene identificato nel file CSV dall’impronta digitale binaria. Se il file binario è lo stesso, è possibile utilizzare lo stesso testo pre-estratto in tutte le istanze AEM. Poiché AEM Publish è in genere un sottoinsieme di AEM Author, il testo pre-estratto da AEM Author può spesso essere utilizzato anche per reindicizzare AEM Publish (supponendo che AEM Publish abbia accesso ai file di testo estratti nel file system).

Il testo pre-estratto può essere aggiunto in modo incrementale a nel tempo. La pre-estrazione del testo salta l’estrazione per i file binari estratti in precedenza, pertanto è consigliabile mantenere il testo pre-estratto nel caso in cui la reindicizzazione debba avvenire nuovamente in futuro (supponendo che il contenuto estratto non sia eccessivamente grande. In caso affermativo, valutare la compressione del contenuto nel frattempo, poiché il testo viene compresso correttamente.

Reindicizza indici Oak, ricerca full-text da file di testo estratto

Esegui la reindicizzazione (passaggi 3a-b) durante un periodo di manutenzione/basso utilizzo mentre l’archivio nodi viene attraversato durante questa operazione, che può causare un carico significativo sul sistema.

3a. Reindicizza degli indici Lucene viene richiamato nell’AEM

3b. La configurazione OSGi di Apache Jackrabbit Oak DataStore PreExtractedTextProvider (configurata per puntare al testo estratto tramite un percorso del file system) indica a Oak il testo full-text di origine dai file estratti ed evita di colpire ed elaborare direttamente i dati memorizzati nell’archivio.

Risorse Business.Adobe.com

Personalized Experiences Personalized Communications Theme Editor Document Generation Web Content Management Digital Signage