Tecniche consigliate per query e indicizzazione

Insieme alla transizione a Oak nel 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 il oak:index nodo. Una query può essere eseguita senza un indice, ma per i set di dati di grandi dimensioni, viene eseguita molto lentamente o persino in arresto.

Questo articolo illustra 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, assicurati di leggere il Documentazione Oak sulla scrittura di query e indici. Oltre a considerare gli indici come un nuovo concetto nel AEM 6, vi sono differenze sintattiche nelle query Oak che devono essere prese in considerazione durante la migrazione del codice da una precedente installazione AEM.

Quando utilizzare le query

Struttura dell'archivio e della tassonomia

Durante la progettazione della tassonomia di un archivio, è necessario tenere conto di diversi fattori. tra cui 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 "traversabilità" del design di indicizzazione. In questo contesto, l’attraversabilità è la capacità di una tassonomia che consente un accesso prevedibile ai contenuti in base al relativo percorso. Questo renderà più performante un sistema più semplice da mantenere rispetto a uno che richiederà l'esecuzione di molte query.

Inoltre, durante la progettazione di una tassonomia, è importante considerare l'importanza dell'ordine. Nei casi in cui non è richiesto un ordine 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 è richiesta l'ordinazione, nt:unstructured e sling:OrderedFolder sarebbe più appropriato.

Query nei componenti

Poiché le query possono essere una delle operazioni di imposizione più eseguite su un sistema AEM, è consigliabile evitarle nei componenti. L’esecuzione di più 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 l’esecuzione di query durante il rendering dei componenti: attraversamento dei nodi e risultati di preacquisizione.

Navigazione nei nodi

Se l'archivio è 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 il rendering di contenuti che si adattano a una determinata categoria. Un approccio consiste nell’organizzare il contenuto 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 nel strutturare il contenuto in una tassonomia per categoria in modo che possa essere recuperato manualmente.

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

/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

la /content/myUnstructuredContent/parentCategory/childCategory il nodo può essere semplicemente recuperato, i relativi figli 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 l’archivio e raccogliere i nodi richiesti, anziché creare una query per restituire lo stesso set di risultati. In generale, occorre evitare le interrogazioni laddove possibile.

Recupero preventivo dei risultati

Sometimes the content or the requirements around the component will not allow the use of node traversal as a method of retrieving the required data. In questi casi, è necessario eseguire le query necessarie prima di eseguire il rendering del componente in modo da garantire prestazioni ottimali per l’utente finale.

If the results that are required for the component can be calculated at the time that it is authored and there is no expectancy that the content will change, the query can be executed when the author applies settings in the dialog.

If the data or content will change regularly, the query can be executed on a schedule or via a listener for updates to the underlying data. Then, the results can be written to a shared location in the repository. 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 delle query

Quando si esegue una query che non utilizza un indice, verranno registrati avvisi relativi all'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, il Strumento Spiega query è consigliato. Per ulteriori informazioni, la registrazione DEBUG può essere abilitata per le API di ricerca pertinenti.

NOTA

Dopo aver modificato la definizione di un indice, quest'ultimo deve essere ricostruito (reindicizzato). A seconda delle dimensioni dell’indice, il completamento dell’operazione potrebbe richiedere del tempo.

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

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

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

Mentre tutte le query vengono convertite in SQL2 prima dell'esecuzione, 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.

NOTA

Quando si utilizza QueryBuilder, per impostazione predefinita verrà determinato il conteggio dei risultati, che è più lento in Oak rispetto alle versioni precedenti di Jackrabbit. Per compensare questo, è possibile utilizzare il Parametro guessTotal.

Strumento Spiega query

Come per qualsiasi linguaggio di query, il primo passo per ottimizzare una query è capire come verrà eseguita. Per abilitare questa attività, puoi utilizzare la funzione Strumento Spiega query fa parte del dashboard delle 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, nonché il tempo di esecuzione e gli indici che verranno utilizzati. Lo strumento può anche caricare un elenco di query lente e popolari che possono poi essere spiegate e ottimizzate.

Registrazione DEBUG per le query

