Best practice per query e indicizzazione

Oltre alla transizione a Oak nel AEM 6, sono state apportate alcune modifiche importanti alla gestione di query e 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 il nodo oak:index. Una query può essere eseguita senza un indice, ma per i set di dati di grandi dimensioni sarà eseguita molto lentamente o persino in modo interrotto.

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

Inoltre, leggere la documentazione Oak per la scrittura di query e indici. Oltre al fatto che gli indici sono un nuovo concetto nella AEM 6, vi sono differenze sintattiche nelle query Oak che devono essere prese in considerazione durante la migrazione del codice da un'installazione AEM precedente.

Quando utilizzare le query

Struttura del repository e della tassonomia

Durante la progettazione della tassonomia di un repository, occorre tenere conto di diversi fattori. Tra questi, controlli di accesso, localizzazione, ereditarietà di componenti e proprietà di pagina.

Durante la progettazione di una tassonomia che risponda a questi problemi, è importante considerare anche la "traversabilità" del design di indicizzazione. In questo contesto, la traversabilità è la capacità di una tassonomia che consente l'accesso prevedibile al contenuto in base al suo percorso. Questo renderà un sistema più performante che è più facile da mantenere di uno che richiederà un sacco di query da eseguire.

Inoltre, durante la progettazione di una tassonomia, è importante considerare se l'ordine è importante. Nei casi in cui l'ordine esplicito non è richiesto 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'ordine, nt:unstructured e sling:OrderedFolder sarebbero più appropriati.

Query nei componenti

Poiché le query possono essere una delle operazioni di rassettamento più eseguite su un sistema AEM, è consigliabile evitarle nei componenti. L'esecuzione di diverse query ogni volta che viene eseguito il rendering di una pagina può spesso compromettere le prestazioni del sistema. Esistono due strategie che possono essere utilizzate per evitare di eseguire query durante il rendering dei componenti: nodi di attraversamento e risultati di preacquisizione.

Nodi di navigazione

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

Un esempio potrebbe essere rappresentato dal rendering del contenuto che si adatta a una determinata categoria. Un approccio consiste nell’organizzare il contenuto con una proprietà category che può essere richiesta per compilare un componente che mostra gli elementi in una categoria.

Un approccio migliore consisterebbe nel strutturare il contenuto in una tassonomia per categoria in modo che possa essere recuperato manualmente.

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

/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

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

Inoltre, quando si tratta di un set di risultati piccolo o omogeneo, può essere più veloce attraversare la directory archivio e raccogliere i nodi richiesti, anziché creare una query per restituire lo stesso set di risultati. In linea generale, occorre evitare le interrogazioni laddove possibile.

Preacquisizione dei risultati

A volte il contenuto o i requisiti intorno al componente non consentiranno l'uso del passaggio dei nodi come metodo per recuperare i dati richiesti. In questi casi, le query necessarie devono essere eseguite prima del rendering del componente in modo da garantire prestazioni ottimali all’utente finale.

Se i risultati richiesti per il componente possono essere calcolati al momento della creazione e non è previsto che il contenuto venga modificato, 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 su una programmazione o tramite un listener per gli aggiornamenti dei dati sottostanti. Quindi, i risultati possono essere scritti in una posizione condivisa nella directory archivio. Tutti i componenti che necessitano di questi dati possono quindi estrarre i valori da questo singolo nodo senza dover eseguire una query in fase di esecuzione.

Ottimizzazione query

Durante l'esecuzione di una query che non utilizza un indice, gli avvisi vengono registrati per quanto riguarda l'attraversamento dei nodi. Se si tratta di una query che verrà eseguita spesso, è necessario creare un indice. Per determinare l'indice utilizzato da una determinata query, si consiglia di utilizzare lo strumento Spiega query. Per ulteriori informazioni, la registrazione DEBUG può essere abilitata per le API di ricerca pertinenti.

Quando si eseguono query complesse, possono verificarsi casi in cui la suddivisione della query in più query più piccole e l'unione dei dati attraverso il codice dopo che il fatto è più performante. La raccomandazione per questi casi è di confrontare le prestazioni dei due approcci per determinare quale opzione sarebbe migliore per il caso d'uso in questione.

AEM è possibile scrivere query in uno dei tre modi seguenti:

• Tramite le API QueryBuilder (consigliato)
• Utilizzo di XPath (consigliato)
• Utilizzo di SQL2

