Inhaltssuche und -indizierung indexing

Änderungen in AEM as a Cloud Service changes-in-aem-as-a-cloud-service

Mit AEM as a Cloud Service stellt Adobe von einem AEM-Instanz-zentrierten Modell auf eine Service-basierte Ansicht mit n-x AEM-Containern um, unterstützt von CI/CD-Pipelines in Cloud Manager. Anstatt Indizes für einzelne AEM-Instanzen zu konfigurieren und zu verwalten, muss die Indexkonfiguration vor der Bereitstellung angegeben werden. Konfigurationsänderungen in der Produktion verstoßen gegen die CI/CD-Richtlinien. Dasselbe gilt für Indexänderungen, da diese die Systemstabilität und -leistung beeinträchtigen können, wenn sie nicht vor der Produktion spezifiziert, getestet und neu indiziert werden.

Nachstehend finden Sie eine Liste der wichtigsten Änderungen im Vergleich zu AEM 6.5 und früheren Versionen:

Beschränkungen:

Verwendung how-to-use

Indexdefinitionen können wie folgt in drei primäre Anwendungsfälle kategorisiert werden:

Für die Punkte 1 und 2 müssen Sie als Teil Ihrer benutzerdefinierten Code-Basis im jeweiligen Release-Plan für Cloud Manager eine neue Indexdefinition erstellen. Weitere Informationen finden Sie in der Dokumentation Bereitstellen in AEM as a Cloud Service.

Indexnamen index-names

Eine Indexdefinition kann in eine der folgenden Kategorien unterteilt werden:

Vorbereiten der neuen Indexdefinition preparing-the-new-index-definition

Bereiten Sie für Anpassungen eines vorkonfigurierten Index ein neues Paket vor, das die angepasste oder benutzerdefinierte Indexdefinition enthält. Der Indexname muss dem folgenden Benennungsmuster entsprechen:

<indexName>-<productVersion>-custom-<customVersion>

Bereiten Sie für einen vollständig angepassten Index ein neues Indexdefinitionspaket vor, das die Indexdefinition enthält und diesem Namensmuster folgt:

<prefix>.<indexName>-<productVersion>-custom-<customVersion>

Wie in den Abschnitten zu den Einschränkungen erwähnt, muss der type der angepassten Indexdefinition immer auf lucene festgelegt werden, auch wenn die extrahierte Indexdefinition unter Verwendung von Package Manager einen anderen Typ aufweist (z. B. elasticsearch).
Die Eigenschaft async muss ebenfalls geändert werden, wenn die extrahierte Indexdefinition auf elastic-async festgelegt ist. Die Eigenschaft async muss für die angepasste Indexdefinition auf eine der folgenden Eigenschaften festgelegt werden: [async], [async,nrt] oder [fulltext-async].

Bereitstellen benutzerdefinierter Indexdefinitionen deploying-custom-index-definitions

Für die Veranschaulichung der Bereitstellung einer angepassten Version des vordefinierten Indexes damAssetLucene-8 erhalten Sie eine schrittweise Anleitung. In diesem Beispiel werden wir ihn in damAssetLucene-8-custom-1 umbenennen. Dann läuft der Prozess wie folgt ab:

Projektkonfiguration

Wir empfehlen dringend, eine Version >= 1.3.2 des Jackrabbit filevault-package-maven-plugin zu verwenden. Die Schritte zur Integration in Ihr Projekt sind wie folgt:

Stellen Sie nach dem Hinzufügen der neuen Indexdefinition die neue Anwendung mithilfe von Cloud Manager bereit. Diese Bereitstellung startet zwei Aufträge, die für das Hinzufügen (und gegebenenfalls das Zusammenführen) der Indexdefinitionen zu MongoDB und Azure Segment Store verantwortlich sind (für Authoring- bzw. Publishing-Zwecke). Vor dem Wechsel werden die zugrunde liegenden Repositorys einer Neuindizierung mit den aktualisierten Indexdefinitionen unterzogen.

Indexverwaltung unter Verwendung von rollierenden Bereitstellungen index-management-using-rolling-deployments

Was ist Indexverwaltung? what-is-index-management

