In diesem Artikel wird die Konfiguration von Indizes in AEM 6 beschrieben. Informationen zur besten Vorgehensweise beim Optimieren von Abfragen- und Indizierungsleistung finden Sie unter Best Practices für Abfragen und Indizierung.
Anders als bei Jackrabbit 2 wird Inhalt in Oak nicht standardmäßig indiziert. Indizes müssen daher bei Bedarf vom Benutzer erstellt werden, ähnlich wie bei herkömmlichen relationalen Datenbanken. Falls für eine spezifische Abfrage kein Index vorhanden ist, werden möglicherweise viele Knoten durchsucht. Die Abfrage kann zwar erfolgreich sein, wird jedoch sehr langsam verarbeitet.
Falls Oak eine nicht indizierte Abfrage findet, wird eine Protokollmeldung der Stufe WARNUNG ausgegeben:
*WARN* Traversed 1000 nodes with filter Filter(query=select ...) consider creating an index or changing the query
Die Abfrage-Engine von Oak unterstützt folgende Sprachen:
Beim auf Apache Oak basierenden Backend können mehrere Indexer als Plug-in für das Repository verwendet werden.
Ein Indexer ist der Eigenschaften-Index, dessen Indexdefinition im Repository gespeichert wird.
Implementierungen für Apache Lucene und Solr sind ebenfalls standardmäßig verfügbar und unterstützen die Volltextindizierung.
Der Traversalindex wird verwendet, wenn kein anderer Indexer verfügbar ist. Dies bedeutet, dass der Inhalt nicht indiziert ist und Inhaltsknoten durchsucht werden, um Übereinstimmungen mit der Abfrage zu finden.
Wenn mehrere Indexer für eine Abfrage verfügbar sind, berechnet jeder verfügbare Indexer die voraussichtlichen Kosten für das Ausführen der Abfrage. Oak wählt dann den Indexer mit den niedrigsten geschätzten Kosten aus.
Das obige Diagramm ist eine Übersicht über den Abfragevorgang von Apache Oak.
Zuerst wird die Abfrage in eine abstrakte Syntaxstruktur analysiert. Dann wird die Abfrage überprüft und in SQL-2, die native Sprache für Oak-Abfragen, umgewandelt.
Im nächsten Schritt werden von jedem Index die voraussichtlichen Kosten für die Abfrage berechnet. Anschließend werden die Ergebnisse des billigsten Index abgerufen. Diese Ergebnisse werden gefiltert, um sicherzustellen, dass der aktuelle Benutzer Schreibzugriff auf diese hat und sie mit der abgeschlossenen Abfrage übereinstimmen.
Hinweis: Bei großen Repositorys ist das Erstellen eines Index ein zeitaufwändiger Vorgang. Dies gilt sowohl für das erstmalige Erstellen des Index als auch für eine Neuindizierung (Neuerstellung des Index nach einer Änderung der Definition). Weitere Informationen finden Sie im Beitrag zur Fehlerbehebung in Oak-Indizes in dem Abschnitt, der Maßnahmen gegen eine langsame Neuindizierung beschreibt.
Wenn sehr große Repositorys neu indiziert werden müssen, insbesondere wenn MongoDB verwendet wird und eine Volltextindizierung erforderlich ist, empfiehlt es sich gegebenenfalls, vorab eine Textvorextraktion durchzuführen und den Ausgangsindex mit „oak-run“ zu erstellen und anschließend eine Neuindizierung durchzuführen.
Indizes sind im Repository als Knoten unter dem Knoten oak:index konfiguriert.
Der Typ des Indexknotens muss oak:QueryIndexDefinition lauten. Für jeden Indexer sind diverse Konfigurationsoptionen als Knoteneigenschaften verfügbar. Weitere Informationen finden Sie in den Konfigurationsdetails für jeden Indexer-Typ unten.
Der Eigenschaften-Index ist für Abfragen mit Eigenschaftenbeschränkungen und ohne Volltext geeignet. Der Index kann wie folgt konfiguriert werden:
Öffnen Sie CRXDE, indem Sie zu http://localhost:4502/crx/de/index.jsp
gehen.
Erstellen Sie einen neuen Knoten unter oak:index.
Nennen Sie den Knoten PropertyIndex und legen Sie als Knotentyp oak:QueryIndexDefinition fest.
Legen Sie die folgenden Eigenschaften für den neuen Knoten fest:
property
(vom Typ Zeichenfolge)jcr:uuid
(vom Typ „Name“)Bei diesem Beispiel wird die Eigenschaft jcr:uuid
indiziert, die dazu dient, die UUID (Universally Unique Identifier) des verknüpften Knotens anzuzeigen.
Speichern Sie die Änderungen.
Beim Eigenschaften-Index sind folgende Konfigurationsoptionen verfügbar:
Die Eigenschaft type gibt den Indextyp an und muss in diesem Fall property lauten.
Die Eigenschaft propertyNames gibt eine Liste der Eigenschaften an, die im Index gespeichert werden. Falls diese Eigenschaft fehlt, wird der Knotenname als Referenzwert des Eigenschaftennamen verwendet. In diesem Beispiel dient die Eigenschaft jcr:uuid dazu, die UUID (Universally Unique Identifier) des verknüpften Knotens anzuzeigen.
Falls für die Kennzeichnung unique der Wert true festgelegt ist, wird dadurch eine Eindeutigkeitsbeschränkung auf den Eigenschaften-Index angewendet.
Mit der Eigenschaft declaringNodeTypes können Sie einen bestimmten Knotentyp angeben, der für den Index gilt.
Falls für die Kennzeichnung Neuindizierung der Wert auf true festgelegt ist, wird eine vollständige Neuindizierung des Inhalts ausgelöst.
Der geordnete Index ist eine Erweiterung des Eigenschaften-Index. Er ist allerdings veraltet. Indizes dieses Typs müssen durch den Lucene-Eigenschaften-Index ersetzt werden.
AEM 6 beinhaltet einen auf Apache Lucene basierten Indexer.
Falls ein Volltext-Index konfiguriert ist, wird dieser für alle Abfragen mit Volltext-Bedingung verwendet, unabhängig davon, ob andere indizierte Bedingungen gelten oder ob eine Pfadbeschränkung besteht.
Falls kein Volltext-Index konfiguriert ist, werden Abfragen mit Volltext-Bedingungen nicht wie erwartet verarbeitet.
Da der Index über einen asynchronen Hintergrund-Thread aktualisiert wird, sind bestimmte Volltextsuchen für einen kurzen Zeitraum nicht verfügbar, bis die Prozesse im Hintergrund beendet sind.
Sie können einen Lucene-Volltext-Index wie folgt konfigurieren:
Öffnen Sie CRXDE und erstellen Sie einen neuen Knoten unter oak:index.
Nennen Sie den Knoten LuceneIndex und legen Sie als Knotentyp oak:QueryIndexDefinition fest.
Fügen Sie dem Knoten folgende Eigenschaften hinzu:
lucene
(vom Typ Zeichenfolge)async
(vom Typ Zeichenfolge)Speichern Sie die Änderungen.
Für den Lucene-Index sind folgende Konfigurationsoptionen verfügbar:
Ab Oak 1.0.8 kann Lucene zum Erstellen von Indizes mit Eigenschaftenbeschränkungen ohne Volltext verwendet werden.
Um einen Lucene-Eigenschaften-Index zu erhalten, muss für die Eigenschaft fulltextEnabled immer „false“ festgelegt sein.
Sehen wir uns folgende Beispielabfrage an:
select * from [nt:base] where [alias] = '/admin'
Um einen Lucene-Eigenschaften-Index für die obige Abfrage zu definieren, können Sie folgende Definition hinzufügen, indem Sie unter oak:index: einen neuen Knoten erstellen.
LucenePropertyIndex
oak:QueryIndexDefinition
Sobald der Knoten erstellt wurde, fügen Sie die folgenden Eigenschaften hinzu:
Typ:
lucene (of type String)
asynchron:
async (of type String)
fulltextEnabled:
false (of type Boolean)
includePropertyNames: ["alias"] (of type String)
Verglichen mit dem normalen Eigenschaften-Index ist der Lucene-Eigenschaften-Index immer im asynchronen Modus konfiguriert. Daher entsprechen die vom Index ausgegebenen Ergebnisse möglicherweise nicht immer dem aktuellen Stand des Repositorys.
Weitere Informationen zum Lucene-Eigenschaften-Index finden Sie auf der Dokumentationsseite zu Apache Jackrabbit Oak Lucene.
Ab Version 1.2.0 unterstützt Oak Lucene-Analyzer.
Analyzer werden zum Indizieren von Dokumenten und für Abfragen verwendet. Ein Analyzer überprüft den Text von Feldern und generiert einen Token-Stream. Lucene-Analyzer beinhalten eine Reihe von Tokenizern und Filterklassen.
Die Analyzer können über den Knoten analyzers
(vom Typ nt:unstructured
) in der Definition oak:index
konfiguriert werden.
Der Standard-Analyzer für einen Index wird im untergeordneten Knoten default
des Analyzer-Knotens konfiguriert.
Eine Liste der verfügbaren Analyzer finden Sie in der API-Dokumentation der Lucene-Version, die Sie verwenden.
Falls Sie einen vorkonfigurierten Analyzer verwenden möchten, können Sie diesen wie folgt konfigurieren:
Suchen Sie im Knoten oak:index
nach dem Index, mit dem Sie den Analyzer verwenden möchten.
Erstellen Sie unter dem Index einen untergeordneten Knoten default
vom Typ nt:unstructured
.
Fügen Sie dem Knoten „default“ eine Eigenschaft mit folgenden Eigenschaften hinzu:
class
String
org.apache.lucene.analysis.standard.StandardAnalyzer
Der Wert ist der Name der Analyzer-Klasse, die Sie verwenden möchten.
Sie können auch einen Analyzer für eine bestimmte Lucene-Version festlegen, indem Sie die optionale String-Eigenschaft luceneMatchVersion
verwenden. Eine gültige Syntax für die Verwendung mit Lucene 4.7 sieht wie folgt aus:
luceneMatchVersion
String
LUCENE_47
Wenn luceneMatchVersion
nicht angegeben ist, verwendet Oak die im Lieferumfang enthaltene Version von Lucene.
Wenn Sie eine Stoppwörter-Datei zu Analyzer-Konfigurationen hinzufügen möchten, können Sie einen neuen Knoten unter dem Knoten default
mit folgenden Eigenschaften erstellen:
stopwords
nt:file
Analyzer können auch anhand der Eigenschaften Tokenizers
, TokenFilters
und CharFilters
zusammengestellt werden. Geben Sie dazu einen Analyzer an und erstellen Sie untergeordnete Knoten der optionalen Tokenizer und Filter, die in der aufgelisteten Reihenfolgen angewendet werden. Siehe auch https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#Specifying_an_Analyzer_in_the_schema
Sehen Sie sich diese Knotenstruktur als Beispiel an:
Name: analyzers
Name: default
Name: charFilters
Typ: nt:unstructured
HTMLStrip
Mapping
Name: tokenizer
Eigenschaftsname: name
String
Standard
Name: filters
Typ: nt:unstructured
Name: LowerCase
Name: Stop
Eigenschaftsname: words
String
stop1.txt, stop2.txt
Name: stop1.txt
nt:file
Name: stop2.txt
nt:file
Der Name der Filter „charFilters“ und „tokenizers“ wird durch Entfernen der Factory-Suffixe gebildet. Das heißt:
org.apache.lucene.analysis.standard.StandardTokenizerFactory
wird zu standard
org.apache.lucene.analysis.charfilter.MappingCharFilterFactory
wird zu Mapping
org.apache.lucene.analysis.core.StopFilterFactory
wird zu Stop
Für die Factory erforderliche Konfigurationsparameter werden als Eigenschaft des entsprechenden Knotens angegeben.
In Fällen wie beim Laden von Stoppwörtern, bei denen Inhalt aus externem Dateien geladen werden muss, kann der Inhalt als untergeordneter Knoten vom Typ nt:file
für die betroffene Datei bereitgestellt werden.
Der Solr-Index dient der Volltextsuche. Er kann jedoch auch für die Index-Suche nach Pfad, Eigenschaften- und Primärtyp-Beschränkungen verwendet werden. Der Solr-Index kann also in Oak für praktisch jeden Typ von JCR-Abfrage eingesetzt werden.
Die Integration in AEM erfolgt auf Repository-Ebene, damit Solr als möglicher Index in Oak, der neuen mit AEM ausgelieferten Repository-Implementierung, verwendet werden kann.
Es kann so konfiguriert werden, dass es als Remote-Server mit der AEM-Instanz funktioniert.
AEM kann auch mit einer Remote-Solr-Server-Instanz konfiguriert werden:
Laden Sie die neueste Version von Solr herunter und extrahieren Sie diese. Weitere Informationen zur Vorgehensweise finden Sie in der Dokumentation zur Apache Solr-Installation.
Erstellen Sie zwei Solr-Shards. Erstellen Sie dazu Ordner für jedes Shard in dem Ordner, in den Solr entpackt wurde:
<solrunpackdirectory>\aemsolr1\node1
<solrunpackdirectory>\aemsolr2\node2
Suchen Sie die Beispiel-Instanz im Solr-Paket. Sie befindet sich in der Regel im Ordner example
im Stammverzeichnis des Pakets.
Kopieren Sie die folgenden Ordner von der Beispiel-Instanz in die Ordner der zwei Shards (aemsolr1\node1
und aemsolr2\node2
):
contexts
etc
lib
resources
scripts
solr-webapp
webapps
start.jar
Erstellen Sie in jedem der beiden Shard-Ordner einen neuen Ordner mit dem Namen cfg
.
Speichern Sie die Solr- und ZooKeeper-Konfigurationsdateien in den neu erstellten cfg
-Ordnern.
Weitere Informationen zur Solr- und ZooKeeper-Konfiguration finden Sie in der Dokumentation zur Solr-Konfiguration bzw. im ZooKeeper-Handbuch „Erste Schritte“.
Starten Sie den ersten Shard mit ZooKeeper-Unterstützung, indem Sie zu aemsolr1\node1
wechseln und folgenden Befehl ausführen:
java -Xmx2g -Dbootstrap_confdir=./cfg/oak/conf -Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar
Starten Sie den zweiten Shard, indem Sie zu aemsolr2\node2
wechseln und folgenden Befehl ausführen:
java -Xmx2g -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
Wenn Sie beide Shards gestartet haben, testen Sie die ordnungsgemäße Funktion, indem Sie eine Verbindung zur Solr-Schnittstelle unter http://localhost:8983/solr/#/
/#/ herstellen.
Starten Sie AEM und wechseln Sie zur Web-Konsole unter http://localhost:4502/system/console/configMgr
Legen Sie folgende Konfiguration unter Oak Solr remote server configuration fest:
http://localhost:8983/solr/
Wählen Sie Remote Solr in der Dropdown-Liste unter dem Serveranbieter Oak Solr aus.
Wechseln Sie zu CRXDE und melden Sie sich mit „Admin“ an.
Erstellen Sie einen neuen Knoten mit dem Namen solrIndex unter oak:index und legen Sie folgende Eigenschaften fest:
Speichern Sie die Änderungen.
Unten sehen Sie ein Beispiel für eine Grundkonfiguration, die mit allen drei Solr-Bereitstellungen verwendet werden kann, die in diesem Artikel beschrieben sind. Diese Konfiguration basiert auf den dedizierten Eigenschaften-Indizes, die bereits in AEM vorhanden sind, und sollte nicht mit anderen Anwendungen verwendet werden.
Für die richtige Verwendung müssen Sie die Inhalte im Archiv direkt im Solr-Basisverzeichnis speichern. Bei Bereitstellungen mit mehreren Knoten muss der Inhalt direkt in den Stammorder der einzelnen Knoten gespeichert werden.
Empfohlene Solr-Konfigurationsdateien
In AEM 6.1 sind auch zwei Indizierungs-Tools aus AEM 6.0 integriert, die Teil der Adobe Consulting Services Commons-Tools sind:
Sie können diese Tools aufrufen, indem Sie vom AEM-Begrüßungsbildschirm zu Tools > Vorgänge > Dashboard > Diagnose navigieren.
Weitere Informationen zur Verwendung der Tools finden Sie in der Dokumentation zum Vorgangs-Dashboard.
Das ACS Commons-Paket enthält auch OSGi-Konfigurationen, die zum Erstellen von Eigenschaften-Indizes verwendet werden können.
Sie können über die Web-Konsole darauf zugreifen, indem Sie nach „Ensure Oak Property Index“ suchen.
Unter Umständen dauert die Ausführung von Abfragen sehr lange und die allgemeine Systemreaktion ist langsam.
In diesem Abschnitt werden einige Empfehlungen gegeben, wie Sie vorgehen sollten, um die Ursache dieser Probleme zu finden und diese zu beheben.
Am einfachsten erhalten Sie die erforderlichen Informationen zu der ausgeführten Abfrage anhand des Explain Query-Tools. Mit diesem Tool können Sie genaue Informationen zum Debuggen einer langsamen Abfrage erfassen, ohne Protokolldaten einsehen zu müssen. Dies ist hilfreich, wenn Sie wissen, welche Abfrage debuggt werden soll.
Falls dies aus irgendeinem Grund nicht möglich ist, können Sie die Indizierungsprotokolle in einer Datei zusammenfassen und diese zum Beheben des spezifischen Problems verwenden.
Um die Protokollierung zu aktivieren, müssen Sie Protokolle auf DEBUG-Ebene für die Kategorien aktivieren, die für Oak-Indizierung und -Abfragen gelten. Diese Kategorien sind:
Die Kategorie com.day.cq.search gilt nur, wenn Sie das von AEM bereitgestellte QueryBuilder-Dienstprogramm verwenden.
Es ist wichtig, für Protokolle nur für die Dauer der problematischen Abfrage, die Sie debuggen, DEBUG festzulegen, da andernfalls über einen längeren Zeitraum sehr viele Ereignisse in den Protokollen erzeugt werden. Daher sollten Sie, sobald Sie die erforderlichen Protokolle erfasst haben, für die Protokollierung der oben genannten Kategorien wieder INFO festlegen.
Sie können die Protokollierung wie folgt aktivieren:
https://serveraddress:port/system/console/slinglog
verweisen.logs/queryDebug.log
an. Dadurch werden alle DEBUG-Ereignisse in einer Protokolldatei zusammengefasst.Ausschlaggebend für die Bewertung einer Abfrage ist die Indexkonfiguration. Es ist wichtig, die Indexkonfiguration abzurufen, um diese zu analysieren oder an den Support zu senden. Sie können die Konfiguration als Inhaltspaket oder als JSON-Ausgabe abrufen.
Da die Indexkonfiguration in den meisten Fällen unter dem Knoten /oak:index
in CRXDE gespeichert ist, können Sie die JSON-Version unter folgender Adresse abrufen:
https://serveraddress:port/oak:index.tidy.-1.json
Falls sich die Indexkonfiguration an einem anderen Speicherort befindet, ändern Sie den Pfad entsprechend.
In einigen Fällen ist es hilfreich, die Ausgabe Index-spezifischer MBeans für das Debuggen bereitzustellen. Gehen Sie dazu wie folgt vor:
Wechseln Sie zur JMX-Konsole unter:
https://serveraddress:port/system/console/jmx
Suchen Sie nach folgenden MBeans:
Klicken Sie auf die einzelnen MBeans, um die Leistungsstatistiken anzuzeigen. Erstellen Sie einen Screenshot oder halten Sie die Daten fest, falls Sie diese an den Support weitergeben müssen.
Sie können auch die JSON-Version dieser Statistiken unter folgenden URLs abrufen:
https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak/%2522LuceneIndex%2522.tidy.-1.json
https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak/%2522LuceneIndex%2522.tidy.-1.json
https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak/%2522LuceneIndex%2522.tidy.-1.json
https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak/%2522LuceneIndex%2522.tidy.-1.json
Sie können die konsolidierte JMX-Ausgabe auch über https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak.tidy.3.json
bereitstellen. Hierdurch werden alle Oak-spezifischen MBean-Details im JSON-Format erfasst.
Sie können zusätzliche Informationen sammeln, die die Problembehebung erleichtern können, zum Beispiel:
org.apache.jackrabbit.oak-core
-Bundle überprüfen.https://serveraddress:port/libs/cq/search/content/querydebug.html
aufgerufen werden.