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 Implementierung angegeben werden. Konfigurationsänderungen in der Produktion verstoßen eindeutig gegen CI/CD-Richtlinien. Dasselbe gilt für Indexänderungen, da sie sich auf die Systemstabilität und -leistung auswirken können, wenn sie nicht speziell getestet werden, bevor sie in die Produktion aufgenommen werden.
Nachstehend finden Sie eine Liste der wichtigsten Änderungen im Vergleich zu AEM 6.5 und früheren Versionen:
Beschränkungen:
lucene
unterstützt.damAssetLucene
-Index geschrieben wurden, können auf Skyline tatsächlich für eine Elasticsearch-Version dieses Index ausgeführt werden. Dieser Unterschied ist für das Programm und die Benutzerinnen und Benutzer normalerweise nicht sichtbar, jedoch melden bestimmte Tools wie die explain
-Funktion einen anderen Index. Unterschiede zwischen Lucene-Indizes und Elastic-Indizes finden Sie unter die Elastic-Dokumentation in Apache Jackrabbit Oak. Elasticsearch-Indizes müssen und können vom Kunden nicht direkt konfiguriert werden.Eine Definition von Indizes kann die folgenden drei Anwendungsfälle umfassen:
Für die Punkte 1 und 2 müssen Sie als Teil Ihrer benutzerspezifischen 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.
Eine Indexdefinition kann Folgendes sein:
/oak:index/cqPageLucene-2
./oak:index/cqPageLucene-2-custom-1
./oak:index/acme.product-1-custom-2
. Um Namenskollisionen zu vermeiden, müssen vollständig benutzerdefinierte Indizes ein Präfix aufweisen, z. B. acme.
Beachten Sie, dass sowohl die Anpassung eines vordefinierten Index als auch vollständig benutzerdefinierte Indizes -custom-
enthalten müssen. Nur vollständig benutzerdefinierte Indizes müssen mit einem Präfix beginnen.
Wenn Sie beispielsweise einen vorkonfigurierten Index anpassen, z. B. damAssetLucene-6
, kopieren Sie bitte die neueste vorkonfigurierte Indexdefinition aus einer Cloud Service-Umgebung mithilfe des CRX DE Package Manager (/crx/packmgr/
). Benennen Sie dann die Konfiguration um, z. B. in damAssetLucene-6-custom-1
, und fügen Sie oben Ihre Anpassungen hinzu. Dadurch wird sichergestellt, dass erforderliche Konfigurationen nicht versehentlich entfernt werden. Beispiel: der Knoten tika
unter /oak:index/damAssetLucene-6/tika
ist im angepassten Index des Cloud-Service erforderlich. Er existiert nicht im Cloud-SDK.
Sie müssen ein neues Indexdefinitionspaket erstellen, das die tatsächliche Indexdefinition gemäß folgendem Benennungsmuster enthält:
<indexName>[-<productVersion>]-custom-<customVersion>
das dann unter ui.apps/src/main/content/jcr_root
aufgeführt werden muss. Alle angepassten und benutzerdefinierten Indexdefinitionen müssen unter /oak:index
gespeichert werden.
Der Filter für das Paket muss so festgelegt sein, dass vorhandene (vokonfigurierte Indizes) beibehalten werden. In der Datei ui.apps/src/main/content/META-INF/vault/filter.xml
muss jeder benutzerdefinierte (oder angepasste) Index aufgeführt werden, z. B. als <filter root="/oak:index/damAssetLucene-6-custom-1"/>
. Wenn die Indexversion später geändert wird, muss der Filter angepasst werden.
Für jedes Inhaltspaket, das Indexdefinitionen enthält, sollte die folgende Eigenschaft in der Eigenschaftendatei des Inhaltspakets unter /META-INF/vault/properties.xml
festgelegt sein:
noIntermediateSaves=true
Indexdefinitionen werden als benutzerdefiniert und versioniert gekennzeichnet:
/oak:index/ntBaseLucene-custom-1
)Um einen benutzerdefinierten oder angepassten Index bereitzustellen, muss die Indexdefinition (/oak:index/definitionname
) über ui.apps
über Git und den Cloud Manager-Implementierungsprozess bereitgestellt werden. Listen Sie im FileVault-Filter, z. B. ui.apps/src/main/content/META-INF/vault/filter.xml
, jeden benutzerdefinierten und angepassten Index einzeln auf, z. B. <filter root="/oak:index/damAssetLucene-7-custom-1"/>
. Die benutzerdefinierte/angepasste Indexdefinition selbst wird dannwie folgt in der Datei ui.apps/src/main/content/jcr_root/_oak_index/damAssetLucene-7-custom-1/.content.xml
gespeichert:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:oak="https://jackrabbit.apache.org/oak/ns/1.0" xmlns:dam="http://www.day.com/dam/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:rep="internal"
jcr:primaryType="oak:QueryIndexDefinition"
async="[async,nrt]"
compatVersion="{Long}2"
...
</indexRules>
<tika jcr:primaryType="nt:unstructured">
<config.xml jcr:primaryType="nt:file"/>
</tika>
</jcr:root>
Das obige Beispiel enthält eine Konfiguration für Apache Tika. Die Tika-Konfigurationsdatei würde unter ui.apps/src/main/content/jcr_root/_oak_index/damAssetLucene-7-custom-1/tika/config.xml
gespeichert.
Je nachdem, welche Version des Jackrabbit Filevault Maven Package-Plug-ins verwendet wird, ist eine weitere Konfiguration im Projekt erforderlich. Bei Verwendung der Jackrabbit Filevault Maven Package-Plug-in-Version 1.1.6 oder neuer, muss die Datei pom.xml
dann den folgenden Abschnitt in der Plug-in-Konfiguration für das filevault-package-maven-plugin
in configuration/validatorsSettings
(kurz vor jackrabbit-nodetypes
) enthalten:
<jackrabbit-packagetype>
<options>
<immutableRootNodeNames>apps,libs,oak:index</immutableRootNodeNames>
</options>
</jackrabbit-packagetype>
Außerdem muss in diesem Fall die vault-validation
-Version auf eine neuere Version aktualisiert werden:
<dependency>
<groupId>org.apache.jackrabbit.vault</groupId>
<artifactId>vault-validation</artifactId>
<version>3.5.6</version>
</dependency>
Dann muss bei der Konfiguration von filevault-package-maven-plugin
in ui.apps.structure/pom.xml
und ui.apps/pom.xml
sowohl allowIndexDefinitions
als auch noIntermediateSaves
aktiviert sein. Die Option noIntermediateSaves
stellt sicher, dass die Indexkonfigurationen automatisch hinzugefügt werden.
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<configuration>
<allowIndexDefinitions>true</allowIndexDefinitions>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
<noIntermediateSaves>true</noIntermediateSaves>
</properties>
...
In ui.apps.structure/pom.xml
muss der Abschnitt filters
für dieses Plug-in einen Filterstamm wie folgt enthalten:
<filter><root>/oak:index</root></filter>
Nachdem die neue Indexdefinition hinzugefügt wurde, muss das neue Programm über Cloud Manager bereitgestellt werden. Bei der Implementierung werden zwei Aufträge gestartet, die für das Hinzufügen (und gegebenenfalls das Zusammenführen) der Indexdefinitionen zu MongoDB und Azure Segment Store verantwortlich sind (für Erstellungs- bzw. Veröffentlichungszwecke). Die zugrunde liegenden Repositorys werden mit den neuen Indexdefinitionen neu indiziert, bevor die Blau/Grün-Umstellung stattfindet.
Wenn Sie bei der Validierung der Fehler folgende Fehlermeldung feststellen:
[ERROR] ValidationViolation: "jackrabbit-nodetypes: Mandatory child node missing: jcr:content [nt:base] inside node with types [nt:file]"
Anschließend kann einer der folgenden Schritte ausgeführt werden, um das Problem zu beheben:
<allowIndexDefinitions>true</allowIndexDefinitions>
Unten finden Sie ein Beispiel dafür, wo die oben beschriebene Konfiguration in den POM platziert werden soll.
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<configuration>
<properties>
...
</properties>
...
<allowIndexDefinitions>true</allowIndexDefinitions>
<repositoryStructurePackages>
...
</repositoryStructurePackages>
<dependencies>
...
</dependencies>
</configuration>
</plugin>
<isDisabled>true</isDisabled>
Unten finden Sie ein Beispiel dafür, wo die oben beschriebene Konfiguration in den POM platziert werden soll.
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
...
<configuration>
...
<validatorsSettings>
...
<jackrabbit-nodetypes>
<isDisabled>true</isDisabled>
</jackrabbit-nodetypes>
</validatorsSettings>
</configuration>
</plugin>
Weitere Informationen zur erforderlichen Paketstruktur für AEM as a Cloud Service finden Sie im Dokument AEM-Projektstruktur.
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.
Eine Blau/Grün-Implementierung kann Ausfallzeiten reduzieren. Sie ermöglicht Upgrades ohne Ausfallzeiten sowie schnelle Rollbacks. Die alte Version des Programms (blau) wird gleichzeitig mit der neuen Version des Programms (grün) ausgeführt.
Bestimmte Bereiche des Repositorys (schreibgeschützte Teile des Repositorys) können sich in der alten (blauen) und der neuen (grünen) Version des Programms 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.
Bei der Entwicklung oder bei Verwendung von lokalen Installationen können Indizes zur Laufzeit hinzugefügt, entfernt oder geändert werden. Indizes werden verwendet, sobald sie verfügbar sind. Wenn ein Index noch nicht in der alten Version des Programms verwendet werden soll, 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 sofort nach der Entfernung nicht mehr zur Verfügung.
Bei Blau/Grün-Implementierungen gibt es keine Ausfallzeiten. Während eines Upgrades werden für einige Zeit sowohl die alte Version (z. B. Version 1) des Programms 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 später entfernt werden, z. B. in Version 3. Ab diesem Zeitpunkt wird garantiert, dass Version 1 des Programms 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 können möglicherweise noch einige Zeit bleiben, 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.
<indexName>-custom-<customerVersionNumber>
ist erforderlich, damit AEM as a Cloud Service das als Ersatz für einen vorhandenen Index kennzeichnen kann.
Index | Vordefinierter Index | Verwendung in Version 1 | Verwendung in Version 2 |
---|---|---|---|
/oak:index/damAssetLucene | Ja | Ja | Nein |
/oak:index/damAssetLucene-custom-1 | Ja (angepasst) | Nein | Ja |
/oak:index/acme.product-custom-1 | Nein | Ja | Nein |
/oak:index/acme.product-custom-2 | Nein | Nein | Ja |
/oak:index/cqPageLucene | Ja | Ja | Ja |
Die Versionsnummer wird bei jeder Indexänderung inkrementiert. Um zu vermeiden, dass es zu Überschneidungen zwischen anwenderspezifischen Indexnamen und den Indexnamen des Produkts selbst kommt, müssen anwenderspezifische Indizes sowie Änderungen an vordefinierten Indizes mit -custom-<number>
enden.
Sobald Adobe einen vordefinierten Index wie „damAssetLucene“ oder „cqPageLucene“ ändert, wird ein neuer Index mit dem Namen damAssetLucene-2
oder cqPageLucene-2
erstellt; falls der Index bereits angepasst wurde, wird die benutzerdefinierte 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.
Index | Vordefinierter Index | Verwendung in Version 2 | Verwendung in Version 3 |
---|---|---|---|
/oak:index/damAssetLucene-custom-1 | Ja (angepasst) | Ja | Nein |
/oak:index/damAssetLucene-2-custom-1 | Ja (automatisch aus „damAssetLucene-custom-1“ und „damAssetLucene-2“ zusammengeführt) | Nein | Ja |
/oak:index/cqPageLucene | Ja | Ja | Nein |
/oak:index/cqPageLucene-2 | Ja | Nein | Ja |
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 Endbenutzer des Programms 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.
Um eine optimale Betriebsleistung zu erzielen, sollten Indizes nicht zu groß sein. Verwenden Sie die Gesamtgröße aller Indizes als Richtwert: Wenn sich diese um mehr als 100 % erhöht, nachdem benutzerdefinierte Indizes hinzugefügt und Standardindizes in einer Entwicklungsumgebung angepasst wurden, sollten benutzerdefinierte Indexdefinitionen angepasst werden. AEM as a Cloud Service kann die Implementierung von Indizes verhindern, die die Systemstabilität und -leistung negativ beeinflussen würden.
Um einen Index mit dem Namen /oak:index/acme.product-custom-1
hinzuzufügen, der in einer neuen Version des Programms 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 gezeigt, wird sichergestellt, dass der Index nur von der neuen Version des Programms verwendet wird.
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-custom-1
wird geändert. Der alte Index wird unter /oak:index/acme.product-custom-1
, der neue Index unter /oak:index/acme.product-custom-2
gespeichert.
Die alte Version des Programms nutzt die folgende Konfiguration:
/oak:index/acme.product-custom-1
Die neue Version des Programms nutzt die folgende (geänderte) Konfiguration:
/oak:index/acme.product-custom-2
Die Indexdefinitionen für AEM as a Cloud Service stimmen möglicherweise nicht vollständig mit den Indexdefinitionen für eine lokale Entwicklungsinstanz überein. Die Entwicklungsinstanz verfügt im Gegensatz zu AEM as a Cloud Service-Instanzen nicht über eine Tika-Konfiguration. Wenn Sie einen Index mit einer Tika-Konfiguration anpassen, behalten Sie die Tika-Konfiguration bei.
Manchmal muss eine Änderung der Indexdefinition rückgängig gemacht werden, etwa wenn eine Änderung versehentlich vorgenommen wurde oder aber nicht mehr erforderlich ist. Beispiel: Die Indexdefinition damAssetLucene-8-custom-3
wurde versehentlich erstellt und bereits bereitgestellt. Daher empfiehlt es sich, zur vorherigen Indexdefinition damAssetLucene-8-custom-2
zurückkehren. Dazu müssen Sie einen neuen Index namens damAssetLucene-8-custom-4
hinzufügen, der die Definition des vorherigen Index – damAssetLucene-8-custom-2
– enthält.
Nachfolgendes gilt nur für anwenderdefinierte Indizes. Produktindizes können nicht entfernt werden, da sie von AEM verwendet werden.
Wenn ein Index in einer späteren Version des Programms entfernt werden soll, können Sie einen leeren Index (einen leeren Index, der nie verwendet wird und keine Daten enthält) mit einem neuen Namen definieren. Für dieses Beispiels können Sie ihn /oak:index/acme.product-custom-3
nennen. Dadurch wird der Index /oak:index/acme.product-custom-2
ersetzt. Nachdem das System /oak:index/acme.product-custom-2
entfernt hat, kann auch der leere Index /oak:index/acme.product-custom-3
entfernt werden. Beispiel für einen solchen leeren Index:
<acme.product-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-custom-3>
Wenn eine Anpassung eines vordefinierten Index nicht mehr erforderlich ist, müssen Sie die vordefinierte Indexdefinition kopieren. Wenn Sie beispielsweise damAssetLucene-8-custom-3
bereits bereitgestellt haben, die Anpassungen jedoch nicht mehr benötigen und zum standardmäßigen damAssetLucene-8
-Index zurückwechseln möchten, müssen Sie einen damAssetLucene-8-custom-4
-Index hinzufügen, der die Indexdefinition von damAssetLucene-8
enthält.
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.