Aanbevolen werkwijzen voor query en indexering query-and-indexing-best-practices

In AEM as a Cloud Service worden alle operationele aspecten met betrekking tot indexering geautomatiseerd. Op deze manier kunnen ontwikkelaars zich richten op het maken van efficiënte query's en de bijbehorende indexdefinities.

Wanneer moet u query's gebruiken? when-to-use-queries

Zoekopdrachten zijn een manier om toegang te krijgen tot inhoud, maar niet de enige mogelijkheid. In veel situaties kan inhoud in de opslagplaats effectiever worden benaderd met andere middelen. U zou moeten nadenken als de vragen de beste en meest efficiënte manier zijn om tot inhoud voor uw gebruiksgeval toegang te hebben.

Opslagplaats en Taxonomie-ontwerp repository-and-taxonomy-design

Bij het ontwerpen van de taxonomie van een gegevensopslagruimte moeten verschillende factoren in aanmerking worden genomen. Deze omvatten toegangscontroles, localisatie, component en paginabezitsovererving, en meer.

Terwijl het ontwerpen van een taxonomie die deze zorgen richt, is het ook belangrijk om de "draagbaarheid"van het indexeren ontwerp te overwegen. In dit verband is de verhandelbaarheid het vermogen van een taxonomie om inhoud toe te staan om voorspelbaar te worden betreden gebaseerd op zijn weg. Dit maakt voor een efficiënter systeem dat gemakkelijker is te handhaven dan één die veelvoudige vragen vereist om worden uitgevoerd.

Ook, wanneer het ontwerpen van een taxonomie, is het belangrijk om te overwegen of het opdracht geven belangrijk is. Wanneer expliciete volgorde niet vereist is en een groot aantal knooppunten op hetzelfde niveau wordt verwacht, wordt u beter een ongeordend knooppunttype gebruikt, zoals sling:Folder of oak:Unstructured. In gevallen waarin bestelling vereist is, nt:unstructured en sling:OrderedFolder zou beter zijn.

Zoekopdrachten in componenten queries-in-components

Aangezien de vragen één van de meer het belasten verrichtingen op een AEM systeem kunnen zijn, is het een goed idee om hen in uw componenten te vermijden. Als u meerdere query's hebt uitgevoerd telkens wanneer een pagina wordt gerenderd, kan dit vaak de prestaties van het systeem nadelig beïnvloeden. Er zijn twee strategieën die kunnen worden gebruikt om het uitvoeren van query's bij het renderen van componenten te voorkomen: knooppunten doorlopen en Resultaten vooraf instellen.

Doorlopende knooppunten traversing-nodes

Als de opslagplaats op een manier wordt ontworpen die vroegere kennis van de plaats van de vereiste gegevens toestaat, kan de code die deze gegevens van de noodzakelijke wegen terugwint worden opgesteld zonder het moeten vragen in werking stellen om het te vinden.

Een voorbeeld hiervan is het renderen van inhoud die binnen een bepaalde categorie past. Een manier is om de inhoud te ordenen met een categorie-eigenschap die kan worden gevraagd om een component te vullen die items in een categorie weergeeft.

Een betere benadering zou zijn om deze inhoud in een taxonomie door categorie te structureren zodat het manueel kan worden teruggewonnen.

Als de inhoud bijvoorbeeld wordt opgeslagen in een taxonomie die lijkt op:

/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

de /content/myUnstructuredContent/parentCategory/childCategory de knoop kan eenvoudig worden teruggewonnen, zijn kinderen kunnen worden ontleed en worden gebruikt om de component terug te geven.

Wanneer u te maken hebt met een kleine of homogene resultaatset, kan het bovendien sneller zijn om de gegevensopslagruimte te doorlopen en de vereiste knooppunten te verzamelen in plaats van een query te maken om dezelfde resultatenset te retourneren. In het algemeen moeten vragen worden vermeden wanneer dat mogelijk is.

Voorkeursresultaten prefetching-results

Soms staat de inhoud of de vereisten rond de component het gebruik van knooptraversal als methode toe om de vereiste gegevens terug te winnen. In dergelijke gevallen moeten de vereiste query's worden uitgevoerd voordat de component wordt gerenderd, zodat optimale prestaties worden gegarandeerd.

Als de resultaten die voor de component worden vereist op het tijdstip kunnen worden berekend dat het wordt geschreven en er geen verwachting is dat de inhoud zal veranderen, kan de vraag worden uitgevoerd nadat een verandering is gedaan.

