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

In AEM as a Cloud Service worden alle operationele aspecten van 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 het aanbevolen een niet-geordend knooppunttype zoals sling:Folder of oak:Unstructured te gebruiken. In gevallen waarin volgorde vereist is, zijn nt:unstructured en sling:OrderedFolder geschikter.

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 vragen te vermijden wanneer het teruggeven van componenten: het oversteken van knopen en het prefetching resultaten.

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

Het knooppunt /content/myUnstructuredContent/parentCategory/childCategory kan eenvoudig worden opgehaald, de onderliggende items ervan kunnen worden geparseerd en gebruikt om de component te renderen.

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 vergelijkbare strategie kan worden gebruikt om het resultaat in een cache in het geheugen te houden. Deze cache wordt bij het opstarten gevuld en bijgewerkt wanneer wijzigingen worden uitgevoerd (met een JCR ObservationListener of een Sling ResourceChangeListener ).

Zoekopdrachten optimaliseren optimizing-queries

De documentatie van Oak verstrekt a overzicht op hoog niveau hoe de vragen worden uitgevoerd. Dit vormt de basis voor alle optimalisatieactiviteiten die in dit document worden beschreven.

AEM as a Cloud Service verstrekt het Hulpmiddel van de Prestaties van de Vraag, dat wordt ontworpen om het uitvoeren van efficiënte vragen te steunen.

Het hulpmiddel van de Prestaties van de Vraag is bereikbaar via Developer Console in Cloud Manager. Het AEM as a Cloud Service-hulpprogramma voor zoekprestaties biedt meer informatie over de details van de uitvoering van de query in de versie 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 Onderzoek en het Indexerenvoor meer details. De sectie van het Cheatsheet van de Vraag JCRvan dit document beschrijft hoe een bezitsdefinitie op een index moet kijken om een specifiek vraagtype te steunen.

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 sectie van de Vraag JCRvan dit document maakt een lijst van de beschikbare beperkingen en ook schetst hoe een indexdefinitie moet kijken zodat het opnam. Gebruik het Hulpmiddel van de Prestaties van de Vraagom de vraag te testen en ervoor te zorgen dat de juiste index wordt gebruikt en dat de vraagmotor geen beperkingen buiten de index moet 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 gehaalde resultaatreeks altijd moeten worden beperkt, of door de vraag (zie de 🔗 sectie van de Vraag 0} te verhogen JCR van dit document voor details) of door de gelezen resultaten van de resultaten te beperken.

Zulk een grens verhindert ook de vraagmotor de doorlopende grens van 100.000 knopen te raken, die tot een gedwongen einde van de vraag leidt.

Zie de sectie Vragen met grote resultaatreeksenvan 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 /libs/granite/operations/content/diagnosistools/queryPerformance.html wordt gevestigd en beschikbaar via Developer Console in Cloud Manager) verstrekt -

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

Deze lijsten helpen het identificeren van vragen die niet volledig worden geïndexeerd (zie Gebruik een Indexof lees teveel knopen (zie ook Traversal van de Bewaarplaatsen Traversal van de Index). Dergelijke vragen zullen worden benadrukt - de aangewezen gebieden van zorg worden gemerkt rood.

De optie Reset Statistics is bedoeld om alle bestaande statistieken te verwijderen die in de tabellen worden verzameld. 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

Het Uitdrukkelijke hulpmiddel van de Vraag staat ontwikkelaars toe om het Plan van de Uitvoering van de Vraag te begrijpen (zie die het Plan van de Uitvoering van de Vraagleest), met inbegrip van details van om het even welke indexen die wanneer het uitvoeren van de vraag worden gebruikt. 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 van Explain, wordt de gebruiker voorgesteld met een pop-up 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. Nochtans, is het nog mogelijk voor zulk een vraag om langzaam uit te voeren als de beste praktijken niet worden gevolgd - zie 🔗 hieronder Traversal van de Index van 0}.

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 ertoe leiden dat elk element onder /content/dam van de index wordt gelezen, en dan verder gefilterd door de vraagmotor (die slechts die zal omvatten die de niet-geïndexeerde bezitsbeperking in de resultaatreeks aanpassen).

Zelfs als slechts een klein percentage van activa de beperking jcr:content/metadata/myProperty = "My Property Value" aanpast, moet de vraag een groot aantal knopen lezen (poging om) de gevraagde "pagina"van resultaten te vullen. Dit kan in slecht uitvoerend vraag resulteren, die zal worden getoond zoals hebbend een lage Read Optimization score in het hulpmiddel van de Prestaties van de Vraag) en kan tot WARN berichten leiden die erop wijzen dat de grote aantallen knopen (zie het Doorlopen van de Index) worden overgestoken.

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 voegt u de volgende eigenschapdefinitie toe -

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

JCR-query - Cheat Sheet jcr-query-cheatsheet

Om de verwezenlijking van efficiënte vragen JCR en indexdefinities te steunen, is het JCR- Cheat Sheet van de Vraagbeschikbaar voor download en gebruik als verwijzing tijdens ontwikkeling.

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 Oak te bouwen of aan te passen. De inhoud van dit controleblad is van toepassing op 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 Cloud Manager pijpleidingscontroles zullen enkele 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 Optimizing de sectie van Vragenvan dit document.

Indextraversal index-traversal

Vragen die een index gebruiken, maar nog steeds grote aantallen knooppunten lezen, worden geregistreerd met een bericht dat lijkt op het volgende (let op de term Index-Traversed in plaats van 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 -