Bei der Indexverwaltung geht es darum, Indizes hinzuzufügen, zu entfernen und zu ändern. Eine Änderung der Definition eines Index geht schnell, doch die Anwendung der Änderung (häufig als „Erstellen eines Index“ oder bei vorhandenen Indizes als „Neuindizierung“ bezeichnet) erfordert Zeit. Das geht nicht sofort: Das Repository muss zunächst auf zu indizierende Daten geprüft werden.

Was sind rollierende Bereitstellungen? what-are-rolling-deployments

Eine rollierende Bereitstellung ermöglicht Upgrades ohne Ausfallzeiten sowie schnelle Rollbacks. Die alte Version der Anwendung wird gleichzeitig mit der neuen Version der Anwendung ausgeführt.

Schreibgeschützte Bereiche und Bereiche mit Lese-Schreib-Zugriff read-only-and-read-write-areas

Bestimmte Bereiche des Repositorys (schreibgeschützte Teile des Repositorys) können sich in der alten und der neuen Version der Anwendung unterscheiden. Die schreibgeschützten Bereiche des Repositorys sind in der Regel /app und /libs. Im folgenden Beispiel wird Kursivschrift verwendet, um schreibgeschützte Bereiche zu markieren, während Fettschrift für Bereiche mit Lese-Schreib-Zugriff steht.

Die Bereiche mit Lese- und Schreibzugriff des Repositorys werden von allen Versionen des Programms gemeinsam genutzt, während es für jede Version des Programms einen spezifischen Satz von /apps und /libs gibt.

Indexverwaltung ohne rollierende Bereitstellungen index-management-without-rolling-deployments

Bei der Entwicklung oder bei Verwendung von lokalen Installationen können Indizes zur Laufzeit hinzugefügt, entfernt oder geändert werden. Indizes werden verwendet, wenn sie verfügbar sind. Wenn ein Index nicht schon in der alten Version der Anwendung verwendet wird, wird der Index normalerweise während einer geplanten Ausfallzeit erstellt. Dasselbe gilt, wenn ein Index entfernt oder ein vorhandener Index geändert wird. Wenn Sie einen Index entfernen, steht er nach der Entfernung nicht mehr zur Verfügung.

Indexverwaltung mit rollierenden Bereitstellungen index-management-with-rolling-deployments

Bei rollierenden Bereitstellungen gibt es keine Ausfallzeiten. Während einer Aktualisierung werden sowohl die alte Version (z. B. Version 1) der Anwendung als auch die neue Version (Version 2) gleichzeitig für dasselbe Repository ausgeführt. Wenn für Version 1 ein bestimmter Index verfügbar sein muss, darf dieser Index in Version 2 nicht entfernt werden. Der Index sollte erst später entfernt werden, z. B. in Version 3. Ab diesem Zeitpunkt ist garantiert, dass Version 1 der Anwendung nicht mehr ausgeführt wird. Außerdem sollten Programme so geschrieben werden, dass Version 1 gut funktioniert, auch wenn Version 2 ausgeführt wird und Indizes von Version 2 verfügbar sind.

Nach Abschluss der Aktualisierung auf die neue Version können alte Indizes vom System entfernt werden. Die alten Indizes bleiben typischerweise noch eine Woche bestehen, um Rollbacks zu beschleunigen (falls ein Rollback erforderlich sein sollte).

Die folgende Tabelle zeigt fünf Indexdefinitionen: der Index cqPageLucene wird in beiden Versionen verwendet, während der Index damAssetLucene-custom-1 nur in Version 2 zum Einsatz kommt.

Die Versionsnummer wird bei jeder Indexänderung inkrementiert. Um zu vermeiden, dass benutzerspezifische Indexnamen mit den Indexnamen des Produkts selbst kollidieren, müssen benutzerdefinierte Indizes und Änderungen an vordefinierten Indizes mit -custom-<number> enden.

Änderungen an vordefinierten Indizes changes-to-out-of-the-box-indexes

Nachdem Adobe einen vordefinierten Index wie damAssetLucene oder cqPageLucene ändert, wird ein neuer Index mit dem Namen damAssetLucene-2 oder cqPageLucene-2 erstellt. Oder wenn der Index bereits angepasst wurde, wird die angepasste Indexdefinition mit den Änderungen im vordefinierten Index zusammengeführt, wie unten dargestellt. Die Zusammenführung von Änderungen erfolgt automatisch. Das bedeutet, dass Sie nichts tun müssen, wenn sich ein vordefinierter Index ändert. Der Index lässt sich jedoch später erneut anpassen. In diesem Fall ist es wichtig, die neueste (zusammengeführte) Version als Baseline zu verwenden.

