Best Practices für Abfragen und Indizierung best-practices-for-queries-and-indexing

Neben dem Übergang zu Oak in AEM 6 wurden auch einige bedeutende Änderungen in Bezug auf die Verwaltung von Abfragen und Indizes vorgenommen. Unter Jackrabbit 2 wurde sämtlicher Inhalt standardmäßig indiziert und war frei abrufbar. In Oak müssen Indizes manuell unter dem Knoten oak:index erstellt werden. Eine Abfrage kann zwar ohne Index ausgeführt werden, aber bei großen Datensätzen ist dieser Vorgang sehr langsam. Es kann sogar zu einem Abbruch kommen.

In diesem Artikel wird beschrieben, wann Indizes zu erstellen sind und wann auf sie verzichtet werden kann. Außerdem finden Sie hierin Tricks zum Vermeiden von nicht benötigten Abfragen sowie Tipps zur Funktionsoptimierung von Indizes und Abfragen.

Darüber hinaus sollten Sie die Oak-Dokumentation zum Erstellen von Abfragen und Indizes lesen. Außer den als neues Konzept in AEM 6 eingeführten Indizes gibt es syntaktische Unterschiede in Oak-Abfragen, die beim Migrieren von Code aus früheren AEM-Installationen berücksichtigt werden müssen.

Wann Abfragen verwendet werden sollten when-to-use-queries

Repository- und Taxonomiedesign repository-and-taxonomy-design

Bei der Erstellung der Taxonomie eines Repositorys müssen mehrere Faktoren berücksichtigt werden. Dazu gehören unter anderem Zugriffssteuerungen, Lokalisierung, die Vererbung von Komponenten- und Seiteneigenschaften.

Beim Entwerfen einer Taxonomie, die diese Bedenken berücksichtigt, muss zudem auch die „Durchlauffähigkeit“ des Index-Designs beachtet werden. In diesem Zusammenhang ist die Durchlaufbarkeit die Fähigkeit einer Taxonomie, die den vorhersehbaren Zugriff auf Inhalte auf Grundlage ihres Pfads ermöglicht. Dies ermöglicht ein leistungsfähigeres System, das leichter zu verwalten ist als ein System, bei dem viele Abfragen ausgeführt werden müssen.

Darüber hinaus muss beim Entwerfen einer Taxonomie bedacht werden, ob eine Sortierung wichtig ist. Wenn auf eine explizite Sortierung verzichtet werden kann und eine große Anzahl gleichgeordneter Knoten erwartet wird, sind unsortierte Knotentypen wie sling:Folder oder oak:Unstructured vorzuziehen. Ist eine Sortierung erforderlich, wären nt:unstructured und sling:OrderedFolder besser geeignet.

Abfragen in Komponenten queries-in-components

Da Abfragen eine der steuerbareren Vorgänge in einem AEM sein können, ist es empfehlenswert, sie in Ihren Komponenten zu vermeiden. Die Ausführung mehrerer Abfragen bei jedem Rendern einer Seite kann häufig die Leistung des Systems beeinträchtigen. Es gibt zwei Strategien, mit denen sich beim Rendering von Komponenten die Ausführung von Abfragen vermeiden lässt: Durchlaufen von Knoten und Vorabrufen von Ergebnissen.

Durchlaufen von Knoten traversing-nodes

Wenn das Repository so konzipiert ist, dass eine vorherige Kenntnis des Speicherorts der erforderlichen Daten möglich ist, kann Code, der diese Daten aus den erforderlichen Pfaden abruft, bereitgestellt werden, ohne Abfragen ausführen zu müssen, um sie zu finden.

Ein Beispiel hierfür wäre das Rendern von Inhalten, die zu einer bestimmten Kategorie passen. Ein Ansatz wäre, den Inhalt mit einer Kategorieeigenschaft zu organisieren, die abgefragt werden kann, um eine Komponente zu füllen, die Elemente in einer Kategorie anzeigt.

Ein besserer Ansatz wäre, diesen Inhalt in einer Taxonomie nach Kategorie zu strukturieren, damit er manuell abgerufen werden kann.

Wenn der Inhalt beispielsweise in einer Taxonomie gespeichert ist, die Folgendem ähnelt:

/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

In diesem Fall lässt sich der Knoten /content/myUnstructuredContent/parentCategory/childCategory einfach abrufen und seine untergeordneten Elemente können analysiert und zum Rendern der Komponente verwendet werden.

