Den här artikeln handlar om att konfigurera index i AEM 6. De bästa sätten att optimera fråga- och indexeringsprestanda finns i Metodtips för frågor och indexering.
Till skillnad från Jackrabbit 2 indexerar inte Oak innehållet 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, kommer kanske många noder att gå igenom. Frågan kanske fortfarande fungerar, men den är antagligen väldigt långsam.
Om Oak stöter på 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
Oak-frågemotorn stöder följande språk:
Med den Apache Oak-baserade serverdelen kan olika indexerare kopplas in i databasen.
En indexerare är Egenskapsindex som indexdefinitionen lagras i själva databasen.
Implementeringar för Apache Lucene och Solr är också tillgängliga som standard, som båda stöder fulltextindexering.
The 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. Därefter väljer Oak 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.
För stora databaser är det tidskrävande att skapa ett index. Detta gäller både när ett index skapas första gången och när ett index indexeras om (ett index återskapas efter att definitionen ändrats). Se även Felsöka ekindex och Förhindra långsam omindexering.
Om omindexering behövs i mycket 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 oak:index nod.
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 är vanligtvis användbart för frågor som har egenskapsbegränsningar men som inte är fulltext. Den kan konfigureras genom att följa proceduren nedan:
Öppna CRXDE genom att gå till http://localhost:4502/crx/de/index.jsp
Skapa en ny nod under oak:index
Namnge noden PropertyIndex och ange nodtypen till oak:QueryIndexDefinition
Ange följande egenskaper för den nya noden:
property
(av typen String)jcr:uuid
(av typen Namn)Det här exemplet indexerar jcr:uuid
egenskapen, vars jobb är att visa den universellt unika identifieraren (UUID) för den nod som den är kopplad till.
Spara ändringarna.
Egenskapsindexet har följande konfigurationsalternativ:
The type egenskapen anger indextypen och i det här fallet måste den anges till property
The propertyNames anger listan med egenskaper som ska lagras i indexet. Om det saknas används nodnamnet som referensvärde för egenskapsnamnet. I det här exemplet jcr:uuid egenskapen vars jobb är att visa den unika identifieraren (UUID) för noden läggs till i indexet.
The unik flagga som, om den är inställd på true lägger till en unikhetsbegränsning i egenskapsindexet.
The declareNodeTypes kan du ange en viss nodtyp som indexet bara gäller för.
The reindex flagga som true, kommer att utlösa en omindexering av allt innehåll.
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.
En fulltextindexerare baserad på Apache Lucene finns i AEM 6.
Om ett fulltextindex är konfigurerat används heltextindexet för alla frågor som har ett fulltextvillkor, oavsett om det finns andra villkor som är indexerade eller oavsett om det finns en sökvägsbegränsning.
Om inget fulltextindex är konfigurerat kommer frågor med fulltextvillkor inte att fungera som förväntat.
Eftersom indexet uppdateras via en asynkron bakgrundstråd kommer vissa textsökningar att vara otillgängliga under ett litet tidsfönster tills bakgrundsprocesserna är klara.
Du kan konfigurera ett fulltextindex för Lucene enligt följande procedur:
Öppna CRXDE och skapa en ny nod under oak:index.
Namnge noden LuceneIndex och ange nodtypen till oak:QueryIndexDefinition
Lägg till följande egenskaper i noden:
lucene
(av typen String)async
(av typen String)Spara ändringarna.
Lucene-indexet har följande konfigurationsalternativ:
Sedan ek 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 ska fulltextEnabled -egenskapen måste 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 ny nod under oak:index:
LucenePropertyIndex
oak:QueryIndexDefinition
När noden har skapats lägger du till följande egenskaper:
typ:
lucene (of type String)
asynk:
async (of type String)
fulltextEnabled:
false (of type Boolean)
includePropertyNames: ["alias"] (of type String)
Jämfört med det vanliga egenskapsindexet är Lucene-egenskapsindexet alltid konfigurerat i asynkront läge. Resultatet som returneras av indexet kanske inte alltid återspeglar det mest aktuella läget i databasen.
Mer information om egenskapsindexet Lucene finns i Dokumentationssida för Apache Jackrabbit Oak Lucene.
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 via analyzers
nod (av typ nt:unstructured
) i oak:index
definition.
Standardanalysatorn för ett index är konfigurerad i default
underordnad till analysatornoden.
En lista över tillgängliga analysatorer finns i API-dokumentationen för Lucene-versionen som du använder.
Om du vill använda någon av de färdiga analysverktygen kan du konfigurera den enligt följande procedur:
Leta reda på det index som du vill använda analysverktyget med under oak:index
nod.
Skapa en underordnad nod under indexet med namnet default
av typen nt:unstructured
.
Lägg till en egenskap i standardnoden med följande egenskaper:
class
String
org.apache.lucene.analysis.standard.StandardAnalyzer
Värdet är namnet på den analyserarklass som du vill använda.
Du kan också ange att analysatorn ska användas med en specifik lucene-version genom att använda det valfria luceneMatchVersion
strängegenskap. Ett giltigt syntaxvärde för användning med Lucene 4.7 är:
luceneMatchVersion
String
LUCENE_47
If luceneMatchVersion
inte tillhandahålls kommer Oak att använda den version av Lucene som det levereras med.
Om du vill lägga till en stoppordsfil i analyskonfigurationerna kan du skapa en ny nod under default
en med följande egenskaper:
stopwords
nt:file
Analysprogram kan också sammanställas baserat på Tokenizers
, TokenFilters
och CharFilters
. Du kan göra detta genom att ange en analysator och skapa underordnade noder till dess tillvalstokensorer och filter som ska användas i listordning. Se även https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#Specifying_an_Analyzer_in_the_schema
Se den här nodstrukturen som ett exempel:
Namn: analyzers
Namn: default
Namn: charFilters
Typ: nt:unstructured
HTMLStrip
Mapping
Namn: tokenizer
Egenskapsnamn: name
String
Standard
Namn: filters
Typ: nt:unstructured
Namn: LowerCase
Namn: Stop
Egenskapsnamn: words
String
stop1.txt, stop2.txt
Namn: stop1.txt
nt:file
Namn: stop2.txt
nt:file
Namnet på filtren, charFilters och tokenizers formas genom att fabrikssuffixen tas bort. Således:
org.apache.lucene.analysis.standard.StandardTokenizerFactory
blir standard
org.apache.lucene.analysis.charfilter.MappingCharFilterFactory
blir Mapping
org.apache.lucene.analysis.core.StopFilterFactory
blir Stop
Alla konfigurationsparametrar som krävs för fabriken anges som egenskaper för den aktuella koden.
I fall där t.ex. inläsning av stoppord där innehåll från externa filer behöver läsas in, kan innehållet tillhandahållas genom att skapa en underordnad nod till nt:file
filtyp.
Syftet med Solr-indexet är i huvudsak fulltextsökning, men det kan också användas för att indexera sökningar 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.
Integrationen 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.
AEM kan även konfigureras för att fungera med en fjärrserver för Solr:
Hämta och extrahera den senaste versionen av Solr. Mer information finns i Installationsdokumentation för Apache Solr.
Skapa nu två Solr-kort. Du kan göra detta genom att skapa mappar för varje delning i mappen där Solr har packats upp:
<solrunpackdirectory>\aemsolr1\node1
<solrunpackdirectory>\aemsolr2\node2
Leta reda på exempelinstansen i Solr-paketet. Den finns vanligtvis i en mapp som heter example
" i paketets rot.
Kopiera följande mappar från exempelinstansen till de två delade mapparna ( aemsolr1\node1
och aemsolr2\node2
):
contexts
etc
lib
resources
scripts
solr-webapp
webapps
start.jar
Skapa en ny mapp med namnet " cfg
" i var och en av de två delade mapparna.
Placera Solr- och Zookeeper-konfigurationsfilerna i den nya cfg
mappar.
Mer information om Solr- och ZooKeeper-konfigurationen finns i Dokumentation för SolrConfiguration och Starthandbok för ZooKeeper.
Starta den första delningen med stöd för ZooKeeper genom att gå till aemsolr1\node1
och köra följande kommando:
java -Xmx2g -Dbootstrap_confdir=./cfg/oak/conf -Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar
Starta den andra delningen genom att gå till aemsolr2\node2
och köra följande kommando:
java -Xmx2g -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
När båda delarna har startats testar du att allt är igång genom att ansluta till Solr-gränssnittet på http://localhost:8983/solr/#/
Starta AEM och gå till webbkonsolen på http://localhost:4502/system/console/configMgr
Ange följande konfiguration under Konfiguration av Oak Solr-fjärrserver:
http://localhost:8983/solr/
Välj Fjärrverktyg i listrutan under Oak Solr serverprovider.
Gå till CRXDE och logga in som administratör.
Skapa en ny nod med namnet solrIndex under oak:index och ange följande egenskaper:
Spara ändringarna.
Nedan visas ett exempel på en baskonfiguration som kan användas med alla tre Solr-distributioner som beskrivs i den här artikeln. Den rymmer de dedikerade egenskapsindex som redan finns i AEM och bör inte användas med andra program.
För att kunna använda det på rätt sätt måste du placera innehållet i arkivet direkt i Solr Home Directory. Vid distributioner med flera noder bör den placeras direkt under rotmappen för varje nod.
Rekommenderade Solr-konfigurationsfiler
AEM 6.1 integrerar även två indexeringsverktyg som finns i AEM 6.0 som en del av verktygsuppsättningen Adobe Consulting Services Commons:
Nu kan du nå dem genom att gå till Verktyg - Åtgärder - Kontrollpanel - Diagnostik på AEM välkomstskärm.
Mer information om hur du använder dem finns i Dokumentation för instrumentpanelen för åtgärder.
ACS Commons-paketet visar även OSGi-konfigurationer som kan användas för att skapa egenskapsindex.
Du kommer åt den från webbkonsolen genom att söka efter Se till att egenskapsindex för Oak".
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 presenteras en uppsättning rekommendationer om vad som behöver göras för att spåra orsaken till sådana problem och råd om hur man löser dem.
Det enklaste sättet att få den information som krävs för frågan som körs är via 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.
Om du vill aktivera loggning måste du aktivera FELSÖKNING nivåloggar för de kategorier som gäller för ekindexering och frågor. Dessa kategorier är:
The com.day.cq.search -kategorin kan bara användas om du använder det AEM tillhandahållna QueryBuilder-verktyget.
Det är viktigt att loggarna bara är inställda på DEBUG så länge frågan som du vill felsöka körs, annars genereras ett stort antal händelser i loggarna över tid. På grund av detta växlar du tillbaka till INFO-nivåloggning för de kategorier som nämns ovan när de obligatoriska loggarna har samlats in.
Du kan aktivera loggning genom att följa den här proceduren:
https://serveraddress:port/system/console/slinglog
logs/queryDebug.log
. Detta korrelerar alla DEBUG-händelser till en enda loggfil.Hur frågan utvärderas påverkas i hög grad av indexkonfigurationen. Det är viktigt att få indexkonfigurationen för att kunna analyseras eller skickas till support. Du kan antingen hämta konfigurationen som ett innehållspaket eller hämta en JSON-återgivning.
Eftersom indexeringskonfigurationen i de flesta fall lagras under /oak:index
i CRXDE kan du 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.
I vissa fall kan det vara bra att ange utdata för indexrelaterade MBeans för felsökning. Du kan göra detta genom att:
Gå till JMX-konsolen på:
https://serveraddress:port/system/console/jmx
Sök efter följande MBeans:
Klicka på var och en av MBeans för att få prestandastatistik. Skapa en skärmbild eller anteckna dem om du behöver ge support.
Du kan också hämta JSON-varianten av statistiken på följande URL:er:
https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak/%2522LuceneIndex%2522.tidy.-1.json
https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak/%2522LuceneIndex%2522.tidy.-1.json
https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak/%2522LuceneIndex%2522.tidy.-1.json
https://serveraddress:port/system/sling/monitoring/mbeans/org/apache/jackrabbit/oak/%2522LuceneIndex%2522.tidy.-1.json
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.
Du kan samla in ytterligare information för att hjälpa till att felsöka problemet, till exempel:
org.apache.jackrabbit.oak-core
paket.https://serveraddress:port/libs/cq/search/content/querydebug.html