Oak Queries and Indexing oak-queries-and-indexing

Introduktion introduction

Till skillnad från Jackrabbit 2 indexerar Oak inte innehåll som standard. Anpassade index måste skapas när det behövs, ungefär som med traditionella relationsdatabaser. Om det inte finns något index för en viss fråga kan många noder gå igenom. Frågan kanske fortfarande fungerar, men den är förmodligen långsam.

Om Oak påträffar en fråga utan index skrivs ett loggmeddelande på WARN-nivå ut:

*WARN* Traversed 1000 nodes with filter Filter(query=select ...) consider creating an index or changing the query

Frågespråk som stöds supported-query-languages

Oak frågemotor har stöd för följande språk:

Indexerartyper och kostnadsberäkning indexer-types-and-cost-calculation

Med Apache Oak-baserad backend kan olika indexerare kopplas in i databasen.

En indexerare är egenskapsindexet, som indexdefinitionen lagras i själva databasen.

Implementeringar för Apache Lucene och Solr är också tillgängliga som standard, vilket båda stöder fulltextindexering.

Traversal Index används om ingen annan indexerare är tillgänglig. Det innebär att innehållet inte är indexerat och att innehållsnoderna gås igenom för att hitta matchningar med frågan.

Om det finns flera tillgängliga indexerare för en fråga beräknar varje tillgänglig indexerare kostnaden för att köra frågan. Oak väljer sedan indexeraren med den lägsta uppskattade kostnaden.

Diagrammet ovan är en högnivårepresentation av frågekörningsmekanismen i Apache Oak.

Först tolkas frågan i ett abstrakt syntaxträd. Sedan kontrolleras frågan och omvandlas till SQL-2, som är det ursprungliga språket för Oak-frågor.

Därefter används varje index för att beräkna kostnaden för frågan. När det är klart hämtas resultaten från det lägsta indexvärdet. Slutligen filtreras resultaten, både för att säkerställa att den aktuella användaren har läsåtkomst till resultatet och att resultatet matchar hela frågan.

Konfigurera index configuring-the-indexes

Om omindexering behövs i stora databaser, särskilt när du använder MongoDB och fulltextindex, bör du överväga att extrahera text och använda eko-run för att skapa det ursprungliga indexet och indexera om.

Index konfigureras som noder i databasen under noden Oak:index .

Indexnodens typ måste vara oak:QueryIndexDefinition. Det finns flera konfigurationsalternativ tillgängliga för varje indexerare som nodegenskaper. Mer information finns i konfigurationsinformationen för varje indexerartyp nedan.

Egenskapsindexet the-property-index

Egenskapsindexet är användbart för frågor som har egenskapsbegränsningar men inte är fulltextfrågor. Den kan konfigureras genom att följa proceduren nedan:

Egenskapsindexet har följande konfigurationsalternativ:

Orderat index the-ordered-index

Det sorterade indexet är ett tillägg till egenskapsindexet. Den har dock tagits bort. Index av den här typen måste ersättas med Lucene-egenskapsindex.

Fullständigt Lucene-textindex the-lucene-full-text-index

En fulltextindexerare baserad på Apache Lucene finns i AEM 6.

Om ett fulltextindex är konfigurerat kommer alla frågor som har ett fulltextvillkor att använda fulltextindexet, oavsett om det finns andra villkor som är indexerade eller oavsett om det finns en sökvägsbegränsning.

Om inget fulltextindex är konfigurerat fungerar inte frågor med fulltextvillkor som förväntat.

Eftersom indexet uppdateras med hjälp av en asynkron bakgrundstråd är vissa textsökningar inte tillgängliga för ett litet tidsfönster förrän bakgrundsprocesserna har slutförts.

Du kan konfigurera ett fulltextindex för Lucene enligt följande procedur:

Lucene-indexet har följande konfigurationsalternativ:

Förstå fulltextsökning understanding-fulltext-search