Per ottenere alcune informazioni aggiuntive su come Oak sta scegliendo l'indice da utilizzare e come il motore di query sta eseguendo effettivamente una query, un DEBUG la configurazione della registrazione può essere aggiunta per i seguenti pacchetti:

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

Assicurati di rimuovere questo logger quando hai finito di eseguire il debug della query in quanto produrrà un sacco di attività e può alla fine riempire il disco con i file di log.

Per ulteriori informazioni su come eseguire questa operazione, consulta la Documentazione sulla registrazione.

Statistiche indice

Lucene registra un fagiolo JMX che fornirà dettagli sul contenuto indicizzato, tra cui la dimensione 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, esegui una ricerca per Statistiche dell'indice Lucene per trovarla. Altre statistiche sull'indice si trovano nella IndexStats MBean.

Per le statistiche delle query, controlla l’MBean denominato Statistiche query Oak.

Se desideri approfondire gli indici utilizzando uno strumento come Luca, sarà necessario utilizzare la console Oak per scaricare l’indice dal NodeStore in una directory filesystem. Per istruzioni su come eseguire questa operazione, leggere il Documentazione di Lucene.

Puoi anche estrarre gli indici nel tuo sistema in formato JSON. Per farlo, 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 ottimizza la query costosa quando si preme un UnsupportedOperationException dicendo "La query legge più di x nodi…"