Mentre tutte le query vengono convertite in SQL2 prima di essere eseguite, il sovraccarico della conversione delle query è minimo e, quindi, la maggiore preoccupazione nella scelta di un linguaggio di query sarà la leggibilità e il livello di comfort dal team di sviluppo.

Strumento Spiega query

Come per qualsiasi lingua di query, il primo passo per ottimizzare una query è capire come verrà eseguita. Per abilitare questa attività, potete utilizzare lo strumento Query di spiegazione che fa parte del Pannello operazioni. Con questo strumento, è possibile collegare e spiegare una query. Viene visualizzato un avviso se la query causerà problemi con un archivio di grandi dimensioni, oltre al tempo di esecuzione e agli indici che verranno utilizzati. Lo strumento può anche caricare un elenco di query lente e popolari che possono essere spiegate e ottimizzate.

Registrazione DEBUG per query

Per ottenere ulteriori informazioni su come Oak sta scegliendo l'indice da utilizzare e come il motore di query sta effettivamente eseguendo una query, è possibile aggiungere una configurazione di registrazione DEBUG per i pacchetti seguenti:

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

Assicuratevi di rimuovere questo logger quando avete finito di debugging della query in quanto produrrà un sacco di attività e può eventualmente riempire il disco con i file di registro.

Per ulteriori informazioni su come eseguire questa operazione, consultare la Documentazione di registrazione.

Statistiche indice

Lucene registra un file JMX che fornisce informazioni dettagliate sui contenuti indicizzati, 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

Una volta effettuato l'accesso alla console JMX, eseguire una ricerca per Statistiche indice Lucene per individuarla. Altre statistiche sull'indice sono disponibili in IndexStats MBean.

Per le statistiche delle query, consultare l'MBean denominato Statistiche query Oak.

Se desiderate approfondire gli indici utilizzando uno strumento come Luke, dovrete utilizzare la console Oak per scaricare l'indice da NodeStore a una directory del file system. Per istruzioni su come eseguire questa operazione, leggere la documentazione di Lucene.

Potete anche estrarre gli indici nel sistema in formato JSON. A tal fine, è necessario accedere a https://server:port/oak:index.tidy.-1.json

Limiti per le query

Durante lo sviluppo

Impostare soglie basse per oak.queryLimitInMemory (ad esempio 10000) e quercia. queryLimitReads (ad esempio 5000) e ottimizzare la query costosa quando si tocca un UnsupportedOperationException che dice "La query ha letto più di x nodi…"

In questo modo si evitano le query che richiedono molte risorse (ad es. non sostenuto da alcun indice o sostenuto da un indice di copertura inferiore). Ad esempio, una query che legge 1 milione di nodi comporterebbe 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

• Monitorare i registri per le query che attivano il consumo di memoria heap di grandi nodi: "

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

• Monitorare i registri per le query che attivano un grande consumo 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
  • Ottimizzare la query per ridurre il consumo di memoria heap

Per le versioni AEM 6.0 - 6.2, è possibile ottimizzare la soglia per l'attraversamento dei nodi tramite i parametri JVM nello script di avvio AEM per evitare che le query di grandi dimensioni sovraccarichino l'ambiente.

I valori consigliati sono:

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

In AEM 6.3, i due parametri indicati sopra sono OOTB preconfigurati e possono essere memorizzati tramite OSGi QueryEngineSettings.

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

Suggerimenti per la creazione di indici efficienti

Devo creare un indice?

La prima domanda da porre al momento della creazione o dell’ottimizzazione degli indici è se questi siano effettivamente necessari per una determinata situazione. Se si desidera eseguire la query in questione solo una volta o solo occasionalmente e in un momento di picco per il sistema attraverso un processo batch, potrebbe essere meglio non creare alcun indice.

Dopo aver creato un indice, ogni volta che i dati indicizzati vengono aggiornati, è necessario aggiornare anche l'indice. Poiché questo comporta implicazioni in termini di prestazioni per il sistema, gli indici dovrebbero essere creati solo quando sono effettivamente richiesti.

Inoltre, gli indici sono utili solo se i dati contenuti all'interno dell'indice sono abbastanza univoci da giustificarlo. Considerate un indice in un libro e gli argomenti trattati. Quando si indicizza un insieme di argomenti in un testo, in genere sono presenti centinaia o migliaia di voci, il che consente di passare rapidamente a un sottoinsieme di pagine per trovare rapidamente le informazioni che si stanno cercando. Se l'indice contenesse solo due o tre voci, ognuna delle quali indicava diverse centinaia di pagine, l'indice non sarebbe molto utile. Lo stesso concetto si applica agli indici di database. Se ci sono solo due valori univoci, l'indice non sarà molto utile. Detto questo, un indice può anche diventare troppo grande per essere utile. Per consultare le statistiche sull'indice, vedere Statistiche sull'indice sopra.

