Innehållssökning och indexering indexing

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

Med AEM as a Cloud Service går Adobe från en instanscentrerad AEM-modell till en tjänstebaserad vy med n-x AEM Containers, som drivs av CI/CD-ledningar i Cloud Manager. I stället för att konfigurera och underhålla index för enskilda AEM-instanser måste indexkonfigurationen anges före en distribution. Konfigurationsförändringar i produktionen bryter mot CI/CD-principer. Samma sak gäller för indexändringar, eftersom det kan påverka systemets stabilitet och prestanda om det inte anges, testas och omindexeras innan de börjar produceras.

Nedan finns en lista över de viktigaste ändringarna jämfört med AEM 6.5 och tidigare versioner:

Begränsningar:

Använda how-to-use

Indexdefinitioner kan kategoriseras i tre primära användningsområden:

För båda punkterna 1 och 2 ovan måste du skapa en indexdefinition som en del av din anpassade kodbas i respektive Cloud Manager-releaseplan. Mer information finns i dokumentationen för Distribuera till AEM as a Cloud Service.

Indexnamn index-names

En indexdefinition kan delas in i någon av följande kategorier:

Förbereder den nya indexdefinitionen preparing-the-new-index-definition

Om du vill anpassa ett OOTB-index förbereder du ett nytt paket som innehåller den anpassade eller anpassade indexdefinitionen. Indexnamnet måste följa namngivningsmönstret:

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

Om du vill skapa ett helt anpassat index skapar du ett nytt indexdefinitionspaket som innehåller indexdefinitionen som följer namnmönstret:

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

Som vi nämnt i avsnittet om begränsningar måste type för den anpassade indexdefinitionen alltid anges till lucene även om den extraherade indexdefinitionen med hjälp av Package Manager är av en annan typ (t.ex. elasticsearch).
Egenskapen async måste också ändras om den extraherade indexdefinitionen är inställd på elastic-async. Egenskapen async måste anges till något av följande: [async], [async,nrt] eller [fulltext-async] för den anpassade indexdefinitionen.

Distribuera anpassade indexdefinitioner deploying-custom-index-definitions

För att illustrera distributionen av en anpassad version av det körklara indexet damAssetLucene-8 kommer vi att tillhandahålla en steg-för-steg-guide. I det här exemplet byter vi namn på det till damAssetLucene-8-custom-1. Sedan är processen följande:

Projektkonfiguration

Vi rekommenderar starkt att du använder version >= 1.3.2 av Jackrabbit filevault-package-maven-plugin. Så här implementerar du den i ditt projekt:

När du har lagt till den nya indexdefinitionen distribuerar du det nya programmet med Cloud Manager. Distributionen initierar två jobb som ansvarar för att lägga till (och sammanfoga om det behövs) indexdefinitionerna i MongoDB och Azure Segment Store för författare respektive publicering. Före bytet omindexeras de underliggande databaserna med de uppdaterade indexdefinitionerna.

Indexhantering med rullande distributioner index-management-using-rolling-deployments

Vad är indexhantering? what-is-index-management

Indexhantering handlar om att lägga till, ta bort och ändra index. Det går snabbt att ändra definition för ett index, men det tar lång tid att tillämpa ändringen (kallas ofta"skapa ett index" eller"omindexering" för befintliga index). Det är inte omedelbart: databasen måste genomsökas för att data ska kunna indexeras.

Vad är rullande distributioner? what-are-rolling-deployments

Med en rullande driftsättning kan du uppgradera utan driftavbrott och få snabba återställningar. Den gamla versionen av programmet körs samtidigt som den nya versionen av programmet.

Skrivskyddade och skrivskyddade områden read-only-and-read-write-areas

Vissa delar av databasen (skrivskyddade delar av databasen) kan vara olika i den gamla och den nya versionen av programmet. De skrivskyddade områdena i databasen är vanligtvis /app och /libs. I följande exempel används kursiv för att markera skrivskyddade områden, medan fetstil används för skrivskyddade områden.

Databasens läs- och skrivområden delas mellan alla programversioner, medan det för varje programversion finns en specifik uppsättning av /apps och /libs.