Als de gegevens of de inhoud regelmatig zullen veranderen, kan de vraag op een programma of via een luisteraar voor updates aan de onderliggende gegevens worden uitgevoerd. Vervolgens kunnen de resultaten naar een gedeelde locatie in de opslagplaats worden geschreven. Om het even welke componenten die deze gegevens nodig hebben kunnen dan de waarden van deze enige knoop trekken zonder het moeten een vraag bij runtime uitvoeren.

Een gelijkaardige strategie kan worden gebruikt om het resultaat in een in geheugen geheim voorgeheugen te houden, dat bij opstarten wordt bevolkt en wanneer de veranderingen worden gedaan bijgewerkt (gebruikend JCR ObservationListener of een Sling ResourceChangeListener).

Zoekopdrachten optimaliseren optimizing-queries

De documentatie van de eikel verstrekt een overzicht op hoog niveau hoe query's worden uitgevoerd. Dit vormt de basis van alle optimalisatieactiviteiten die in dit document worden beschreven.

AEM as a Cloud Service biedt de Query-prestaties, die bedoeld is ter ondersteuning van het implementeren van efficiënte query's.

Het hulpmiddel van de Prestaties van de Vraag is bereikbaar via Developer Console in Cloud Manager. AEM as a Cloud Service Hulpmiddel van de Prestaties van de Vraag van de Vraag levert meer informatie over de details van de vraaguitvoering over de versie van AEM 6.x.

Dit diagram illustreert de algemene stroom om het Hulpmiddel van de Prestaties van de Vraag te gebruiken om vragen te optimaliseren.

Een index gebruiken use-an-index

Elke vraag zou een index moeten gebruiken om optimale prestaties te leveren. In de meeste gevallen, zouden de bestaande out-of-box indexen moeten voldoende zijn om vragen te behandelen.

Soms moeten aangepaste eigenschappen worden toegevoegd aan een bestaande index, zodat aanvullende beperkingen kunnen worden gevraagd met de index. Zie het document Inhoud zoeken en indexeren voor meer informatie . De JCR-query-controle in dit document wordt beschreven hoe een eigenschapdefinitie op een index moet kijken om een specifiek querytype te ondersteunen.

De juiste criteria gebruiken use-the-right-criteria

De primaire beperking op om het even welke vraag zou een bezitsgelijke moeten zijn, aangezien dit het meest efficiënte type is. Als u meer eigenschapbeperkingen toevoegt, beperkt u het resultaat verder.

De query-engine beschouwt slechts één index. Dat betekent dat een bestaande index kan en moet worden aangepast door er meer aangepaste indexeigenschappen aan toe te voegen.

De JCR-query-werkblad in dit document worden de beschikbare beperkingen vermeld en ook uitgelegd hoe een indexdefinitie eruit moet zien zodat deze wordt opgepikt. Gebruik de Query-prestaties om de vraag te testen en ervoor te zorgen dat de juiste index wordt gebruikt en dat de vraagmotor geen beperkingen buiten de index hoeft te evalueren.

Volgorde ordering

Als een specifieke orde van het resultaat wordt gevraagd, zijn er twee manieren voor de vraagmotor om dit te bereiken:

De resultaatgrootte beperken restrict-result-size

De teruggewonnen grootte van het vraagresultaat is een belangrijke factor in vraagprestaties. Aangezien het resultaat op een luie manier wordt gehaald, is er een verschil in enkel het halen van de eerste 20 resultaten in vergelijking met het halen van 10.000 resultaten, zowel in runtime als geheugengebruik.