Beachten Sie, dass sich Umgebungen in verschiedenen AEM-Versionen befinden können. Beispiel: Die Umgebung dev befindet sich in Version X+1, während sich die Staging- und Produktionsumgebung noch in Version X befinden und darauf warten, auf Version X+1 aktualisiert zu werden, nachdem die erforderlichen Tests für dev durchgeführt wurden. Wenn Version X+1 mit einer neueren Version eines Produktindexes geliefert wird, der angepasst wurde, und eine neue Anpassung dieses Indexes erforderlich ist, wird in der folgenden Tabelle erläutert, welche Versionen für Umgebungen basierend auf der AEM-Version festgelegt werden müssen:

Aktuelle Einschränkungen current-limitations

Die Indexverwaltung wird derzeit nur für Indizes des Typs lucene unterstützt, wobei compatVersion auf 2 gesetzt ist. Intern können andere Indizes konfiguriert und für Abfragen verwendet werden, z. B. Elasticsearch-Indizes. Sie können Abfragen, die gegen den damAssetLucene-Index geschrieben werden, auf AEM as a Cloud Service tatsächlich für eine Elasticsearch-Version dieses Indexes ausführen. Dieser Unterschied ist für die Anwenderinnen und Anwender nicht sichtbar. Bestimmte Tools wie die explain-Funktion melden jedoch einen anderen Index. Unterschiede zwischen Lucene- und Elasticsearch-Indizes finden Sie in der Elasticsearch-Dokumentation in Apache Jackrabbit Oak. Elasticsearch-Indizes können und müssen nicht direkt konfiguriert werden.

Es werden nur integrierte Analyzer unterstützt (d. h. diejenigen, die mit dem Produkt geliefert werden). Benutzerdefinierte Analyzer werden nicht unterstützt.

Derzeit wird die Indizierung der Inhalte von /oak:index nicht unterstützt.

Um eine optimale Betriebsleistung zu erzielen, sollten Indizes nicht zu groß sein. Die Gesamtgröße aller Indizes kann als Richtwert dienen. Wenn diese Größe um mehr als 100 % zunimmt, nachdem benutzerdefinierte Indizes hinzugefügt und Standardindizes in einer Entwicklungsumgebung angepasst wurden, sollten benutzerdefinierte Indexdefinitionen angepasst werden. AEM as a Cloud Service kann die Bereitstellung von Indizes verhindern, die die Systemstabilität und -leistung negativ beeinflussen würden, oder solche entfernen.

Hinzufügen eines Index adding-an-index

Um einen Index mit dem Namen /oak:index/acme.product-1-custom-1 hinzuzufügen, der in einer neuen Version der Anwendung und höher verwendet werden soll, muss der Index wie folgt konfiguriert werden:

acme.product-1-custom-1

Dies funktioniert, indem dem Indexnamen eine benutzerdefinierte Kennung vorangestellt wird, gefolgt von einem Punkt (.). Die Kennung muss zwischen 2 und 5 Zeichen lang sein.

Wie oben wird durch diese Konfiguration sichergestellt, dass der Index nur von der neuen Version der Anwendung verwendet wird.

Ändern eines Index changing-an-index

Wenn ein vorhandener Index geändert wird, muss ein neuer Index mit der geänderten Indexdefinition hinzugefügt werden. Angenommen, der vorhandene Index /oak:index/acme.product-1-custom-1 wird geändert. Der alte Index wird unter /oak:index/acme.product-1-custom-1, der neue Index unter /oak:index/acme.product-1-custom-2 gespeichert.

Die alte Version des Programms nutzt die folgende Konfiguration:

/oak:index/acme.product-1-custom-1

Die neue Version des Programms nutzt die folgende (geänderte) Konfiguration:

/oak:index/acme.product-1-custom-2

Rückgängigmachen einer Änderung undoing-a-change

Manchmal ist es erforderlich, eine Änderung in einer Indexdefinition rückgängig zu machen, z. B. aufgrund eines Fehlers oder weil die Änderung nicht mehr erforderlich ist. Wenn z. B. die Indexdefinition damAssetLucene-8-custom-3 einen Fehler enthält, empfiehlt es sich möglicherweise, zur vorherigen Definition damAssetLucene-8-custom-2 zurückzukehren. Erstellen Sie dazu einen neuen Index mit dem Namen damAssetLucene-8-custom-4, der eine Kopie des vorherigen Index ist, damAssetLucene-8-custom-2.