Indexhantering utan rullande distributioner index-management-without-rolling-deployments

Under utvecklingen, eller när du använder lokala installationer, kan index läggas till, tas bort eller ändras under körningen. Index används när de är tillgängliga. Om ett index ännu inte används i den gamla versionen av programmet skapas det vanligtvis under en schemalagd driftstopp. Samma sak händer när du tar bort ett index eller ändrar ett befintligt index. När du tar bort ett index blir det otillgängligt när det tas bort.

Indexhantering med rullande distributioner index-management-with-rolling-deployments

Med rullande driftsättningar sker inga driftavbrott. Under en uppdatering körs både den gamla versionen (till exempel version 1) av programmet och den nya versionen (version 2) samtidigt mot samma databas. Om version 1 kräver att ett visst index är tillgängligt får detta index inte tas bort i version 2. Indexet bör tas bort senare, t.ex. i version 3, där det är garanterat att version 1 av programmet inte längre körs. Dessutom bör program skrivas så att version 1 fungerar bra, även om version 2 körs, och om det finns index för version 2.

När uppgraderingen till den nya versionen är klar kan gamla index samlas in av systemet. De gamla indexen stannar vanligtvis i en vecka för att påskynda återställningen (om en återställning behövs).

Följande tabell visar fem indexdefinitioner: index cqPageLucene används i båda versionerna medan index damAssetLucene-custom-1 bara används i version 2.

Versionsnumret ökas stegvis varje gång indexvärdet ändras. För att undvika att egna indexnamn kolliderar med indexnamnen för själva produkten måste anpassade index och ändringar i körklara index sluta med -custom-<number>.

Ändringar av färdiga index changes-to-out-of-the-box-indexes

När Adobe har ändrat ett index som inte finns i kartongen, som damAssetLucene eller cqPageLucene, skapas ett nytt index med namnet damAssetLucene-2 eller cqPageLucene-2. Om indexet redan har anpassats sammanfogas den anpassade indexdefinitionen med ändringarna i det körklara indexet, vilket visas nedan. Ändringarna sammanfogas automatiskt. Det innebär att du inte behöver göra något om ett index som inte finns i kartongen ändras. Det går dock att anpassa indexet igen senare. I det här fallet är det viktigt att använda den senaste versionen (den sammanslagna) som baslinje.

Det är viktigt att tänka på att miljöer kan finnas i olika AEM-versioner. Miljön dev är till exempel på version X+1 medan scenen och produkten fortfarande är på version X och väntar på att uppgraderas till version X+1 efter att obligatoriska tester på dev har utförts. Om releasen X+1 innehåller en nyare version av ett produktindex som har anpassats och en ny anpassning av det indexet krävs, kommer följande tabell att förklara vilka versioner som behöver ställas in i miljöer baserade på AEM-versionen:

Aktuella begränsningar current-limitations

Indexhantering stöds bara för index av typen lucene, med compatVersion inställt på 2. Internt kan andra index konfigureras och användas för frågor, till exempel Elasticsearch-index. Frågor som skrivs mot indexet damAssetLucene kan i AEM as a Cloud Service köras mot en Elasticsearch-version av det här indexet. Den här skillnaden är osynlig för programanvändaren, men vissa verktyg som funktionen explain rapporterar ett annat index. Skillnader mellan index för Lucene och Elasticsearch finns i Elasticsearch-dokumentationen i Apache Jackrabbit Oak. Kunder kan inte och behöver inte konfigurera Elasticsearch-index direkt.

Endast inbyggda analysatorer stöds (det vill säga analysatorer som levereras tillsammans med produkten). Anpassade analysatorer stöds inte.

Indexering av innehållet i /oak:index stöds inte för närvarande.

För bästa prestanda bör index inte vara alltför stora. Den totala storleken för alla index kan användas som vägledning. Om den här storleken ökar med mer än 100 % efter att anpassade index har lagts till och standardindex har justerats i en utvecklingsmiljö, bör anpassade indexdefinitioner justeras. AEM as a Cloud Service kan förhindra att index som skulle påverka systemets stabilitet och prestanda distribueras eller tas bort.

Lägga till ett index adding-an-index