Wenn Sie es mit einem kleinen oder homogenen Ergebnissatz zu tun haben, kann es außerdem schneller sein, das Repository zu durchlaufen und die erforderlichen Knoten zu sammeln, anstatt eine Abfrage zu erstellen, um denselben Ergebnissatz zurückzugeben. Generell sollten Abfragen vermieden werden, soweit dies möglich ist.

Vorabruf der Ergebnisse prefetching-results

Manchmal lässt der Inhalt oder die Anforderungen um die Komponente die Verwendung von Knotendurchlauf zum Abrufen der erforderlichen Daten nicht zu. In diesen Fällen müssen die erforderlichen Abfragen vor dem Rendern der Komponente ausgeführt werden, damit eine optimale Leistung für den Endbenutzer gewährleistet ist.

Wenn die für die Komponente erforderlichen Ergebnisse zum Zeitpunkt der Erstellung berechnet werden können und es nicht zu erwarten ist, dass sich der Inhalt ändert, kann die Abfrage ausgeführt werden, wenn der Autor die Einstellungen im Dialogfeld anwendet.

Wenn sich die Daten oder Inhalte regelmäßig ändern, kann die Abfrage planmäßig oder über einen Listener für Aktualisierungen der zugrunde liegenden Daten ausgeführt werden. Anschließend können die Ergebnisse an einen freigegebenen Speicherort im Repository geschrieben werden. Alle Komponenten, die diese Daten benötigen, können dann die Werte aus diesem einzelnen Knoten beziehen, ohne eine Abfrage zur Laufzeit auszuführen.

Abfrageoptimierung query-optimization

Wenn eine Abfrage ausgeführt wird, bei der kein Index verwendet wird, werden Warnungen bezüglich der Knotendurchlauf protokolliert. Wenn es sich um eine Abfrage handelt, die häufig ausgeführt wird, sollte ein Index erstellt werden. Um festzustellen, welcher Index von einer bestimmten Abfrage verwendet wird, wird das Tool „Abfrage erläutern“ empfohlen. Zum Erhalt weiterer Informationen kann die DEBUG-Protokollierung für die entsprechenden Such-APIs aktiviert werden.

Bei der Ausführung komplexer Abfragen kann es vorkommen, dass die Aufschlüsselung der Abfrage in mehrere kleinere Abfragen und die Verknüpfung der Daten über den Code nach der Tatsache leistungsfähiger ist. Für diese Fälle wird empfohlen, die Leistung der beiden Ansätze zu vergleichen, um festzustellen, welche Option für den betreffenden Anwendungsfall besser wäre.

AEM ermöglicht das Schreiben von Abfragen auf eine von drei Arten:

Während alle Abfragen vor der Ausführung in SQL2 konvertiert werden, ist der Aufwand für die Abfragekonvertierung minimal und daher die größte Sorge bei der Auswahl einer Abfragesprache die Lesbarkeit und Komfort des Entwicklungsteams.

Tool "Abfrage erläutern" the-explain-query-tool

Wie bei jeder anderen Abfragesprache besteht der erste Schritt zur Optimierung einer Abfrage darin, zu verstehen, wie sie ausgeführt wird. Dies ermöglicht das Tool „Abfrage erläutern“, das zum Vorgangs-Dashboard gehört. Mithilfe dieses Tools kann eine Abfrage geladen und erläutert werden. Eine Warnung wird angezeigt, wenn die Abfrage Probleme mit einem großen Repository sowie die Ausführungszeit und die zu verwendenden Indizes verursacht. Das Tool kann auch eine Liste langsamer und beliebter Abfragen laden, die dann erklärt und optimiert werden können.

DEBUG-Protokollierung für Abfragen debug-logging-for-queries

Um zusätzliche Informationen darüber zu erhalten, wie Oak auswählt, welchen Index verwendet werden soll und wie die Abfrage-Engine tatsächlich eine Abfrage ausführt, wird ein DEBUG Die Protokollierungskonfiguration kann für die folgenden Pakete hinzugefügt werden:

Stellen Sie sicher, dass Sie diesen Logger entfernen, wenn Sie das Debugging Ihrer Abfrage abgeschlossen haben, da er viele Aktivitäten ausgibt und schließlich Ihre Festplatte mit Protokolldateien füllen kann.

Weitere Informationen hierzu finden Sie im Abschnitt Dokumentation zur Protokollierung.