Dit betekent ook dat de grootte van de resultaatset alleen correct kan worden bepaald als alle resultaten worden opgehaald. Om deze reden, zou de opgehaalde resultaatreeks altijd moeten worden beperkt, of door de vraag (zie JCR-query-werkblad in dit document (voor meer informatie) of door de leesvolgorde van de resultaten te beperken.

Een dergelijke limiet voorkomt ook dat de query-engine de traversale limiet van 100.000 knopen, wat tot een gedwongen einde van de vraag leidt.

Zie de sectie Vragen met grote resultaatsets van dit document als een potentieel grote resultaatreeks volledig moet worden verwerkt.

Query-prestaties query-performance-tool

Het hulpmiddel van de Prestaties van de Vraag (dat bij wordt gevestigd /libs/granite/operations/content/diagnosistools/queryPerformance.html en beschikbaar via de Developer Console in Cloud Manager) biedt -

De tabellen 'Trage query's' en 'Populaire query's' bevatten:

Deze lijsten helpen vragen identificeren die niet volledig geïndexeerd zijn (zie Een index gebruiken of te veel knooppunten lezen (zie ook Repository traversal en Indextraversal). Dergelijke vragen zullen worden benadrukt - de aangewezen gebieden van zorg worden gemerkt rood.

De Reset Statistics er is een optie om alle bestaande statistieken die in de tabellen worden verzameld, te verwijderen. Dit staat de uitvoering van een bepaalde vraag (of via de toepassing zelf of het Uitleg hulpmiddel van de Vraag) en de analyse van de uitvoeringsstatistieken toe.

Query uitvoeren

Met het gereedschap Uitdrukkelijke query kunnen ontwikkelaars het uitvoeringsplan van de query begrijpen (zie Het uitvoeringsplan voor de query lezen), met inbegrip van details van om het even welke indexen die worden gebruikt wanneer het uitvoeren van de vraag. Dit kan worden gebruikt om te begrijpen hoe effectief een vraag wordt geïndexeerd om te voorspellen, of met terugwerkende kracht zijn prestaties te analyseren.

Een query verklaren

Ga als volgt te werk om een query uit te leggen:

Pop-up Query-uitleg query-explanation-popup

Na het selecteren Explain, wordt de gebruiker een pop-up voorgesteld beschrijvend het resultaat van de vraag verklaart (en uitvoering, als geselecteerd).
Deze pop-up bevat gegevens van -

Het uitvoeringsplan voor de query lezen reading-query-execution-plan

Het Plan van de Uitvoering van de Vraag bevat alles wordt vereist om de prestaties van een bepaalde vraag te voorspellen (of te verklaren). Begrijp hoe efficiënt de vraag zal worden uitgevoerd door de beperkingen en het opdracht geven tot in de originele vraag JCR (of de Bouwer van de Vraag) aan de vraag te vergelijken die in de onderliggende index (Lucene, Elastic of Bezit) wordt uitgevoerd.

Kijk eens naar de volgende query -

/jcr:root/content/dam//element(*, dam:Asset) [jcr:content/metadata/dc:title = "My Title"] order by jcr:created

… bevat

Het verklaren van deze vraag resulteert in het volgende plan -

[dam:Asset] as [a] /* lucene:damAssetLucene-9(/oak:index/damAssetLucene-9) +:ancestors:/content/dam +jcr:content/metadata/dc:title:My Title ordering:[{ propertyName : jcr:created, propertyType : UNDEFINED, order : ASCENDING }] where ([a].[jcr:content/metadata/dc:title] = 'My Title') and (isdescendantnode([a], [/content/dam])) */

Binnen dit plan, is de sectie die de vraag beschrijft die in de onderliggende index wordt uitgevoerd -

lucene:damAssetLucene-9(/oak:index/damAssetLucene-9) +:ancestors:/content/dam +jcr:content/metadata/dc:title:My Title ordering:[{ propertyName : jcr:created, propertyType : UNDEFINED, order : ASCENDING }]

In dit deel van het plan staat: -

Zulk een vraag zal waarschijnlijk goed presteren, aangezien de resultaten die van de indexvraag zijn teruggekeerd niet verder in de vraagmotor (behalve het filtreren van de Controle van de Toegang) zullen worden gefiltreerd. Het is echter nog steeds mogelijk dat een dergelijke query langzaam wordt uitgevoerd als de beste praktijken niet worden gevolgd - zie Indextraversal hieronder.

Een andere query overwegen -

/jcr:root/content/dam//element(*, dam:Asset) [jcr:content/metadata/myProperty = "My Property Value"] order by jcr:created

… bevat

Het verklaren van deze vraag resulteert in het volgende plan -

[dam:Asset] as [a] /* lucene:damAssetLucene-9-custom-1(/oak:index/damAssetLucene-9-custom-1) :ancestors:/content/dam ordering:[{ propertyName : jcr:created, propertyType : UNDEFINED, order : ASCENDING }] where ([a].[jcr:content/metadata/myProperty] = 'My Property Value') and (isdescendantnode([a], [/content/dam])) */

Binnen dit plan, is de sectie die de vraag beschrijft die in de onderliggende index wordt uitgevoerd -

lucene:damAssetLucene-9(/oak:index/damAssetLucene-9) :ancestors:/content/dam ordering:[{ propertyName : jcr:created, propertyType : UNDEFINED, order : ASCENDING }]

In dit deel van het plan staat: -

Dit plan van de vraaguitvoering zal in elk element onder resulteren /content/dam die van de index worden gelezen, en dan verder door de vraagmotor worden gefilterd (die slechts die die aanpassen de niet-geïndexeerde bezitsbeperking in de resultaatreeks).

Zelfs als slechts een klein percentage van de activa de beperking aanpast jcr:content/metadata/myProperty = "My Property Value"De query moet een groot aantal knooppunten lezen om de opgevraagde 'pagina' met resultaten te kunnen vullen (poging daartoe). Dit kan in een slecht presterende vraag resulteren, die als laag zal worden getoond Read Optimization score in het hulpmiddel van de Prestaties van de Vraag) en kan tot berichten leiden WAARSCHUWING die erop wijzen dat de grote aantallen knopen (zie Indextraversal).

Als u de prestaties van deze tweede query wilt optimaliseren, maakt u een aangepaste versie van de damAssetLucene-9 index (damAssetLucene-9-custom-1) en voeg de volgende eigenschapdefinitie toe -

"myProperty": {
  "jcr:primaryType": "nt:unstructured",
  "propertyIndex": true,
  "name": "jcr:content/metadata/myProperty"
}

JCR-query - Cheat Sheet jcr-query-cheatsheet

Ter ondersteuning van de creatie van efficiënte JCR-query's en indexdefinities JCR-query - Cheat Sheet kan tijdens de ontwikkeling worden gedownload en gebruikt als referentie.

Het bevat steekproefvragen voor QueryBuilder, XPath, en SQL-2, die veelvoudige scenario's behandelen die zich verschillend in termen van vraagprestaties gedragen. Het verstrekt ook aanbevelingen voor om indexen van het Eak te bouwen of aan te passen. De inhoud van dit Cheat Sheet geldt voor AEM as a Cloud Service en AEM 6.5.

Aanbevolen werkwijzen voor indexdefinitie index-definition-best-practices

Hieronder volgen enkele aanbevolen procedures voor het definiëren of uitbreiden van indexen.

De geautomatiseerde controles van de pijpleiding van de Manager van de Wolk zullen sommige hierboven beschreven beste praktijken afdwingen.

Vragen met grote resultaatsets queries-with-large-result-sets

Hoewel het wordt geadviseerd om vragen met grote resultaatreeksen te vermijden, zijn er geldige gevallen waar de grote resultaatreeksen moeten worden verwerkt. Vaak is de omvang van het resultaat niet vooraf bekend, dus moeten er voorzorgsmaatregelen worden genomen om de verwerking betrouwbaar te maken.

Repository traversal repository-traversal

Zoekopdrachten die de gegevensopslagruimte doorlopen, gebruiken geen index en worden geregistreerd met een bericht dat lijkt op het volgende.

28.06.2022 13:32:52.804 *WARN* [127.0.0.1 [1656415972414] POST /libs/settings/granite/operations/diagnosis/granite_queryperformance.explain.json HTTP/1.1] org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor Traversed 98000 nodes with filter Filter(query=select [jcr:path], [jcr:score], * from [nt:base] as a /* xpath: //* */, path=*) called by com.adobe.granite.queries.impl.explain.query.ExplainQueryServlet.getHeuristics; consider creating an index or changing the query

Met dit logboekfragment kunt u bepalen:

Met deze informatie, is het mogelijk om deze vraag te optimaliseren gebruikend de methodes die in worden beschreven Zoekopdrachten optimaliseren van dit document.

Indextraversal index-traversal

Vragen die een index gebruiken, maar nog steeds grote aantallen knopen lezen worden geregistreerd met een bericht gelijkend op het volgende (neem nota van de termijn Index-Traversed eerder dan Traversed).

05.10.2023 10:56:10.498 *WARN* [127.0.0.1 [1696502982443] POST /libs/settings/granite/operations/diagnosis/granite_queryperformance.explain.json HTTP/1.1] org.apache.jackrabbit.oak.plugins.index.search.spi.query.FulltextIndex$FulltextPathCursor Index-Traversed 60000 nodes with filter Filter(query=select [jcr:path], [jcr:score], * from [dam:Asset] as a where isdescendantnode(a, '/content/dam') order by [jcr:content/metadata/unindexedProperty] /* xpath: /jcr:root/content/dam//element(*, dam:Asset) order by jcr:content/metadata/unindexedProperty */, path=/content/dam//*)

Dit kan om verschillende redenen voorkomen -