Questo consente di evitare query ad alta intensità di risorse (ad es. non supportato 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 dei limiti sopra indicati deve essere analizzata e ottimizzata.

Post-distribuzione

  • Monitora i log per le query che attivano il consumo di memoria heap di grandi nodi o traversal 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 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
    • Ottimizza 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 di cui sopra sono preconfigurati OOTB e possono essere mantenuti 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

È necessario creare un indice?

La prima domanda da porsi quando si creano o si ottimizzano gli indici è se sono realmente necessari per una determinata situazione. Se esegui la query in questione solo una volta o solo occasionalmente e a un'ora 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, l'indice deve essere aggiornato. Poiché questo comporta implicazioni in termini di prestazioni per il sistema, gli indici dovrebbero essere creati solo quando sono effettivamente necessari.

Inoltre, gli indici sono utili solo se i dati contenuti all’interno dell’indice sono abbastanza univoci da garantirne l’attendibilità. Considera un indice in un libro e gli argomenti che tratta. Quando si indicizza un insieme di argomenti in un testo, di solito ci saranno centinaia o migliaia di voci, che ti consente di passare rapidamente a un sottoinsieme di pagine per trovare rapidamente le informazioni che stai cercando. Se quell'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 le statistiche degli indici, vedi Statistiche indice sopra.

Indici di proprietà o Lucene?

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

  • Gli indici Lucene offrono molte più funzionalità degli indici delle proprietà. Ad esempio, un indice di proprietà può indicizzare solo una singola proprietà, mentre un indice Lucene può includerne molte. Per ulteriori informazioni su tutte le funzioni disponibili negli indici Lucene, consulta la documentazione.
  • Gli indici Lucene sono asincroni. Anche se questo offre un notevole incremento delle prestazioni, 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 precisi al 100%, sarà necessario un indice di proprietà.
  • In virtù del fatto che è asincrono, gli indici Lucene non possono applicare vincoli di unicità. Se questo è necessario, allora sarà necessario creare un indice di proprietà.

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

Indicizzazione solare

AEM fornisce inoltre il supporto per l'indicizzazione Solr per impostazione predefinita. Questa funzione viene utilizzata principalmente per supportare la ricerca full text, ma può anche essere utilizzata per supportare qualsiasi tipo di query JCR. Solr dovrebbe essere considerato quando le istanze AEM non hanno la capacità della CPU per gestire il numero di query necessarie in implementazioni intensive di ricerca come siti web basati su 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 di dati incorporati nel server AEM per gli ambienti di sviluppo oppure possono essere scaricati in un'istanza remota per migliorare la scalabilità di ricerca negli ambienti di produzione e di staging. Mentre lo scaricamento della ricerca migliorerà la scalabilità, introdurrà latenza e per questo motivo, è sconsigliato se non richiesto. Per ulteriori informazioni su come configurare l’integrazione Solr e come creare indici Solr, consulta la sezione Documentazione su query e indicizzazione Oak.

NOTA

Se si adotta l'approccio integrato di ricerca Solr, si può scaricare l'indicizzazione su un server Solr. Se le funzioni più avanzate del server Solr vengono utilizzate tramite un approccio basato su crawler, sarà necessario un ulteriore lavoro di configurazione. La cuffia ha creato un connettore open source accelerare questi tipi di implementazioni.

Il lato negativo di questo approccio è che, mentre per impostazione predefinita, le query AEM rispetteranno le ACL e quindi nascondono i risultati a cui un utente non ha accesso, esternalizzare la ricerca a un server Solr non supporterà questa funzione. Se la ricerca deve essere esternalizzata in questo modo, occorre prestare maggiore attenzione affinché 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, potresti avere un sito ospitato su AEM e un secondo sito ospitato su una piattaforma di terze parti. È possibile configurare Solr per eseguire la ricerca per indicizzazione del contenuto di entrambi i siti e archiviarli in un indice aggregato. Ciò consentirebbe ricerche tra siti diversi.

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, utilizza evaluatePathRestrictions. Questo consentirà alla query di restituire il sottoinsieme di risultati sotto il percorso specificato e quindi di filtrarli in base alla query. In caso contrario, la query cercherà tutti i risultati che corrispondono ai parametri di query nel repository e quindi li filtrerà in base al percorso.

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

  • Mettete solo ciò che è necessario nell'indice. L'aggiunta di funzionalità o proprietà non necessarie causerà l'aumento e il rallentamento delle prestazioni dell'indice.

  • In un indice di proprietà, avere un nome di proprietà univoco contribuirebbe a ridurre la dimensione su un indice, ma per gli indici Lucene, l'uso di nodeTypes e mixins per ottenere indici coerenti. Query di uno specifico nodeType o mixin sarà più performante che fare query nt:base. Quando utilizzi questo approccio, definisci indexRules per nodeTypes in questione.

  • Se le query vengono eseguite solo in determinati percorsi, crea tali indici sotto tali percorsi. Gli indici non sono necessari per vivere nella directory principale dell'archivio.

  • Si consiglia di utilizzare un singolo indice quando tutte le proprietà indicizzate 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

Nei casi in cui NodeStore viene memorizzato in remoto, un'opzione denominata CopyOnRead può essere attivato. L'opzione fa sì che l'indice remoto venga scritto nel file system locale quando viene letto. Questo può aiutare a migliorare le prestazioni per le query che vengono spesso eseguite con questi indici remoti.

Questa può essere configurata nella console OSGi sotto la LuceneIndexProvider e è abilitato per impostazione predefinita a partire da Oak 1.0.13.

Rimozione degli indici

Quando si rimuove un indice, si consiglia sempre di disattivare temporaneamente l'indice impostando il type proprietà di disabled e eseguire test per garantire che l'applicazione funzioni correttamente prima di eliminarla. Tieni 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à su un'istanza TarMK, sarà necessario eseguire la compattazione per recuperare lo spazio su disco in uso. Per gli indici Lucene, l'effettivo contenuto dell'indice vive nel BlobStore, quindi sarebbe necessario un archivio dati per la raccolta degli oggetti inattivi.

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

NOTA

For more information about oak-mongo.js, see the Command Line Tools section of the Oak documentation.

Foglio di calcolo della query JCR

Per supportare la creazione di query JCR efficienti e le definizioni degli indici, la Foglio di calcolo della query JCR è disponibile per il download e l’utilizzo come riferimento durante lo sviluppo. It contains sample queries for QueryBuilder, XPath and SQL-2, covering multiple scenarios which behave differently in terms of query performance. Fornisce inoltre raccomandazioni su come creare o personalizzare gli indici Oak. The content of this Cheat Sheet applies to AEM 6.5 and AEM as a Cloud Service.

Reindicizzazione

Questa sezione delinea la only motivi accettabili per reindicizzare gli indici Oak.

Al di fuori dei motivi descritti di seguito, l'avvio di reindici di Oak not modificare il comportamento o risolvere i problemi e aumentare inutilmente il carico su AEM.

Re-indexing of Oak indexes is to be avoided unless covered by a reasons in the tables below.

NOTA

Prior to consulting the tables below to determine is re-indexing is useful, always verify:

  • la query è corretta
  • la query viene risolta nell'indice previsto (utilizzando Spiega query)
  • il processo di indicizzazione è stato completato

Modifiche alla configurazione dell'indice Oak

L'unica condizione accettabile di non-erring per la reindicizzazione degli 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 bassa attività o di intervallo di manutenzione.

I seguenti dettagli possono essere presentati insieme alle risoluzioni:

Modifica della definizione dell'indice di proprietà

  • Si applica a/se:

  • Sintomi:

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

    • Determina se i nodi mancanti sono stati creati/modificati prima della distribuzione della definizione di indice aggiornata.
    • Verifica la jcr:created o jcr:lastModified proprietà di eventuali nodi mancanti rispetto al tempo modificato dell'indice
  • Come risolvere:

    • Reindicizzazione l'indice lucene

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

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

Modifica della definizione dell'indice Lucene

  • Si applica a/se:

  • Sintomi:

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

    • Verifica che la definizione dell'indice sia stata modificata utilizzando il metodo Lucene Index statistics JMX Mbean (LuceneIndex) diffStoredIndexDefinition.
  • Come risolvere:

    • Versioni di Oak precedenti alla 1.6:

    • Oak versioni 1.6+

      • Se le modifiche non apportano contenuto esistente, è necessario solo un aggiornamento

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

        • Note: The index state from the last good re-indexing (or initial indexing) will be used until a new re-indexing is triggered

Situazioni di errore ed eccezionali

La tabella seguente descrive le uniche situazioni di errore accettabili ed eccezionali in cui la reindicizzazione degli indici Oak risolverà il problema.

Se si verifica un problema su AEM che non corrisponde ai criteri descritti di seguito, fai not reindicizza eventuali indici, in quanto non risolverà il problema.

I seguenti dettagli possono essere presentati insieme alle risoluzioni:

Il binario dell'indice Lucene è mancante

  • Si applica a/se:

  • Sintomi:

    • Lucene index does not contain expected results
  • Come verificare:

    • The error log file contains an exception saying a binary of the Lucene index is missing
  • Come risolvere:

    • Eseguire un controllo del repository di traversata; ad esempio:

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

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

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

    • In caso contrario, reindicizzazione tutto indici lucene

    • Nota:

      Questa condizione è indicativa di un datastore configurato in modo errato che può comportare QUALSIASI binario (ad esempio asset binari) da perdere.

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

Il binario dell'indice Lucene è corrotto

  • Si applica a/se:

  • Sintomi:

    • L'indice Lucene non contiene i risultati previsti
  • Come verificare:

    • La AsyncIndexUpdate (ogni 5s) fallirà con un'eccezione nel log degli errori:

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

  • Come risolvere:

    • Rimuovi la copia locale dell'indice lucene

      1. Interrompi AEM
      2. Elimina la copia locale dell'indice lucene in crx-quickstart/repository/index
      3. Riavvia AEM
    • Se questo non risolve il problema, e il AsyncIndexUpdate persistono le eccezioni:

      1. Reindicizzazione l'indice di errore
      2. Anche un file Supporto Adobe biglietto

Come reindicizzare

NOTA

AEM 6.5, oak-run.jar è il metodo ONLY supportato per la reindicizzazione su archivi MongoMK o RDBMK.

Indice delle proprietà di reindicizzazione

Re-indicizzazione indici delle proprietà Lucene

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

  • Imposta la proprietà async-reindex su true sull'indice delle proprietà lucene

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

La sezione precedente riassume e incornicia le indicazioni di reindicizzazione Oak dal Documentazione di Apache Oak nel contesto di AEM.

Pre-estrazione del testo dei binari

La preestrazione del testo è il processo di estrazione ed elaborazione del testo dai binari, direttamente dall’archivio dati tramite un processo isolato, ed espone direttamente il testo estratto ai successivi re/indici degli indici Oak.

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

When CAN text pre-extraction be used?

Re-indexing an existing lucene index with binary extraction enabled

  • Elaborazione della reindicizzazione tutto contenuto candidato nell'archivio; 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 posizionato su AEM. La preestrazione del testo sposta il "lavoro computazionale" dell’estrazione del testo in un processo isolato che accede direttamente AEM Data Store, evitando costi comuni e contese delle risorse in AEM.

Sostenere la diffusione di un nuovo lucene index to AEM con estrazione binaria abilitata

  • Quando un nuovo indice (con l’estrazione binaria abilitata) viene distribuito in AEM, Oak indicizza automaticamente tutti i contenuti candidati nella successiva esecuzione asincrona dell’indice di testo completo. Per gli stessi motivi descritti nella reindicizzazione di cui sopra, 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 all’archivio, né è necessaria.

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

In condizioni normali di AEM, ad esempio durante il caricamento di risorse tramite l’interfaccia utente web o l’acquisizione programmatica di risorse, AEM indicizza 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 nell’archivio in 5 secondi), AEM può eseguire l’estrazione full-text dai binari durante l’indicizzazione senza influire sulle prestazioni complessive del sistema.

Prerequisites to using text pre-extraction

  • Reindicizzerai un indice lucene che esegue l’estrazione binaria full-text o distribuirai un nuovo indice che eseguirà i binari di indice full-text del contenuto esistente

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

  • A maintenance window to generate the CSV file AND to perform the final re-indexing

  • Oak version: 1.0.18+, 1.2.3+

  • oak-run.jarversione 1.7.4+

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

    • La configurazione OSGi di pre-estrazione del testo richiede un percorso del file system ai file di testo estratti, in modo che siano accessibili direttamente dall'istanza AEM (unità locale o file share mount)

Come eseguire la preestrazione del testo

NOTA

The oak-run.jar commands outlined below are fully enumerated at https://jackrabbit.apache.org/oak/docs/query/pre-extract-text.html

Il diagramma e i passaggi descritti di seguito spiegano e completano i passaggi tecnici di preestrazione del testo descritti nella documentazione Apache Oak.

Flusso del processo di preestrazione del testo

Genera elenco di contenuti da pre-estrarre

Esegui il passaggio 1(a-b) durante una finestra di manutenzione/un periodo di utilizzo ridotto, mentre il Node Store viene attraversato durante questa operazione, che può comportare un carico significativo sul sistema.

1 bis. Esegui oak-run.jar --generate per creare un elenco di nodi in cui il loro testo verrà pre-estratto.

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