Indexstatistiken index-statistics

Lucene registriert ein JMX-Bean, das Details zu indizierten Inhalten einschließlich der Größe und Anzahl der in den einzelnen Indizes vorhandenen Dokumente bereitstellt.

Ein Zugriff ist über die JMX-Konsole unter https://server:port/system/console/jmx möglich.

Nachdem Sie in der JMX-Konsole angemeldet sind, suchen Sie nach Lucene-Indexstatistiken um sie zu finden. Weitere Indexstatistiken finden Sie im IndexStats MBean.

Sehen Sie sich die MBean mit dem Namen Oak Query Statistics.

Um Ihre Indizes mit einem Tool wie Luke durchzugehen, müssen Sie die Oak-Konsole aufrufen und den Index vom NodeStore in einem Dateisystemverzeichnis sichern. Anweisungen hierzu finden Sie im Abschnitt Lucene-Dokumentation.

Sie können die Indizes in Ihrem System auch im JSON-Format extrahieren. Hierzu müssen Sie auf Folgendes zugreifen: https://server:port/oak:index.tidy.-1.json

Abfragelimits query-limits

Während der Entwicklung

Festlegung niedriger Schwellenwerte für oak.queryLimitInMemory (z. B. 10.000) und oak. queryLimitReads (z. B. 5000) und optimieren Sie die teure Abfrage, wenn Sie eine UnsupportedOperationException -Ausnahme mit der Meldung "The query read more than x nodes…"erreichen.

Auf diese Weise lassen sich ressourcenintensive Abfragen vermeiden (d. h. nicht durch einen Index unterlegt oder durch einen Index unterlegt, der weniger bedeckt ist). Beispielsweise würde eine Abfrage, die 1 Million Knoten liest, zu einer Erhöhung der E/A führen und die Gesamtleistung der Anwendung negativ beeinflussen. Jede Abfrage, die aufgrund der obigen Beschränkungen fehlschlägt, sollte analysiert und optimiert werden.

Nach der Bereitstellung post-deployment

Für die AEM-Versionen 6.0 bis 6.2 können Sie den Schwellenwert für das Durchlaufen von Knoten über JVM-Parameter im AEM-Startskript abstimmen, um zu verhindern, dass die Umgebung durch umfangreiche Abfragen überlastet wird.

Folgende Werte werden empfohlen:

In AEM 6.3 sind die beiden oben stehenden Parameter vorkonfigurierte OOTB-Kategorien, die über die OSGi QueryEngineSettings beibehalten werden können.

Weitere Informationen finden Sie unter: https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limits

Tipps zum Erstellen effizienter Indizes tips-for-creating-efficient-indexes

Sollte ich einen Index erstellen? should-i-create-an-index

Die erste Frage, die beim Erstellen oder Optimieren von Indizes gestellt werden muss, ist, ob sie für eine bestimmte Situation wirklich erforderlich sind. Wenn Sie die fragliche Abfrage nur einmal oder nur gelegentlich und zu einer Zeit außerhalb der Spitzenzeiten für das System über einen Batch-Prozess ausführen, ist es möglicherweise besser, überhaupt keinen Index zu erstellen.

Wenn ein Index erstellt wurde, muss mit jeder Aktualisierung der indizierten Daten auch der Index aktualisiert werden. Da sich dies auf die Leistung des Systems auswirkt, sollten Indizes nur dann erstellt werden, wenn sie tatsächlich benötigt werden.

Darüber hinaus sind Indizes nur nützlich, wenn die im Index enthaltenen Daten eindeutig genug sind, um sie zu rechtfertigen. Betrachten Sie einen Index in einem Buch und die Themen, die darin behandelt werden. Bei der Indizierung einer Reihe von Themen in einem Text gibt es in der Regel Hunderte oder Tausende von Einträgen, was es Ihnen ermöglicht, schnell zu einer Untergruppe von Seiten zu springen, um die gesuchten Informationen schnell zu finden. Wenn dieser Index nur zwei oder drei Einträge hätte, von denen jeder auf mehrere Hundert Seiten verweist, wäre der Index nicht sehr nützlich. Dasselbe Konzept gilt für Datenbankindizes. Sind nur einige eindeutige Werte vorhanden, ist der Index nicht sehr nützlich. Dabei kann ein Index auch zu umfangreich werden und dadurch seine Nützlichkeit verlieren. Informationen zu Indexstatistiken finden Sie unter Indexstatistiken höher.

