Tecniche consigliate per query e indicizzazione best-practices-for-queries-and-indexing
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 when-to-use-queries
Struttura dell’archivio e della tassonomia repository-and-taxonomy-design
Durante la progettazione della tassonomia di un archivio, occorre 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 “fruibilità” 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’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 queries-in-components
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 traversing-nodes
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 prefetching-results
A volte il contenuto o i requisiti intorno al componente non consentono l’uso di node traversal come metodo per recuperare i dati richiesti. 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.
Se i risultati richiesti per il componente possono essere calcolati al momento della creazione e non c’è alcuna aspettativa 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 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 delle query query-optimization
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.
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.
Strumento Spiega query the-explain-query-tool
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 debug-logging-for-queries
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 index-statistics
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 query-limits
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 post-deployment
-
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 tips-for-creating-efficient-indexes
È necessario creare un indice? should-i-create-an-index
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? lucene-or-property-indexes
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 solr-indexing
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.
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 design-considerations
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
orderedatrueper 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
nodeTypesemixinsper ottenere indici coerenti. Query di uno specificonodeTypeomixinsarà più performante che fare querynt:base. Quando utilizzi questo approccio, definisciindexRulespernodeTypesin 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 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 removing-indexes
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.
Reindicizzazione re-indexing
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.
Occorre evitare la reindicizzazione degli indici Oak, a meno che non sia coperta da una motivazione nelle tabelle seguenti.
- 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 oak-index-configuration-changes
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à property-index-definition-change
-
Si applica a/se:
- Tutte le versioni Oak
- Solo indici delle proprietà
-
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:createdojcr:lastModifiedproprietà 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 lucene-index-definition-change
-
Si applica a/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 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.
- Verifica che la definizione dell'indice sia stata modificata utilizzando il metodo Lucene Index statistics JMX Mbean (LuceneIndex)
-
Come risolvere:
-
Versioni di Oak precedenti alla 1.6:
- Reindicizzazione l'indice lucene
-
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
- Nota: Lo stato dell’indice dall’ultima reindicizzazione corretta (o indicizzazione iniziale) verrà utilizzato fino a quando non viene attivata una nuova reindicizzazione.
-
-
Situazioni di errore ed eccezionali erring-and-exceptional-situations
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 lucene-index-binary-is-missing
-
Si applica a/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 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 lucene-index-binary-is-corrupt
-
Si applica a/se:
- Tutte le versioni Oak
- Solo indici lucene
-
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
- Interrompi AEM
- Elimina la copia locale dell'indice lucene in
crx-quickstart/repository/index - Riavvia AEM
-
Se questo non risolve il problema, e il
AsyncIndexUpdatepersistono le eccezioni:- Reindicizzazione l'indice di errore
- Anche un file Supporto Adobe biglietto
-
Come reindicizzare how-to-re-index
Indice delle proprietà di reindicizzazione re-indexing-property-indexes
-
Utilizzo oak-run.jar per reindicizzare l'indice delle proprietà
-
Imposta la proprietà async-reindex su true sull'indice delle proprietà
[oak:queryIndexDefinition]@reindex-async=true
-
Reindicizza l'indice delle proprietà in modo asincrono utilizzando la Console web tramite la PropertyIndexAsyncReindex MBean;
ad esempio,
Re-indicizzazione indici delle proprietà Lucene re-indexing-lucene-property-indexes
-
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
Pre-estrazione del testo dei binari text-pre-extraction-of-binaries
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.
Quando è possibile utilizzare la preestrazione del testo? when-can-text-pre-extraction-be-used
Re-indicizzazione di un esistente indice lucene con estrazione binaria abilitata
- 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? when-can-text-pre-extraction-not-be-used
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.
Prerequisiti per l’utilizzo della preestrazione del testo 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
-
Una finestra di manutenzione per generare il file CSV E per eseguire la reindicizzazione finale
-
Versione Oak: 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 how-to-perform-text-pre-extraction
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.
1a. Esegui oak-run.jar --generate per creare un elenco di nodi in cui il loro testo verrà pre-estratto.
1b. 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.
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 CSV nel 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 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.
3a. Reindicizzazione di indici Lucene viene richiamato in AEM
3b. 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.