Tieni presente che l’intero Node Store viene attraversato ogni volta (come specificato dai percorsi nel comando oak-run) --generate viene eseguito e viene eseguito un nuovo Viene creato un file CSV. Il file CSV è not riutilizzato tra esecuzioni discrete del processo di preestrazione del testo (passaggi 1 - 2).

Preestrarre 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. The process initiated in (2a) accesses binary nodes defined in the CSV in Data Store directly, and extracts text.

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

Il testo pre-estratto è identificato nel CSV dall’impronta digitale binaria. Se il file binario è lo stesso, lo stesso testo pre-estratto può essere utilizzato in AEM istanze. Poiché AEM Publish è solitamente un sottoinsieme di AEM Author, il testo pre-estratto da AEM Author può spesso essere utilizzato anche per reindicizzare AEM Publish (partendo dal presupposto che AEM Publish abbia accesso al file di testo estratto).

Il testo pre-estratto può essere aggiunto in modo incrementale nel tempo. La preestrazione del testo salterà l’estrazione per i binari precedentemente estratti, quindi è consigliabile mantenere il testo pre-estratto nel caso in cui la reindicizzazione debba ripetersi in futuro (supponendo che il contenuto estratto non sia eccessivamente grande). Se lo è, valuta la compressione dei contenuti nel frattempo, dal momento che il testo si comprime bene).

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

Esegui la reindicizzazione (passaggi 3a-b) durante un periodo di manutenzione/basso utilizzo mentre il Node Store viene attraversato durante questa operazione, che può comportare un carico significativo sul sistema.

3 bis. Reindicizzazione di indici Lucene viene richiamato in AEM

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

In questa pagina