Entfernen eines Index removing-an-index

Folgendes gilt nur für Anpassungen von vorkonfigurierten Indizes und vollständig benutzerdefinierten Indizes. Beachten Sie, dass die ursprünglichen vorkonfigurierten Indizes nicht entfernt werden können, da sie von AEM verwendet werden.

Um die Systemintegrität und -stabilität sicherzustellen, sollten Indexdefinitionen nach der Bereitstellung als unveränderlich behandelt werden. Wenn Sie einen benutzerdefinierten Index oder eine benutzerdefinierte Anpassung entfernen müssen, erstellen Sie eine neue Version dieses Index mit einer Definition, die die Entfernung effektiv simuliert
(siehe Beispiele unten).

Sobald eine neue Version eines Index bereitgestellt wurde, wird die ältere Version desselben Index nicht mehr von Abfragen verwendet.
Die ältere Version wird nicht sofort aus der Umgebung gelöscht.
Die Speicherbereinigung wird jedoch durch einen Bereinigungsmechanismus ermöglicht, der regelmäßig ausgeführt wird.
Nach einer Nachfrist, die eine Wiederherstellung im Falle von Fehlern ermöglicht
(derzeit 7 Tage ab dem Zeitpunkt, zu dem die Indizierung entfernt wurde, Änderungen sind jedoch möglich),
löscht dieser Bereinigungsmechanismus die nicht verwendeten Indexdaten
und deaktiviert oder entfernt die alte Version des Index aus der Umgebung.

Im Folgenden beschreiben wir die beiden möglichen Fälle: Entfernen der Anpassungen eines vorkonfigurierten Index und Entfernen eines vollständig benutzerdefinierten Index.

Entfernen der Anpassungen eines vordefinierten Index

Führen Sie die unter Rückgängigmachen einer Änderung beschriebenen Schritte aus. Verwenden Sie dabei die Definitionen des vorkonfigurierten Index als neue Version. Wenn Sie beispielsweise damAssetLucene-8-custom-3 bereits bereitgestellt haben, die Anpassungen jedoch nicht mehr benötigen und zum standardmäßigen Index damAssetLucene-8 zurückwechseln möchten, müssen Sie einen Index damAssetLucene-8-custom-4 hinzufügen, der die Indexdefinition von damAssetLucene-8 enthält.

Entfernen eines vollständig benutzerdefinierten Index

Führen Sie die unter Rückgängigmachen einer Änderung beschriebenen Schritte aus. Verwenden Sie dabei einen Platzhalterindex als neue Version. Ein Platzhalterindex wird nie für Abfragen verwendet und enthält keine Daten, sodass der Effekt derselbe ist, als ob der Index nicht vorhanden wäre. Sie können ihn beispielsweise /oak:index/acme.product-1-custom-3 nennen. Dadurch wird der Index /oak:index/acme.product-1-custom-2 ersetzt. Beispiel für einen solchen Platzhalterindex:

<acme.product-1-custom-3
        jcr:primaryType="oak:QueryIndexDefinition"
        async="async"
        compatVersion="2"
        includedPaths="/dummy"
        queryPaths="/dummy"
        type="lucene">
        <indexRules jcr:primaryType="nt:unstructured">
            <rep:root jcr:primaryType="nt:unstructured">
                <properties jcr:primaryType="nt:unstructured">
                    <dummy
                        jcr:primaryType="nt:unstructured"
                        name="dummy"
                        propertyIndex="{Boolean}true"/>
                </properties>
            </rep:root>
        </indexRules>
</acme.product-1-custom-3>

Index- und Abfrageoptimierung index-query-optimizations

Apache Jackrabbit Oak ermöglicht flexible Indexkonfigurationen zur effizienten Verarbeitung von Suchabfragen. Indizes sind besonders für größere Repositorys wichtig. Stellen Sie sicher, dass alle Abfragen durch einen geeigneten Index gestützt werden. Bei Abfragen ohne geeigneten Index können Tausende von Knoten gelesen werden. Bei einem solchen Vorgang wird eine Warnung protokolliert.

Beachten Sie dieses Dokument für Informationen zur Optimierung von Abfragen und Indizes.