Om du vill lägga till ett helt anpassat index med namnet /oak:index/acme.product-1-custom-1, som ska användas i en ny version av programmet och senare, måste indexet konfigureras på följande sätt:

acme.product-1-custom-1

Den här konfigurationen fungerar genom att en anpassad identifierare försätts i indexnamnet, följt av en punkt (.). Identifieraren ska vara mellan 2 och 5 tecken lång.

Som ovan säkerställer den här konfigurationen att indexet bara används av den nya versionen av programmet.

Ändra ett index changing-an-index

När ett befintligt index ändras måste ett nytt index läggas till med den ändrade indexdefinitionen. Anta till exempel att det befintliga indexet /oak:index/acme.product-1-custom-1 har ändrats. Det gamla indexet lagras under /oak:index/acme.product-1-custom-1 och det nya indexet lagras under /oak:index/acme.product-1-custom-2.

I den gamla versionen av programmet används följande konfiguration:

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

I den nya versionen av programmet används följande (ändrade) konfiguration:

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

Ångra en ändring undoing-a-change

Ibland kan det vara nödvändigt att ångra en ändring i en indexdefinition, till exempel på grund av ett fel eller på grund av att ändringen inte längre behövs. Om indexdefinitionen damAssetLucene-8-custom-3 till exempel innehåller ett fel kan du återgå till den tidigare definitionen, damAssetLucene-8-custom-2. För att uppnå detta skapar du ett nytt index med namnet damAssetLucene-8-custom-4 som är en kopia av det tidigare indexet, damAssetLucene-8-custom-2.

Ta bort ett index removing-an-index

Följande gäller endast för anpassningar av OTB-index (out-of-the-box) och helt anpassade index. Observera att de ursprungliga OOTB-indexen inte kan tas bort eftersom de används av AEM.

För att säkerställa systemets integritet och stabilitet bör indexdefinitioner behandlas som oföränderliga när de väl har distribuerats. Om du behöver ta bort ett anpassat index eller en anpassning skapar du en ny version av indexet med en definition som simulerar borttagningen
(se exemplen nedan).

När en ny version av ett index distribueras kommer den äldre versionen av samma index inte längre att användas av frågor.
Den äldre versionen tas inte bort omedelbart från miljön,
men kommer att bli berättigad till skräpinsamling genom en rensningsmekanism som körs regelbundet.
Efter en frist som är avsedd att återvinnas vid misstag
(för närvarande 7 dagar räknat från när indexeringen togs bort, men kan komma att ändras),
denna rensningsmekanism kommer att ta bort oanvända indexdata,
och inaktiverar eller tar bort den gamla versionen av indexet från miljön.

Här nedan beskrivs de två möjliga fallen: ta bort anpassningar av ett OOTB-index och ta bort ett helt anpassat index.

Ta bort anpassningar av ett körklart index

Följ stegen som beskrivs i Ångra en ändring med definitionerna för OTB-indexet som den nya versionen. Om du till exempel redan har distribuerat damAssetLucene-8-custom-3, men inte längre behöver anpassningarna och vill växla tillbaka till standardindexvärdet damAssetLucene-8, måste du lägga till ett index damAssetLucene-8-custom-4 som innehåller indexdefinitionen damAssetLucene-8.

Ta bort ett helt anpassat index

Följ stegen som beskrivs i Ångra en ändring med ett indexvärde som ny version. Ett "dummy"-index används aldrig för frågor och innehåller inga data, så effekten är densamma som om indexet inte fanns. I det här exemplet kan du ge det namnet /oak:index/acme.product-1-custom-3. Det här namnet ersätter indexet /oak:index/acme.product-1-custom-2. Ett exempel på ett sådant index är:

<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>

Optimeringar av index och frågor index-query-optimizations

Med Apache Jackrabbit Oak kan du hantera sökfrågor effektivt med hjälp av flexibla indexkonfigurationer. Index är särskilt viktiga för större databaser. Se till att alla frågor backas upp av ett lämpligt index. Frågor utan lämpligt index kan läsa tusentals noder, som sedan loggas som en varning.

Mer information om hur frågor och index kan optimeras finns i det här dokumentet.