Lucene o indici di proprietà?

Gli indici di Lucene sono stati introdotti in Oak 1.0.9 e offrono alcune potenti ottimizzazioni sugli indici di proprietà che sono stati introdotti nel lancio iniziale di AEM 6. Nel decidere se utilizzare gli indici Lucene o gli indici di proprietà, tenere presente quanto segue:

• Gli indici di Lucene offrono molte più funzionalità degli indici di proprietà. Ad esempio, un indice di proprietà può indicizzare solo una singola proprietà, mentre un indice Lucene può includere molti. Per ulteriori informazioni su tutte le funzioni disponibili negli indici Lucene, consulta la documentazione.
• Gli indici di Lucene sono asincrono. Questo offre un notevole miglioramento delle prestazioni, ma può anche causare un ritardo tra il momento in cui i dati vengono scritti nell'archivio e il momento in cui l'indice viene aggiornato. Se è fondamentale che le query restituiscano risultati accurati al 100%, è necessario un indice di proprietà.
• In quanto asincrone, gli indici Lucene non possono applicare vincoli di univocità. Se necessario, sarà necessario creare un indice di proprietà.

In generale, si consiglia di utilizzare indici Lucene a meno che non vi sia un'urgente necessità di utilizzare indici di proprietà in modo da poter ottenere i vantaggi di prestazioni e flessibilità più elevate.

Indicizzazione Solr

AEM supporta anche l'indicizzazione Solr per impostazione predefinita. Questa funzione è principalmente utilizzata per supportare la ricerca full text, ma può essere utilizzata anche per supportare qualsiasi tipo di query JCR. Solr deve essere considerato quando le istanze AEM non dispongono della capacità CPU per gestire il numero di query necessarie nelle distribuzioni che richiedono molta 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 caratteristiche più avanzate della piattaforma.

Gli indici solr possono essere configurati per l'esecuzione incorporati nel server AEM per gli ambienti di sviluppo oppure per essere scaricati in un'istanza remota per migliorare la scalabilità della ricerca negli ambienti di produzione e di gestione temporanea. Mentre l'offload della ricerca migliorerà la scalabilità, introdurrà latenza e per questo motivo, non è consigliato a meno che non richiesto. Per ulteriori informazioni su come configurare l'integrazione Solr e come creare indici Solr, consultare la Documentazione sulle query Oak e sull'indicizzazione.

Il lato negativo di questo approccio è che, mentre per impostazione predefinita, AEM query rispetteranno gli ACL e quindi nasconderanno i risultati a cui un utente non ha accesso, esternalizzando la ricerca a un server Solr non supporterà questa funzionalità. Se la ricerca deve essere esternalizzata in questo modo, occorre prestare maggiore attenzione al fatto che gli utenti non ricevano risultati che non dovrebbero vedere.

I casi d’uso potenziali in cui questo approccio può essere appropriato sono i casi in cui i dati di ricerca provenienti da più fonti possono dover essere aggregati. Ad esempio, potete avere un sito ospitato su AEM e un secondo sito ospitato su una piattaforma di terze parti. È possibile configurare Solr per eseguire una ricerca per indicizzazione del contenuto di entrambi i siti e memorizzarlo in un indice aggregato. Ciò consentirebbe ricerche tra più siti.

Considerazioni sulla progettazione

La documentazione Oak per gli indici Lucene elenca diverse considerazioni da fare durante la progettazione degli indici:

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

• Se la query utilizza l'ordinamento, avere una definizione esplicita della proprietà ordinata e impostare ordered su true per essa. Ciò consentirà di ordinare i risultati come tali nell'indice e di risparmiare sulle operazioni di ordinamento costose al momento dell'esecuzione della query.

• Inserire solo ciò che è necessario nell'indice. L'aggiunta di funzioni o proprietà non necessarie causerà un aumento e una riduzione delle prestazioni dell'indice.

• In un indice di proprietà, avere un nome di proprietà univoco contribuirebbe a ridurre le dimensioni di un indice, ma per gli indici Lucene, è necessario utilizzare nodeTypes e mixins per ottenere indici coesivi. La query di un nodeType o mixin specifico sarà più efficace rispetto alla query di nt:base. Quando si utilizza questo approccio, definire indexRules per la nodeTypes in questione.

• Se le query vengono eseguite solo in determinati percorsi, creare tali indici sotto tali percorsi. Gli indici non sono necessari per vivere nella directory principale del repository.

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

CopyOnRead

Se il file NodeStore è memorizzato in remoto, è possibile abilitare un'opzione denominata CopyOnRead. L'opzione causerà la scrittura dell'indice remoto nel file system locale durante la lettura. Ciò può contribuire a migliorare le prestazioni delle query che vengono spesso eseguite in base a questi indici remoti.

Questo può essere configurato nella console OSGi sotto il servizio LuceneIndexProvider ed è attivato per impostazione predefinita a partire da Oak 1.0.13.

Rimozione degli indici

Quando si rimuove un indice, è sempre consigliabile disattivare temporaneamente l'indice impostando la proprietà type su disabled ed eseguire delle verifiche per garantire che l'applicazione funzioni correttamente prima di eliminarla. Tenete presente che un indice non viene aggiornato mentre è disabilitato, pertanto potrebbe non avere il contenuto corretto se viene riabilitato e potrebbe essere necessario reindicizzarlo.

Dopo aver rimosso un indice di proprietà in un'istanza TarMK, sarà necessario eseguire compaction per recuperare lo spazio su disco in uso. Per gli indici Lucene, il contenuto effettivo dell'indice risiede in BlobStore, pertanto sarebbe necessario un processo di raccolta dei rifiuti per l'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, si consiglia di disattivare l'indice ed eliminarlo solo durante una finestra di manutenzione, utilizzando uno strumento come oak-mongo.js. Nota: questo approccio non deve essere utilizzato per il contenuto dei nodi regolari, in quanto può introdurre incoerenze nei dati.

Reindicizzazione

In questa sezione vengono illustrati i motivi accettabili per reindicizzare gli indici Oak only.

Al di fuori dei motivi indicati di seguito, l'avvio di reindici degli indici Oak non modificherà il comportamento o risolverà i problemi, e aumenterà inutilmente il carico su AEM.

È opportuno evitare di reindicizzare gli indici Oak se non per motivi esposti nelle tabelle di seguito.

Modifiche alla configurazione dell'indice Oak

L’unica condizione accettabile di non-erring per reindicizzare gli indici Oak è se la configurazione di un indice Oak è cambiata.

La reindicizzazione deve sempre essere affrontata con la dovuta considerazione per il suo impatto sulle prestazioni complessive AEM, ed eseguita durante i periodi di attività o finestre di manutenzione ridotte.

I seguenti dettagli possono essere presentati insieme alle risoluzioni:

• Modifica definizione indice proprietà
• Modifica definizione indice Lucene

Modifica definizione indice proprietà

• Si applica per/if:

  • Tutte le versioni di Oak
  • Solo indici di proprietà

• Sintomi:

  • Nodi esistenti prima dell'aggiornamento della definizione dell'indice delle proprietà mancanti dai risultati

• Come verificare:

  • Determinare se i nodi mancanti sono stati creati/modificati prima della distribuzione della definizione di indice aggiornata.
  • Verificare le proprietà jcr:created o jcr:lastModified di eventuali nodi mancanti in base al tempo di modifica dell'indice