Dokumentationen i det här avsnittet gäller till exempel Apache Lucene, Elasticsearch och fulltextindex för PostgreSQL, SQLite och MySQL. Följande exempel är för AEM / Oak / Lucene.

Data som ska indexeras

Startpunkten är de data som måste indexeras. Ta följande dokument som exempel:

Inverterat index

Indexeringsfunktionen delar upp fulltexten i ord som kallas "tokens" och skapar ett index som kallas "inverterat index". Indexet innehåller en lista med dokument där det finns för varje ord.

Korta, vanliga ord (kallas även"stopwords") indexeras inte. Alla variabler konverteras till gemener och ordstam används.

Specialtecken som - är inte indexerade.

Listan med dokument sorteras. Det här är praktiskt när du frågar.

Söker

Nedan visas ett exempel på en fråga. Observera att alla specialtecken (som ') ersattes med ett blanksteg:

/jcr:root/content//element(\*; cq:Page)`[` jcr:contains('Rubik s Cube')`]`

Orden tokeniseras och filtreras på samma sätt som vid indexering (enstaka teckenord tas till exempel bort). Så i det här fallet är sökningen för:

+:fulltext:rubik +:fulltext:cube

Indexet läser listan med dokument för dessa ord. Om det finns många dokument kan listan vara stor. Anta att de innehåller följande:

Lucene bläddrar fram och tillbaka mellan de två listorna (eller rundrobat n-listor, när du söker efter n ord):

Det enda dokument som innehåller båda villkoren är 200, som i exemplet nedan:

När flera poster hittas sorteras de sedan efter poäng.

Egenskapsindexet Lucene the-lucene-property-index

Sedan Oak 1.0.8 kan Lucene användas för att skapa index som innehåller egenskapsbegränsningar som inte är fulltext.

För att uppnå ett Lucene-egenskapsindex måste egenskapen fulltextEnabled alltid anges till false.

Ta följande exempelfråga:

select * from [nt:base] where [alias] = '/admin'

Om du vill definiera ett Lucene-egenskapsindex för frågan ovan kan du lägga till följande definition genom att skapa en nod under oak:index:

När noden har skapats lägger du till följande egenskaper:

Lucene Analyzers lucene-analyzers

Sedan version 1.2.0 stöder Oak Lucene-analysatorer.

Analysatorer används både när ett dokument indexeras och vid frågetillfället. En analyserare undersöker texten i fälten och genererar en tokenström. Lucene-analysatorerna består av en serie tokeniserings- och filterklasser.

Analysatorerna kan konfigureras med noden analyzers (av typen nt:unstructured) inuti definitionen oak:index.

Standardanalysatorn för ett index är konfigurerad i den underordnade default-noden för analysatornoden.

Ange klassen Analyzer direkt specifying-the-analyzer-class-directly

Om du vill använda någon av de färdiga analysverktygen kan du konfigurera den enligt följande procedur:

Skapa analysatorer med hjälp av komposition creating-analyzers-via-composition

Analysatorer kan också sättas samman baserat på Tokenizers, TokenFilters och CharFilters. Du kan göra detta genom att ange en analysator och skapa underordnade noder till dess tillvalstokeniserare och filter som tillämpas i listordning. Se även https://cwiki.apache.org/confluence/display/solr/AnalyzersTokenizersTokenFilters#Specifying_an_Analyzer_in_the_schema

Se den här nodstrukturen som ett exempel:

Namnet på filtren, charFilters och tokenizers formas genom att fabrikssuffixen tas bort. Således

Alla konfigurationsparametrar som krävs för fabriken anges som egenskapen för noden i fråga.

För exempelvis inläsning av stoppord där innehåll från externa filer måste läsas in, kan innehållet anges genom att en underordnad nod av typen nt:file skapas för filen i fråga.

Solr-index the-solr-index

Syftet med Solr-indexet är fulltextsökning, men det kan också användas för indexsökning efter sökväg, egenskapsbegränsningar och primära typbegränsningar. Det innebär att Solr-indexet i Oak kan användas för alla typer av JCR-frågor.

Integreringen i AEM sker på databasnivå så att Solr är ett av de möjliga index som kan användas i Oak, den nya databasimplementeringen som levererades med AEM.

Den kan konfigureras för att fungera som en fjärrserver med AEM.

Konfigurera AEM med en enda fjärr-Solr-server configuring-aem-with-a-single-remote-solr-server

AEM kan även konfigureras för att fungera med en fjärrserver för Solr:

Rekommenderad konfiguration för Solr recommended-configuration-for-solr

Nedan visas ett exempel på en baskonfiguration som kan användas med alla tre Solr-distributioner som beskrivs i den här artikeln. Den innehåller de dedikerade egenskapsindexen som redan finns i AEM. Använd inte med andra program.

Om du vill använda det på rätt sätt måste du placera innehållet i arkivet direkt i Solr Home Directory. Om det finns distributioner med flera noder bör den placeras direkt under rotmappen för varje nod.

Rekommenderade Solr-konfigurationsfiler

Hämta fil

AEM aem-indexing-tools

AEM 6.1 integrerar även två indexeringsverktyg som finns i AEM 6.0 som en del av Adobe Consulting Services Commons-verktygen:

Nu kan du nå dem genom att gå till Verktyg - Åtgärder - Kontrollpanel - Diagnos från AEM välkomstskärm.

Mer information om hur du använder dem finns i dokumentationen för kontrollpanelen för åtgärder.

Skapa egenskapsindex med OSGi creating-property-indexes-via-osgi

ACS Commons-paketet visar även OSGi-konfigurationer som kan användas för att skapa egenskapsindex.

Du kan komma åt den från webbkonsolen genom att söka efter Kontrollera Oak-egenskapsindex.

Felsöka indexeringsproblem troubleshooting-indexing-issues

Det kan uppstå situationer när frågor tar lång tid att köra och den allmänna svarstiden för systemet är långsam.

I det här avsnittet ges rekommendationer om vad som måste göras för att spåra orsaken till sådana problem och råd om hur man löser dem.

Förbereder felsökningsinformation för analys preparing-debugging-info-for-analysis

Det enklaste sättet att få den information som krävs för frågan som körs är via verktyget Förklara fråga. På så sätt kan du samla in exakt den information som behövs för att felsöka en långsam fråga utan att behöva läsa loggnivåinformationen. Detta är önskvärt om du känner till frågan som felsöks.

Om detta inte är möjligt av någon anledning, kan du samla indexeringsloggarna i en enda fil och använda den för att felsöka just det problemet.

Aktivera loggning enable-logging

Om du vill aktivera loggning måste du aktivera DEBUG-nivåloggar för de kategorier som gäller Oak-indexering och frågor. Dessa kategorier är:

Kategorin com.day.cq.search kan bara användas om du använder det AEM tillhandahållna QueryBuilder-verktyget.

Du kan aktivera loggning genom att följa den här proceduren:

Indexkonfiguration index-configuration

Hur frågan utvärderas påverkas i hög grad av indexkonfigurationen. Det är viktigt att få indexkonfigurationen analyserad eller skickad till support. Du kan antingen hämta konfigurationen som ett innehållspaket eller hämta en JSON-återgivning.

Oftast lagras indexkonfigurationen under noden /oak:index i CRXDE. Du kan hämta JSON-versionen på:

https://serveraddress:port/oak:index.tidy.-1.json

Om indexet är konfigurerat på en annan plats ändrar du sökvägen i enlighet med detta.

MBean output mbean-output

Ibland kan det vara praktiskt att ange utdata för indexrelaterade MBeans för felsökning. Du kan göra detta genom att:

Du kan också hämta JSON-varianten av statistiken på följande URL

Du kan också tillhandahålla konsoliderade JMX-utdata via https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak.tidy.3.json. Detta inkluderar all Oak-relaterad MBean-information i JSON-format.

Annan information other-details

Du kan samla in ytterligare information som kan hjälpa dig att felsöka problemet, till exempel: