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 wurden alle Inhalte standardmäßig indiziert und konnten frei abgefragt werden. In Oak müssen Indizes manuell unter dem Knoten oak:index
erstellt werden. Eine Abfrage kann ohne Index ausgeführt werden. Bei großen Datensätzen wird sie jedoch langsam ausgeführt oder sogar abgebrochen.
In diesem Artikel wird beschrieben, wann Indizes erstellt werden müssen und wann diese nicht benötigt werden. Außerdem werden Tricks zum Vermeiden von unnötigen Abfragen sowie Tipps zur Optimierung Ihrer Indizes und Abfragen für eine möglichst optimale Leistung beschrieben.
Lesen Sie auch die Oak-Dokumentation zum Schreiben von Abfragen und Indizes. 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.
Bei der Erstellung der Taxonomie eines Repositorys müssen mehrere Faktoren berücksichtigt werden. Dazu gehören unter anderem Zugriffssteuerungen, Lokalisierung, Komponenten und die Vererbung von 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 Durchlauffähigkeit die Fähigkeit einer Taxonomie, einen vorhersehbaren Zugriff auf Inhalte auf der Grundlage ihres Pfads zu ermöglichen. Dies ermöglicht ein leistungsfähigeres System, das leichter zu verwalten ist als ein System, das viele Abfragen erfordert.
Bei der Erstellung einer Taxonomie ist es wichtig zu überlegen, ob die Reihenfolge wichtig ist. In Fällen, in denen keine explizite Reihenfolge erforderlich ist und viele Geschwisterknoten erwartet werden, wird empfohlen, einen ungeordneten Knotentyp zu verwenden, z. B. sling:Folder
oder oak:Unstructured
. In den Fällen, in denen eine Bestellung erforderlich ist, nt:unstructured
, und sling:OrderedFolder
besser geeignet sind.
Da Abfragen eine der steuerpflichtigeren Vorgänge in einem AEM sein können, ist es empfehlenswert, sie in Ihren Komponenten zu vermeiden. Wenn beim Rendern einer Seite mehrere Abfragen gleichzeitig ausgeführt werden, kann dies 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.
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 mit Elementen einer Kategorie aufzufüllen.
Besser wäre es allerdings, diesen Inhalt in einer Taxonomie nach Kategorie zu strukturieren, damit er manuell abgerufen werden kann.
Angenommen, der Inhalt wird in einer Taxonomie wie der folgenden gespeichert:
/content/myUnstructuredContent/parentCategory/childCategory/contentPiece
Die /content/myUnstructuredContent/parentCategory/childCategory
-Knoten können einfach abgerufen werden, 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 auch 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.
Mitunter lassen die Inhalte oder Anforderungen im Zusammenhang mit der Komponente nicht zu, dass Knoten zum Abrufen der erforderlichen Daten durchlaufen werden. In solchen Fällen müssen die erforderlichen Abfragen vor dem Rendern der Komponente ausgeführt werden, damit eine optimale Leistung für die Endbenutzenden sichergestellt werden kann.
Sofern die für die Komponente erforderlichen Ergebnisse zum Zeitpunkt der Erstellung ermittelt werden können und nicht von einer Änderung des Inhalts auszugehen ist, kann die Abfrage ausgeführt werden, wenn der Autor oder die Autorin 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 in 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.
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, erstellen Sie einen Index. 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.
Nach dem Ändern einer Indexdefinition muss der Index neu erstellt (neu indiziert) werden. Je nach Größe des Index kann es einige Zeit dauern, bis dies erfolgt ist.
Beim Ausführen komplexer Abfragen kann es Fälle geben, in denen es effizienter ist, die Abfrage in mehrere kleinere Abfragen aufzuteilen und die Daten später mithilfe von Code zusammenzuführen. Für solche Fälle wird empfohlen, die Leistung der beiden Ansätze miteinander zu vergleichen, um die für den jeweiligen Anwendungsfall besser geeignete Option zu ermitteln.
In AEM können Abfragen mit einer der drei folgenden Methoden geschrieben werden:
Zwar werden alle Abfragen vor der Ausführung in SQL2 konvertiert, jedoch ist der Mehraufwand durch die Abfragenkonvertierung nur minimal. Daher stehen beim Auswählen einer Abfragesprache in erster Linie die Lesbarkeit und der Komfort für das Entwicklungs-Team im Vordergrund.
Bei Verwendung von QueryBuilder wird die Ergebnisanzahl standardmäßig ermittelt, die in Oak im Vergleich zu früheren Jackrabbit-Versionen langsamer ist. Um dies zu kompensieren, können Sie den Parameter guessTotal verwenden.
Wie bei jeder 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. Es wird eine Warnung angezeigt, wenn die Abfrage Probleme mit einem großen Repository und einer langen Laufzeit sowie mit den verwendeten Indizes verursacht. Das Tool kann auch eine Liste langsamer und gängiger Abfragen laden, die dann erläutert und optimiert werden können.
Um weitere Informationen darüber zu erhalten, wie Oak den zu verwendenden Index auswählt und wie das Abfragemodul eine Abfrage tatsächlich ausführt, kann für die folgenden Pakete eine DEBUG-Protokollierungskonfiguration hinzugefügt werden:
Entfernen Sie diese Protokollfunktion, wenn Sie das Debugging Ihrer Abfrage abgeschlossen haben. Es gibt tendenziell eine große Menge an Aktivität aus und kann schließlich Ihre Festplatte mit Protokolldateien füllen.
Weitere Informationen hierzu finden Sie in der Dokumentation zur Protokollierung.
Lucene registriert ein JMX-Bean, das Details zum indizierten Inhalt enthält, einschließlich Größe und Anzahl der in jedem Index vorhandenen Dokumente.
Ein Zugriff ist über die JMX-Konsole unter https://server:port/system/console/jmx
möglich.
Wenn Sie bei der JMX-Konsole angemeldet sind, suchen Sie nach Lucene-Indexstatistiken, um es zu finden. Weitere Indexstatistiken finden Sie im MBean IndexStats.
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 in der 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
Während der Entwicklung
Setzen Sie niedrige Schwellenwerte für oak.queryLimitInMemory
(z. B. 10000) und Oak. queryLimitReads
(z. B. 5000) und optimieren Sie die teure Abfrage, wenn Sie auf eine UnsupportedOperationException-Ausnahme klicken, die besagt: "Die Abfrage liest mehr als x Knoten…"
Auf diese Weise lassen sich ressourcenintensive Abfragen vermeiden (d. h. nicht durch einen Index unterlegt oder durch einen Index mit geringerer Abdeckung unterlegt). 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.
Überwachen Sie die Protokolle auf Abfragen, die eine hohe Anzahl durchlaufener Knoten oder einen hohen Heap-Speicherverbrauch auslösen:
*WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.
Überwachen Sie die Protokolle auf Abfragen, die einen hohen Heap-Speicherverbrauch auslösen:
*WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped
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:
-Doak.queryLimitInMemory=500000
-Doak.queryLimitReads=100000
In AEM 6.3 sind die beiden oben genannten Parameter vorkonfiguriert OOTB und können über die OSGi QueryEngineSettings beibehalten werden.
Weitere Informationen finden Sie unter: https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limits
Die erste Frage, die beim Erstellen oder Optimieren von Indizes gestellt werden muss, ist, ob sie für eine bestimmte Situation erforderlich sind. Wenn Sie eine Abfrage nur einmal oder gelegentlich außerhalb der systembezogenen Stoßzeiten durch einen Batch-Prozess ausführen, kann es besser sein, auf die Indexerstellung komplett zu verzichten.
Wenn ein Index erstellt wurde, muss mit jeder Aktualisierung der indizierten Daten auch der Index aktualisiert werden. Da dies Auswirkungen auf die Leistung des Systems hat, sollten Indizes nur erstellt werden, wenn sie erforderlich sind.
Außerdem sind Indizes nur nützlich, wenn die im Index enthaltenen Daten eindeutig genug sind, um sie zu rechtfertigen. Denken Sie in diesem Zusammenhang an einen Index in einem Buch und die Themen, die er abdeckt: Beim Indizieren einer Reihe von Themen in einem Text gibt es in der Regel Hunderte oder Tausende von Einträgen, mit denen Sie schnell zu einer Untergruppe von Seiten springen können, 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 nützlich. Dasselbe Konzept gilt für Datenbankindizes. Wenn es nur einige eindeutige Werte gibt, ist der Index nicht nützlich. Trotzdem kann ein Index auch zu groß werden, um nützlich zu sein. Informationen zu Indexstatistiken finden Sie weiter oben unter Indexstatistiken.
Lucene-Indizes wurden in Oak 1.0.9 eingeführt und bieten einige Optimierungsvarianten, die gegenüber den bei der Ersteinführung von AEM 6 enthaltenen Eigenschaftenindizes leistungsstärker sind. Bei der Entscheidung zwischen Lucene-Indizes oder Eigenschaftenindizes sollten die folgenden Aspekte berücksichtigt werden:
Im Allgemeinen wird empfohlen, Lucene-Indizes zu verwenden, es sei denn, es besteht eine zwingende Notwendigkeit, Eigenschaftenindizes zu verwenden, damit Sie von höherer Leistung und Flexibilität profitieren können.
AEM unterstützt zudem standardmäßig die Solr-Indizierung. Dies wird zur Unterstützung der Volltextsuche verwendet, kann aber auch zur Unterstützung beliebiger JCR-Abfragen verwendet werden. Solr sollte in Betracht gezogen werden, wenn die CPU-Kapazität der AEM-Instanzen nicht für die benötigte Anzahl an Anfragen in suchintensiven Bereitstellungen wie suchgesteuerten Websites mit einer hohen Anzahl gleichzeitiger Benutzerinnen und Benutzer ausreicht. 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 eingebettet auf dem AEM-Server für Entwicklungsumgebungen ausgeführt werden, oder sie können auf 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 wird daher nicht empfohlen, es sei denn, dies ist erforderlich. Weitere Informationen zum Konfigurieren einer Solr-Integration und zum Erstellen von Solr-Indizes finden Sie in der Dokumentation zu Oak-Abfragen und -Indizierung.
Der integrierte Solr-Suchansatz ermöglicht es, die Indizierung auf einen Solr-Server auszulagern. Wenn die erweiterten Funktionen des Solr-Servers durch einen Crawler-basierten Ansatz verwendet werden, ist eine zusätzliche Konfiguration erforderlich.
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 Suchvorgänge auf eine solche Art und Weise externalisiert werden sollen, muss besonders darauf geachtet werden, dass den Benutzerinnen und Benutzern nur die für sie vorgesehenen Ergebnisse angezeigt werden.
Mögliche Anwendungsfälle, in denen dieser Ansatz sinnvoll sein kann, sind etwa Fälle, in denen Suchdaten aus mehreren Quellen aggregiert werden müssen. Sie können beispielsweise eine Site auf AEM gehostet und eine zweite Site auf einer Drittanbieterplattform gehostet werden. Solr könnte so konfiguriert werden, dass der Inhalt beider Sites durchsucht und in einem aggregierten Index gespeichert wird. Dies würde Site-übergreifende Suchvorgänge ermöglichen.
In der Oak-Dokumentation für Lucene-Indizes sind verschiedene Überlegungen aufgeführt, die beim Design von Indizes angestellt werden sollten:
Wenn die Abfrage unterschiedliche Pfadbeschränkungen verwendet, verwenden Sie evaluatePathRestrictions
. Dadurch kann die Abfrage die Teilmenge der Ergebnisse unter dem angegebenen Pfad zurückgeben und sie dann anhand der Abfrage filtern. Andernfalls sucht die Abfrage nach allen Ergebnissen, die mit den Abfrageparametern im Repository übereinstimmen, und filtert sie dann anhand des Pfads.
Wenn für die Abfrage die Sortierfunktion verwendet wird, ist eine explizite Eigenschaftendefinition erforderlich. Außerdem müssen Sie ordered
auf true
setzen. Dadurch können die Ergebnisse als solche im Index sortiert und bei der Ausführung der Abfrage bei kostspieligen Sortiervorgängen gespeichert werden.
Nehmen Sie nur das in den Index auf, was erforderlich ist. Das Hinzufügen nicht benötigter Funktionen oder Eigenschaften führt dazu, dass der Index wächst und die Leistung verlangsamt.
In einem Eigenschaftenindex trägt ein eindeutiger Eigenschaftsname dazu bei, die Indexgröße zu reduzieren, aber für Lucene-Indizes sollten nodeTypes
und mixins
zum Erstellen kohäsiver Indizes verwendet werden. Die Abfrage nach einem bestimmten nodeType
oder mixin
ist leistungsstärker als eine nt:base
-Abfrage. Definieren Sie bei diesem Ansatz indexRules
für die fraglichen nodeTypes
.
Wenn Ihre Abfragen nur unter bestimmten Pfaden ausgeführt werden, erstellen Sie diese Indizes unter diesen Pfaden. Indizes müssen nicht im Stammverzeichnis des Repositorys gespeichert werden.
Es wird empfohlen, einen einzigen Index zu verwenden, wenn alle zu indizierenden Eigenschaften miteinander zusammenhängen, damit Lucene so viele Eigenschaftseinschränkungen wie möglich nativ bewerten kann. Außerdem verwendet eine Abfrage nur einen Index, auch wenn ein Join ausgeführt wird.
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. Hierdurch kann sich die Leistung bei Abfragen, die häufig mit diesen Remote-Indizes ausgeführt werden, verbessern.
Dies kann in der OSGi-Konsole unter dem Dienst LuceneIndexProvider konfiguriert werden und ist standardmäßig ab Oak 1.0.13 aktiviert.
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. Ein Index wird bei Deaktivierung nicht aktualisiert, 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 Eigenschaftenindex 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 in einer MongoDB-Instanz verhält sich der Löschaufwand 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 mit einem Tool wie oak-mongo.js zu löschen. Beachten Sie, dass dieser Ansatz nicht für reguläre Knoteninhalte verwendet werden sollte, da er zu Dateninkonsistenzen führen kann.
Weitere Informationen zu oak-mongo.js finden Sie im Abschnitt zu den Befehlszeilen-Tools der Oak-Dokumentation.
Um die Erstellung effizienter JCR-Abfragen und Indexdefinitionen zu unterstützen, kann die JCR-Abfrage-Schnellübersicht heruntergeladen und während der Entwicklung als Referenz verwendet werden. Sie enthält Beispielabfragen für QueryBuilder, XPath und SQL-2, die mehrere Szenarien abdecken, welche sich hinsichtlich der Abfrageleistung unterschiedlich verhalten. Sie enthält auch Empfehlungen zum Erstellen oder Anpassen von Oak-Indizes. Der Inhalt dieser Schnellübersicht gilt für AEM 6.5 und AEM as a Cloud Service.
In diesem Abschnitt werden die only akzeptable Gründe für die Neuindizierung von Oak-Indizes.
Außerhalb der unten aufgeführten Gründe bewirkt das Initiieren von Neuindizes von Oak-Indizes Folgendes: not das Verhalten ändern oder Probleme beheben und unnötigerweise die Belastung der AEM erhöhen.
Eine Neuindizierung von Oak-Indizes ist zu vermeiden, es sei denn, dies wird durch einen Grund in den unten stehenden Tabellen erläutert.
Bevor Sie die unten stehenden Tabellen durchsuchen, um festzustellen, ob eine Neuindizierung nützlich ist, always verify:
Die einzigen akzeptablen, nicht fehlenden Bedingungen für die Neuindizierung von Oak-Indizes sind, wenn sich die Konfiguration eines Oak-Index geändert hat.
Die Neuindizierung sollte immer unter gebührender Berücksichtigung der Auswirkungen auf die Gesamtleistung AEM und in Zeiten geringer Aktivität oder Wartungsfenster durchgeführt werden.
Im Folgenden finden Sie Details zu möglichen Problemen sowie entsprechende Lösungen:
Gilt für folgende Fälle:
Symptome:
So kann dies überprüft werden:
jcr:created
oder jcr:lastModified
aller fehlenden Knoten im Hinblick auf die Änderungszeit des Index.Beheben des Problems:
Reindex Lucene-Index
Alternativ können Sie einen Schreibvorgang ohne Auswirkungen für den fehlenden Knoten durchführen.
Gilt für folgende Fälle:
Symptome:
So kann dies überprüft werden:
diffStoredIndexDefinition
.Beheben des Problems:
Oak-Versionen vor 1.6:
Oak-Versionen ab 1.6:
Wenn der vorhandene Inhalt von den Änderungen nicht betroffen ist, ist nur eine Aktualisierung erforderlich
Andernfalls reindex Lucene-Index
In der folgenden Tabelle werden die einzigen akzeptablen Fehler- und Ausnahmesituationen beschrieben, in denen die Neuindizierung von Oak-Indizes das Problem beheben kann.
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:
Gilt für folgende Fälle:
Symptome:
So kann dies überprüft werden:
Beheben des Problems:
Durchführen einer Repository-Durchlauf-Prüfung; Beispiel:
http://localhost:4502/system/console/repositorycheck
Durch das Durchlaufen des Repositorys wird bestimmt, ob andere Binärdateien (außer Lucene-Dateien) fehlen.
Wenn andere Binärdateien als Lucene-Indizes fehlen, stellen Sie diese anhand einer Sicherung wieder her.
Andernfalls reindex all Lucene-Indizes
Hinweis:
Diese Bedingung ist ein Hinweis auf einen falsch konfigurierten Datenspeicher, der dazu führen kann, dass ANY-Binärdateien (z. B. Asset-Binärdateien) fehlen.
Stellen Sie in diesem Fall die letzte einwandfreie Version des Repositorys wieder her, um alle fehlenden Binärdateien wiederzugewinnen.
Gilt für folgende Fälle:
Symptome:
So kann dies überprüft werden:
Die AsyncIndexUpdate
(alle fünf Sekunden) schlägt mit einer Ausnahme in error.log fehl:
...a Lucene index file is corrupt...
Beheben des Problems:
Entfernen Sie die lokale Kopie des Lucene-Index.
crx-quickstart/repository/index
.Wenn das Problem hierdurch nicht behoben wird und die AsyncIndexUpdate
-Ausnahmen bestehen bleiben, gehen Sie wie folgt vor:
In AEM 6.5 oak-run.jar ist die EINZIGE unterstützte Methode für die Neuindizierung in MongoMK- oder RDBMK-Repositorys.
Verwendung oak-run.jar Neuindizieren des Eigenschaftenindex
Stellen Sie im Eigenschaftenindex die Eigenschaft „reindex-async“ auf „true“ ein:
[oak:queryIndexDefinition]@reindex-async=true
Asynchrone Neuindizierung des Eigenschaftenindex mithilfe der Web-Konsole über die PropertyIndexAsyncReindex MBean;
Beispiel,
Verwendung oak-run.jar zu reindex den Lucene-Eigenschaftsindex.
Stellen Sie im Lucene-Eigenschaftsindex
[oak:queryIndexDefinition]@reindex-async=true
Im vorherigen Abschnitt werden die Anleitungen zur Neuindizierung von Oak aus der Apache Oak-Dokumentation im Rahmen von AEM.
Bei der Textvorextraktion wird Text aus Binärdateien direkt aus dem Datenspeicher über einen isolierten Prozess extrahiert und verarbeitet, und der extrahierte Text wird direkt für nachfolgende Neuindizierungen von Oak-Indizes offengelegt.
/oak:index/damAssetLucene
.Neuindizieren einer vorhandene Lucene-Index mit aktivierter Binärextraktion
Unterstützung bei der Bereitstellung eines neuen Lucene-Index in AEM mit aktivierter Binärdateiextraktion
Die Textvorextraktion kann nicht für neue Inhalte verwendet werden, die zum Repository hinzugefügt werden, dies ist aber auch nicht notwendig.
Neue Inhalte, die dem Repository hinzugefügt werden, werden nämlich automatisch und schrittweise durch die asynchrone Volltextindizierung indiziert (standardmäßig alle 5 Sekunden).
Bei normalem AEM-Betrieb, etwa beim Hochladen von Assets über die Web-Benutzeroberfläche oder bei der programmgesteuerten Aufnahme von Assets, führt AEM eine automatische und schrittweise Volltextindizierung des neuen Binärinhalts durch. Da die Datenmenge inkrementell und relativ klein ist (in etwa die Datenmenge, die in 5 Sekunden in das Repository persistiert werden kann), kann AEM während der Indizierung eine Volltextextraktion aus den Binärdateien durchführen, ohne die Gesamtleistung des Systems zu beeinträchtigen.
Sie werden einen Lucene-Index neu indizieren, der eine Volltext-Binärextrahierung durchführt, oder einen neuen Index bereitstellen, der Volltext-Indexbinärdateien vorhandener Inhalte enthält
Die Inhalte (Binärdateien) für die Textextraktion müssen sich im Repository befinden.
Ein Wartungsfenster zum Generieren der CSV-Datei UND zum Ausführen der endgültigen Neuindizierung
Die folgenden Oak-Versionen müssen verwendet werden: 1.0.18 oder höher, 1.2.3 oder höher.
Die folgende oak-run.jar-Version muss verwendet werden: 1.7.4 oder höher.
Ordner/Freigabe eines Dateisystems zum Speichern des extrahierten Texts, auf den über die Indizierungs-AEM zugegriffen werden kann
Die unten beschriebenen oak-run.jar-Befehle finden Sie vollständig aufgeführt unter https://jackrabbit.apache.org/oak/docs/query/pre-extract-text.html.
Die obige Grafik und die darunter stehenden Schritte erläutern und ergänzen die in der Apache Oak-Dokumentation dargelegten technischen Schritte zur Textvorextraktion.
Generieren einer Inhaltsliste für die Vorextraktion
Führen Sie Schritt 1 (a-b) während eines Wartungsfensters/einer Zeitspanne mit geringer Nutzung aus, da der Knotenspeicher während dieses Vorgangs durchlaufen wird, was zu einer erheblichen Belastung des Systems führen kann.
1a. Ausführen oak-run.jar --generate
, um eine Liste von Knoten zu erstellen, deren Text vorab extrahiert wird.
1b. Die Liste der Knoten (1a) wird im Dateisystem als CSV-Datei gespeichert
Der gesamte Knotenspeicher wird jedes Mal durchlaufen (wie durch die Pfade im oak-run-Befehl angegeben). --generate
ausgeführt wird und eine new Die CSV-Datei wird erstellt. Die CSV-Datei lautet not wird zwischen diskreten Ausführungen des Textvorextraktionsprozesses wiederverwendet (Schritte 1 bis 2).
Vorextrahieren von Text für das Dateisystem
Schritt 2 (a-c) kann während des normalen Betriebs von AEM ausgeführt werden, da lediglich eine Interaktion mit dem Datenspeicher stattfindet.
2a. Ausführen oak-run.jar --tika
, um Text für die in der CSV-Datei, die in (1b) generiert wurde, aufgezählten Binärknoten vorab zu extrahieren.
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. Extrahierter Text wird im Dateisystem in einem Format gespeichert, das vom Oak-Neuindizierungsprozess (3a) erfasst 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 über mehrere AEM-Instanzen hinweg verwendet werden. Da AEM Veröffentlichung normalerweise eine Untergruppe von AEM Author ist, kann der vorab extrahierte Text aus AEM Author häufig auch zur Neuindizierung AEM Publish verwendet werden (vorausgesetzt, die AEM Publish haben Zugriff auf das Dateisystem der extrahierten Textdateien).
Vorextrahierter Text kann im Laufe der Zeit schrittweise hinzugefügt werden. Bei der Textvorextraktion wird die Extraktion für zuvor extrahierte Binärdateien übersprungen. Daher empfiehlt es sich, vorab extrahierten Text beizubehalten, falls in Zukunft eine Neuindizierung erforderlich ist (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.)
Neuindizieren von Oak-Indizes, Abrufen von Volltext aus extrahierten Textdateien
Führen Sie die Neuindizierung (Schritte 3a-b) während einer Wartungs-/Nutzungsperiode durch, da der Knotenspeicher während dieses Vorgangs durchlaufen wird, was eine erhebliche Belastung des Systems verursachen kann.
3a. Reindex 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.