• Come risolvere:

  • Indice di lucene di nuovo indicizzato

  • In alternativa, toccate (eseguite un'operazione di scrittura benigna) i nodi mancanti

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

Modifica definizione indice Lucene

• Si applica per/if:

  • Tutte le versioni di Oak
  • Solo indici di lucene

• Sintomi:

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

• Come verificare:

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

• Come risolvere:

  • Versioni di quercia precedenti alla 1.6:

    • Indice di lucene di nuovo indicizzato

  • Oak versione 1.6+

    • Se il contenuto esistente non viene influenzato dalle modifiche, è necessario solo aggiornare

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

    • Altrimenti, reindicizzare l'indice di lucene

      • Nota: Lo stato dell'indice dall'ultimo corretto reindicizzazione (o indicizzazione iniziale) viene utilizzato fino all'attivazione di un nuovo reindicizzazione

Situazioni di errore ed eccezionali

Nella tabella seguente sono illustrate le uniche situazioni di errore ed eccezione accettabili in cui la reindicizzazione degli indici Oak risolverà il problema.

Se si verifica un problema in AEM che non soddisfa i criteri indicati di seguito, eseguire il reindicizzazione di eventuali indici not, in quanto non risolverà il problema.

I seguenti dettagli possono essere presentati insieme alle risoluzioni:

• Valore binario dell'indice Lucene mancante
• Il binario dell'indice di Lucene è danneggiato

Valore binario dell'indice Lucene mancante

• Si applica per/if:

  • Tutte le versioni di Oak
  • Solo indici di lucene

• Sintomi:

  • L'indice di Lucene non contiene i risultati previsti

• Come verificare:

  • Il file di registro degli errori contiene un'eccezione che indica la mancanza di un binario dell'indice Lucene

• Come risolvere:

  • eseguire un controllo del repository di attraversamento; ad esempio:

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

    l'attraversamento del repository determina se mancano altri file binari (oltre ai file lucene)

  • Se mancano file binari diversi dagli indici di lucene, eseguire il ripristino dal backup

  • In caso contrario, reindicizzare all indici di lucene

  • Nota:

    Questa condizione è indicativa di un datastore configurato in modo errato che potrebbe generare QUALSIASI binario (ad esempio asset (file binari) da perdere.

    In questo caso, ripristinare l'ultima versione buona nota del repository per recuperare tutti i binari mancanti.

Il binario dell'indice Lucene è danneggiato

• Si applica per/if:

  • Tutte le versioni di Oak
  • Solo indici di lucene

• Sintomi:

  • L'indice di Lucene non contiene i risultati previsti

• Come verificare:

  • Il AsyncIndexUpdate (ogni 5s) avrà esito negativo con un'eccezione nel log error.log:

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

• Come risolvere:

  • Rimuovere la copia locale dell'indice lucene

    1. Interrompi AEM
    2. Elimina la copia locale dell'indice di lucene in crx-quickstart/repository/index
    3. Riavvia AEM

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

    1. Indice di indicizzazione dell'errore
    2. Anche file di un biglietto supporto Adobe

Come reindicizzare

Indice delle proprietà di reindicizzazione

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

• Impostare la proprietà asincrona-reindex su true nell'indice delle proprietà

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

• Reindicizzare 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

Riindicizzazione indici delle proprietà Lucene

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

• Impostate la proprietà asincrona-reindex su true nell'indice delle proprietà lucene

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

Pre-estrazione del testo dei binari

La preestrazione del testo è il processo di estrazione ed elaborazione del testo dai file binari, direttamente dall'archivio dati attraverso un processo isolato, e di esposizione diretta del testo estratto ai successivi re/indici degli indici Oak.

• La preestrazione del testo in quercia è consigliata per reindicizzare gli indici Lucene nei repository con grandi volumi di file (file binari) che contengono testo estraibile (ad esempio PDF, documenti Word, PPT, TXT ecc.) idonei alla ricerca full-text tramite indici Oak distribuiti; ad esempio /oak:index/damAssetLucene.
• La preestrazione del testo avvantaggia solo la reindicizzazione degli indici Lucene e degli indici delle proprietà NOT Oak, poiché gli indici delle proprietà non estraggono testo dai binari.
• La preestrazione del testo ha un impatto positivo elevato quando l’indicizzazione full-text dei file binari con testo pesante (PDF, Doc, TXT, ecc.), dove come archivio di immagini non avrà le stesse efficienze, poiché le immagini non contengono testo estraibile.
• La preestrazione del testo esegue l’estrazione del testo di ricerca full-text in modo estremamente efficiente e lo espone al processo di re/indicizzazione Oak in modo estremamente efficiente da utilizzare.

Quando è possibile utilizzare la preestrazione del testo?

Riindicizzazione di un indice lucene esistente con estrazione binaria abilitata

• reindicizzazione del contenuto candidato all'elaborazione all nel repository; quando i binari da cui estrarre il testo completo sono numerosi o complessi, un maggiore carico di calcolo per eseguire l’estrazione full-text viene AEM. La preestrazione del testo sposta il "lavoro computazionale" dell'estrazione del testo in un processo isolato che accede direttamente AEM Data Store, evitando sovraccarichi e contese delle risorse in AEM.

Supporto della distribuzione di un nuovo indice di lucene per AEM con l'estrazione binaria abilitata

• Quando un nuovo indice (con l'estrazione binaria abilitata) viene distribuito in AEM, Oak indicizza automaticamente tutto il contenuto candidato alla successiva esecuzione asincrona dell'indice full-text. Per gli stessi motivi descritti nella reindicizzazione precedente, ciò può comportare un carico eccessivo su AEM.

Quando è possibile utilizzare la preestrazione del testo NOT?

La preestrazione del testo non può essere utilizzata per i nuovi contenuti aggiunti alla directory archivio, né per quelli necessari.

Il nuovo contenuto viene aggiunto alla directory archivio in modo naturale e incrementale mediante il processo di indicizzazione full-text asincrono (per impostazione predefinita, ogni 5 secondi).

Con il normale funzionamento di AEM, ad esempio il caricamento di risorse tramite l’interfaccia utente Web o l’assimilazione programmatica di risorse, AEM indicizzerà automaticamente e in modo incrementale il nuovo contenuto binario. Poiché la quantità di dati è incrementale e relativamente piccola (circa la quantità di dati che possono essere memorizzati nel repository in 5 secondi), AEM può eseguire l'estrazione full-text dai binari durante l'indicizzazione senza influire sulle prestazioni complessive del sistema.

Prerequisiti per l'utilizzo della preestrazione del testo

• Verrà reindicizzato un indice di lucene che esegue l'estrazione binaria full-text o distribuisce un nuovo indice che eseguirà i binari di indice full-text del contenuto esistente

• Il contenuto (file binari) da cui estrarre prima il testo deve trovarsi nella directory archivio

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

• Versione quercia: 1.0.18+, 1.2.3+

• oak-run.jarversion 1.7.4+

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

  • La configurazione OSGi di preestrazione del testo richiede un percorso del file system ai file di testo estratti, per cui devono essere accessibili direttamente dall'istanza AEM (unità locale o condivisione file)

Come eseguire la preestrazione del testo

Genera elenco di contenuti da pre-estrarre

Eseguire il passaggio 1(a-b) durante una finestra di manutenzione/un periodo di utilizzo basso, durante il quale il Node Store viene attraversato durante l'operazione, che può comportare un carico significativo sul sistema.

1 bis. Esegui oak-run.jar --generate per creare un elenco di nodi con testo pre-estratto.

1 ter. L’elenco dei nodi (1a) è memorizzato nel file system come file CSV

Tenere presente che l'intero Node Store viene attraversato (come specificato dai percorsi nel comando di esecuzione della quercia) ogni volta che viene eseguito --generate e viene creato un nuovo file CSV. Il file CSV è not riutilizzato tra le esecuzioni discrete del processo di preestrazione del testo (passaggi 1 - 2).

Pre-estrazione del testo nel file system

Il passaggio 2(a-c) può essere eseguito durante il normale funzionamento di AEM se interagisce solo con l'archivio dati.

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

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

2 quater. Il testo estratto viene memorizzato nel file system in un formato assimilabile dal processo di reindicizzazione Oak (3a)

Il testo preestratto è identificato nel CSV dall’impronta digitale binaria. Se il file binario è lo stesso, lo stesso testo preestratto può essere utilizzato in AEM istanze. Poiché AEM Publish è in genere un sottoinsieme di AEM Author, il testo preestratto da AEM Author può spesso essere utilizzato anche per reindirizzare AEM Publish (sempre che AEM Publish disponga dell'accesso del file system ai file di testo estratti).

Il testo preestratto può essere aggiunto in modo incrementale nel tempo. La preestrazione del testo salta l'estrazione per i binari precedentemente estratti, quindi è consigliabile mantenere il testo preestratto nel caso in cui la reindicizzazione debba ripetersi in futuro (supponendo che il contenuto estratto non sia troppo grande). In caso affermativo, valutate la compressione dei contenuti nel frattempo, poiché il testo viene compresso correttamente).

Reindicizzare gli indici Oak, ottenendo il testo completo dai file di testo estratti

Eseguire nuovamente il reindicizzazione (passaggi 3a-b) durante un periodo di manutenzione/basso utilizzo durante l'attraversamento del Node Store durante l'operazione, che potrebbe causare un carico significativo sul sistema.

3 bis. Gli indici Lucene indicizzati di nuovo vengono richiamati in AEM

3 ter. La configurazione OSGi Apache Jackrabbit Oak DataStore PreExtedTextProvider Oak (configurata per puntare al testo estratto tramite un percorso del file system) istruisce Oak al testo full-text originato dai file estratti ed evita di colpire e elaborare direttamente i dati memorizzati nella directory archivio.

Risorse Business.Adobe.com

Auto Text Summarization Cms Cloud Asset Collections Version History Dynamic Media Digital Signage