Lucene- oder Eigenschaftenindizes? lucene-or-property-indexes

Lucene-Indizes wurden in Oak 1.0.9 eingeführt und bieten einige leistungsstarke Optimierungen gegenüber den Eigenschaftenindizes, die beim ersten Start von AEM 6 eingeführt wurden. Berücksichtigen Sie bei der Entscheidung, ob Lucene-Indizes oder Eigenschaftenindizes verwendet werden sollen, Folgendes:

Im Allgemeinen wird empfohlen, Lucene-Indizes zu verwenden, es sei denn, es besteht eine zwingende Notwendigkeit, Eigenschaftenindizes zu verwenden, damit Sie die Vorteile einer höheren Leistung und Flexibilität nutzen können.

Solr-Indizierung solr-indexing

AEM unterstützt standardmäßig auch die Solr-Indizierung. Dies wird hauptsächlich zur Unterstützung der Volltextsuche verwendet, kann aber auch zur Unterstützung beliebiger JCR-Abfragen verwendet werden. Solr sollte berücksichtigt werden, wenn die AEM Instanzen nicht über die CPU-Kapazität verfügen, um die Anzahl der Abfragen zu verarbeiten, die in suchintensiven Implementierungen wie suchgesteuerten Websites mit einer hohen Anzahl gleichzeitiger Benutzer erforderlich sind. Alternativ kann Solr in einem Crawler-basierten Ansatz implementiert werden, um einige der fortschrittlicheren Funktionen der Plattform zu nutzen.

Solr-Indizes können so konfiguriert werden, dass sie für Entwicklungsumgebungen eingebettet auf dem AEM-Server ausgeführt werden, oder sie können in eine Remote-Instanz abgeladen werden, um die Suchskalierbarkeit in der Produktions- und Staging-Umgebung zu verbessern. Während die Abladung der Suche die Skalierbarkeit verbessert, führt sie zu Latenzzeiten, und deshalb wird es nicht empfohlen, es sei denn, dies ist erforderlich. Weitere Informationen zum Konfigurieren der Solr-Integration und zum Erstellen von Solr-Indizes finden Sie unter Dokumentation zu Oak-Abfragen und Indizierung.

Der Nachteil dieses Ansatzes besteht darin, dass AEM Abfragen zwar standardmäßig ACLs respektieren und so Ergebnisse verbergen, auf die ein Benutzer keinen Zugriff hat. Eine Externalisierung der Suche an einen Solr-Server unterstützt diese Funktion nicht. Wenn die Suche auf diese Weise externalisiert werden soll, muss besonders darauf geachtet werden, dass den Benutzern keine Ergebnisse angezeigt werden, die sie nicht sehen sollten.

Mögliche Anwendungsfälle, in denen dieser Ansatz sinnvoll sein kann, sind Fälle, in denen Suchdaten aus mehreren Quellen möglicherweise aggregiert werden müssen. So kann es beispielsweise vorkommen, dass eine Site auf AEM gehostet wird und eine zweite Site auf einer Drittanbieterplattform gehostet wird. Solr könnte so konfiguriert werden, dass der Inhalt beider Sites durchsucht und in einem aggregierten Index gespeichert wird. Dies würde Site-übergreifende Suchen ermöglichen.

Designüberlegungen design-considerations

In der Oak-Dokumentation für Lucene-Indizes werden verschiedene Überlegungen zum Erstellen von Indizes aufgeführt:

CopyOnRead copyonread

Wenn NodeStore remote gespeichert wird, kann die Option CopyOnRead aktiviert werden. Die Option bewirkt, dass der Remote-Index beim Lesen in das lokale Dateisystem geschrieben wird. Dies kann dazu beitragen, die Leistung von Abfragen zu verbessern, die häufig mit diesen Remote-Indizes ausgeführt werden.

Dies kann in der OSGi-Konsole unter der LuceneIndexProvider und ist standardmäßig ab Oak 1.0.13 aktiviert.

Entfernen von Indizes removing-indexes

Beim Entfernen eines Index wird immer empfohlen, den Index durch Einstellen der Eigenschaft type auf disabled vorübergehend zu deaktivieren und Tests durchzuführen, um vor dem Löschen eine ordnungsgemäße Funktionsweise der Anwendung sicherzustellen. Beachten Sie, dass ein Index bei Deaktivierung nicht aktualisiert wird, sodass er möglicherweise nicht über den richtigen Inhalt verfügt, wenn er reaktiviert wird, und möglicherweise neu indiziert werden muss.

Nachdem Sie einen Eigenschaftsindex auf einer TarMK-Instanz entfernt haben, muss die Komprimierung ausgeführt werden, um den verwendeten Speicherplatz zurückzugewinnen. Bei Lucene-Indizes befindet sich der tatsächliche Indexinhalt im BlobStore, sodass eine automatische Datenspeicherbereinigung erforderlich ist.

Beim Entfernen eines Index auf einer MongoDB-Instanz sind die Löschkosten proportional zur Anzahl der Knoten im Index. Da das Löschen eines großen Index Probleme verursachen kann, wird empfohlen, den Index zu deaktivieren und ihn nur während eines Wartungsfensters zu löschen, indem ein Tool wie oak-mongo.js. Bitte beachten Sie, dass dieser Ansatz nicht für reguläre Knoteninhalte verwendet werden sollte, da er Dateninkonsistenzen verursachen kann.

Neuindizieren re-indexing

In diesem Abschnitt werden die einzigen akzeptablen Gründe für eine Neuindizierung von Oak-Indizes beschrieben.

Außerhalb der unten aufgeführten Gründe wird das Initiieren von Neuindizes von Oak-Indizes not Verhalten ändern oder Probleme lösen und die Last auf AEM unnötig erhöhen.

Eine Neuindizierung von Oak-Indizes muss vermieden werden, sofern nicht einer der in den folgenden Tabellen genannten Gründe vorliegt.

Änderungen der Oak-Indexkonfiguration oak-index-configuration-changes

Die einzige akzeptable, nicht fehlerhafte Bedingung für die Neuindizierung von Oak-Indizes ist, dass sich die Konfiguration eines Oak-Index geändert hat.

Vor einer Neuindizierung sollten die damit verbundenen Auswirkungen auf die AEM-Gesamtleistung angemessen berücksichtigt werden. Darüber hinaus sollte die Neuindizierung in Zeiträumen geringer Aktivität oder während Wartungsfenstern stattfinden.

Im Folgenden finden Sie Details zu möglichen Problemen sowie entsprechende Lösungen:

Definitionsänderung des Eigenschaftenindex property-index-definition-change

Definitionsänderung des Lucene-Index lucene-index-definition-change

Fehler und außergewöhnliche Situationen erring-and-exceptional-situations

In der folgenden Tabelle werden die einzigen akzeptablen Fehler- und Ausnahmesituationen beschrieben, in denen die Neuindizierung von Oak-Indizes das Problem beheben wird.

Wenn bei AEM ein Problem auftritt, das nicht den unten beschriebenen Kriterien entspricht, führen Sie not Indizieren Sie alle Indizes neu, da dies das Problem nicht behebt.

Im Folgenden finden Sie Details zu möglichen Problemen sowie entsprechende Lösungen:

Fehlende Lucene-Index-Binärdateien lucene-index-binary-is-missing

Beschädigte Lucene-Index-Binärdateien lucene-index-binary-is-corrupt

Neuindizieren von Indizes how-to-re-index

Neuindizieren von Eigenschaftenindizes re-indexing-property-indexes

Neuindizierung von Lucene-Eigenschaftenindizes re-indexing-lucene-property-indexes

Textvorextraktion von Binärdateien text-pre-extraction-of-binaries

Bei der Textvorextraktion wird Text aus Binärdateien extrahiert und verarbeitet, direkt aus dem Datenspeicher über einen isolierten Prozess, und der extrahierte Text wird direkt zu nachfolgenden Neuindizierungen von Oak-Indizes weitergeleitet.

Wann kann die Textvorextraktion verwendet werden? when-can-text-pre-extraction-be-used

Neuindizieren einer vorhandene Lucene-Index mit aktivierter Binärextraktion

Unterstützung bei der Bereitstellung eines new Lucene-Index für AEM mit aktivierter Binärextraktion

Wann kann die Textvorextraktion NICHT verwendet werden? when-can-text-pre-extraction-not-be-used

Die Textvorextraktion kann nicht für neue Inhalte verwendet werden, die zum Repository hinzugefügt werden, und ist auch nicht erforderlich.

Neue Inhalte werden dem Repository hinzugefügt und werden automatisch schrittweise durch den asynchronen Volltext-Indizierungsprozess indiziert (standardmäßig alle 5 Sekunden).

Unter normalen AEM, z. B. beim Hochladen von Assets über die Web-Benutzeroberfläche oder bei der programmatischen Aufnahme von Assets, wird AEM den neuen binären Inhalt automatisch und inkrementell in Volltext indizieren. Da die Datenmenge inkrementell und relativ gering ist (was ungefähr der Datenmenge entspricht, die in 5 Sekunden im Repository gespeichert werden kann), können AEM während der Indizierung die Volltextextextraktion aus den Binärdateien durchführen, ohne die Gesamtleistung des Systems zu beeinträchtigen.

Voraussetzungen für die Verwendung der Textvorextraktion prerequisites-to-using-text-pre-extraction

Durchführen der Textvorextraktion how-to-perform-text-pre-extraction

Generieren einer Inhaltsliste für die Vorextraktion

Führen Sie Schritt 1 (a-b) während eines Wartungsfensters/Zeitraums mit geringer Nutzung aus, da der Knotenspeicher während dieses Vorgangs durchlaufen wird, was eine erhebliche Belastung des Systems verursachen kann.

1a. Führen Sie oak-run.jar --generate aus, um eine Liste der Knoten mit vorextrahiertem Text zu erstellen.

1b. Die Liste der Knoten (1a) wird im Dateisystem als CSV-Datei gespeichert

Der gesamte Knotenspeicher wird jedes Mal durchlaufen (wie in den Pfaden des oak-run-Befehls angegeben), wenn --generate ausgeführt und eine neue CSV-Datei erstellt wird. Die CSV-Datei wird zwischen den diskreten Ausführungen des Textextraktionsprozesses (Schritte 1–2) nicht wiederverwendet.

Text vorab in Dateisystem extrahieren

Schritt 2 (a-c) kann während des normalen AEM ausgeführt werden, da nur mit dem Datenspeicher interagiert wird.

2a. Führen Sie oak-run.jar --tika aus, um Text für die in der unter (1b) generierten CSV-Datei genannten Binärknoten vorzuextrahieren.

2b. Der in (2a) initiierte Prozess greift direkt auf die Binärknoten zu, die in der CSV-Datei im Datenspeicher definiert sind, und extrahiert Text.

2c. Der extrahierte Text wird im Dateisystem in einem Format gespeichert, das vom Oak-Neuindizierungsprozess (3a) verarbeitet werden kann.

Vorextrahierter Text ist in der CSV-Datei durch einen binären Fingerabdruck gekennzeichnet. Wenn die Binärdatei identisch ist, kann derselbe vorextrahierte Text für AEM Instanzen verwendet werden. Da AEM Publish normalerweise eine Untergruppe von AEM Author ist, kann der vorab extrahierte Text aus AEM Author häufig auch verwendet werden, um AEM Publish erneut zu indizieren (vorausgesetzt, die AEM-Veröffentlichung hat Dateisystemzugriff auf die extrahierten Textdateien).

Vorab extrahierter Text kann schrittweise im Laufe der Zeit hinzugefügt werden. Bei der Textvorextraktion wird die Extraktion für zuvor extrahierte Binärdateien übersprungen. Daher ist es Best Practice, vorextrahierten Text beizubehalten, falls die Neuindizierung in Zukunft erneut erfolgen muss (vorausgesetzt, der extrahierte Inhalt ist nicht unnötig groß). Ziehen Sie sonst eine zwischenzeitliche Zip-Komprimierung des Inhalts in Betracht, da Text gut komprimiert werden kann.)

Indizieren Sie Oak-Indizes neu, indem Sie Volltext aus extrahierten Textdateien beziehen.

Führen Sie die Neuindizierung (Schritte 3a-b) während einer Wartungs-/Anwendungsdauer durch, da der Knotenspeicher während dieses Vorgangs durchlaufen wird, was zu einer erheblichen Belastung des Systems führen kann.

3a. Neuindizierung von Lucene-Indizes werden in AEM aufgerufen

3b. Die Apache Jackrabbit Oak DataStore PreExtractedTextProvider-OSGi-Konfiguration (zum Verweisen auf den extrahierten Text über einen Dateisystempfad) weist Oak an, Volltext aus den extrahierten Dateien zu beziehen, und vermeidet ein direktes Auffinden und Verarbeiten der im Repository gespeicherten Daten.