Förutom övergången till Oak i AEM 6 har några stora förändringar gjorts i hur frågor och index hanteras. Under Jackrabbit 2 indexerades allt innehåll som standard och kunde läsas fritt. I eke måste index skapas manuellt under oak:index
nod. En fråga kan köras utan index, men för stora datauppsättningar kommer den att köras långsamt eller till och med avbrytas.
I den här artikeln beskrivs när index ska skapas och när de inte behövs, hur man undviker att använda frågor när de inte är nödvändiga, och hur man optimerar index och frågor så att de fungerar så optimalt som möjligt.
Läs även Läs dokumentation om hur man skriver frågor och index. Förutom att index är ett nytt koncept i AEM 6 finns det syntaktiska skillnader i Oak-frågor som måste beaktas när du migrerar kod från en tidigare AEM.
När du utformar taxonomin för en databas måste flera faktorer beaktas. Dessa omfattar bland annat åtkomstkontroller, lokalisering, komponent och arv av sidegenskaper.
När du utformar en taxonomi som tar upp dessa problem är det också viktigt att tänka på hur"genomskinlighet" är i indexdesignen. I det här sammanhanget är möjligheten att gå igenom en taxonomi som gör att innehållet kan läsas på ett förutsägbart sätt baserat på dess sökväg. Detta ger ett mer prestandasystem som är enklare att underhålla än ett som kräver att man kör många frågor.
När du utformar en taxonomi är det dessutom viktigt att tänka på om det är viktigt att beställa. Om explicit ordning inte krävs och många noder på samma nivå förväntas är det bättre att använda en oordnad nodtyp, till exempel sling:Folder
eller oak:Unstructured
. Om det krävs en beställning nt:unstructured
och sling:OrderedFolder
är lämpligare.
Eftersom frågor kan vara en av de mer beskattningsbara åtgärderna i ett AEM är det en bra idé att undvika dem i dina komponenter. Om flera frågor körs varje gång en sida återges kan det ofta försämra systemets prestanda. Det finns två strategier som du kan använda för att undvika att köra frågor när du återger komponenter: gå igenom noder och förhämta resultat.
Om databasen är utformad på ett sådant sätt att det går att förhandsgranska platsen för de data som krävs, kan kod som hämtar dessa data från de nödvändiga sökvägarna distribueras utan att behöva köra frågor för att hitta dem.
Ett exempel på detta är att återge innehåll som passar inom en viss kategori. Ett sätt är att ordna innehållet med en kategoriegenskap som kan efterfrågas för att fylla i en komponent som visar objekt i en kategori.
Ett bättre sätt är att strukturera innehållet i en taxonomi efter kategori så att det kan hämtas manuellt.
Om innehållet till exempel lagras i en taxonomi som liknar:
/content/myUnstructuredContent/parentCategory/childCategory/contentPiece
The /content/myUnstructuredContent/parentCategory/childCategory
noden kan bara hämtas, dess underordnade noder kan tolkas och användas för att återge komponenten.
När du har att göra med en liten eller homogen resultatuppsättning kan det dessutom vara snabbare att gå igenom databasen och samla ihop de noder som behövs, i stället för att skapa en fråga som returnerar samma resultatmängd. Generellt sett bör frågor undvikas där det är möjligt att göra detta.
Ibland tillåter inte innehållet eller kraven runt komponenten att nodgenomgång används som ett sätt att hämta nödvändiga data. I dessa fall måste de nödvändiga frågorna köras innan komponenten återges, så att optimala prestanda säkerställs för slutanvändaren.
Om de resultat som krävs för komponenten kan beräknas när den redigeras och det inte finns någon förväntad tid för att innehållet ska ändras, kan frågan köras när författaren tillämpar inställningarna i dialogrutan.
Om data eller innehåll ändras regelbundet, kan frågan köras enligt ett schema eller via en avlyssnare för uppdateringar av underliggande data. Sedan kan resultaten skrivas till en delad plats i databasen. Alla komponenter som behöver dessa data kan sedan hämta värden från den här noden utan att behöva köra en fråga vid körning.
När du kör en fråga som inte använder ett index loggas varningar om nodgenomgång. Skapa ett index om detta är en fråga som kommer att köras ofta. För att avgöra vilket index en viss fråga använder Förklara fråga, verktyg rekommenderas. Om du vill ha mer information kan du aktivera DEBUG-loggning för de relevanta söknings-API:erna.
När du har ändrat en indexdefinition måste indexet återskapas (omindexeras). Beroende på storleken på indexet kan det ta en stund att slutföra detta.
När du kör komplexa frågor kan det finnas fall där frågan delas upp i flera mindre frågor och data kopplas till kod efter att uppgiften har blivit mer presterande. Rekommendationen för dessa fall är att jämföra prestandan för de två metoderna för att avgöra vilket alternativ som är bäst för det aktuella användningsfallet.
AEM tillåter skrivfrågor på ett av tre sätt:
Medan alla frågor konverteras till SQL2 innan de körs är overheadkostnaden för frågekonvertering minimal, vilket innebär att det största problemet när man väljer frågespråk är läsbarhet och komfort från utvecklingsteamet.
När du använder QueryBuilder bestäms resultatet som standard, vilket är långsammare i Oak jämfört med tidigare versioner av Jackrabbit. Om du vill kompensera för detta kan du använda gissaTotal-parameter.
Precis som med andra frågespråk är det första steget för att optimera en fråga att förstå hur den kommer att köras. Om du vill aktivera aktiviteten kan du använda Förklara fråga, verktyg som ingår i kontrollpanelen för åtgärder. Med det här verktyget kan en fråga kopplas in och förklaras. En varning visas om frågan kommer att orsaka problem med en stor databas och körningstid samt de index som kommer att användas. Verktyget kan även läsa in en lista med långsamma och populära frågor som sedan kan förklaras och optimeras.
Om du vill ha mer information om hur Oak väljer vilket index som ska användas och hur frågemotorn faktiskt kör en fråga, kan du FELSÖKNING loggningskonfigurationen kan läggas till för följande paket:
Se till att du tar bort den här loggen när du är klar med felsökningen av frågan. Det brukar generera en stor mängd aktivitet och kan till slut fylla upp disken med loggfiler.
Mer information om hur du gör detta finns i Loggningsdokumentation.
Lucene registrerar en JMX-böna som ger information om indexerat innehåll, inklusive storlek och antal dokument som finns i varje index.
Du kan nå den via JMX-konsolen på https://server:port/system/console/jmx
När du är inloggad på JMX-konsolen söker du efter Lucene Index Statistik för att hitta den. Annan indexstatistik finns i IndexStats MBean.
För frågestatistik kan du titta på MBean med namnet Oak Query-statistik.
Om du vill gå in i indexen med ett verktyg som Lukemåste du använda Oak-konsolen för att dumpa indexvärdet från NodeStore
till en filsystemkatalog. Anvisningar om hur du gör detta finns i Lucene-dokumentation.
Du kan också extrahera indexvärdena i systemet i JSON-format. För att kunna göra detta måste du ha https://server:port/oak:index.tidy.-1.json
Under utveckling
Ange låga tröskelvärden för oak.queryLimitInMemory
(till exempel 10000) och Oak. queryLimitReads
(till exempel 5000) och optimera den dyra frågan när du klickar på ett UnsupportedOperationException som säger"Frågan läser fler än x noder…".
Detta hjälper till att undvika resurskrävande frågor (dvs. som inte backas upp av något index eller backas upp av mindre täckande index). En fråga som till exempel läser 1 miljon noder skulle leda till ökad I/O och negativt påverka programmets totala prestanda. Alla frågor som misslyckas på grund av att gränserna överskrids bör analyseras och optimeras.
Övervaka loggarna för frågor som utlöser genomgång av stora noder eller stor minnesförbrukning i stackar: "
*WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.
Övervaka loggarna för frågor som utlöser stor minnesförbrukning i stackar:
*WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped
I AEM 6.0-6.2 kan du justera tröskelvärdet för nodgenomgång via JVM-parametrar i AEM startskript för att förhindra att stora frågor överbelastar miljön.
Rekommenderade värden är:
-Doak.queryLimitInMemory=500000
-Doak.queryLimitReads=100000
I AEM 6.3 är de två ovanstående parametrarna förkonfigurerade OOTB och kan sparas via OSGi QueryEngineSettings.
Mer information finns under: https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limits
Den första frågan som ska ställas när index skapas eller optimeras är om de behövs för en viss situation. Om du bara ska köra frågan en gång eller endast då och då och vid låg belastning för systemet genom en gruppbearbetning, är det kanske bättre att inte skapa ett index alls.
När du har skapat ett index måste indexvärdet också uppdateras varje gång indexerade data uppdateras. Eftersom detta påverkar systemets prestanda bör index endast skapas när de behövs.
Index är bara användbara om de data som finns i indexet är unika nog att motivera det. Tänk på ett index i en bok och de ämnen den omfattar. När du indexerar en uppsättning ämnen i en text kommer det oftast att finnas hundratals eller tusentals poster, vilket gör att du snabbt kan gå till en delmängd av sidor och snabbt hitta den information du söker efter. Om indexet bara har två eller tre poster, där var och en pekar på flera hundra sidor, skulle indexet inte vara användbart. Samma sak gäller för databasindex. Om det bara finns ett par unika värden är indexet inte användbart. Med andra ord kan ett index också bli för stort för att vara användbart. Om du vill se indexstatistik kan du läsa Indexstatistik ovan.
Lucene-index introducerades i Oak 1.0.9 och erbjuder några kraftfulla optimeringar av egenskapsindexen som introducerades i den första starten av AEM 6. När du bestämmer dig för att använda Lucene-index eller egenskapsindex ska du ta hänsyn till följande:
Vanligtvis rekommenderar vi att du använder Lucene-index, såvida det inte finns ett övertygande behov av att använda egenskapsindex så att du kan dra nytta av bättre prestanda och flexibilitet.
AEM har även stöd för Solr-indexering som standard. Detta används för att stödja fullständig textsökning, men det kan också användas för att stödja alla typer av JCR-frågor. Solr bör beaktas när AEM inte har processorkapacitet att hantera antalet frågor som krävs vid sökintensiva distributioner, som sökdrivna webbplatser med ett stort antal samtidiga användare. Solr kan också implementeras i en crawlningsbaserad metod för att använda några av de mer avancerade funktionerna i plattformen.
Solr-index kan konfigureras för att köras inbäddade på AEM server för utvecklingsmiljöer eller avlastas till en fjärrinstans för att förbättra sökskalbarheten i produktions- och stagningsmiljöer. När du avlastar sökningen förbättras skalbarheten, vilket medför fördröjning och därför rekommenderas inte om det inte krävs. Mer information om hur du konfigurerar Solr-integrering och hur du skapar Solr-index finns i Frågor och indexering.
När du använder den integrerade Solr-sökmetoden kan du avlasta indexering till en Solr-server. Om de mer avancerade funktionerna i Solr-servern används via en crawlningsbaserad metod krävs ytterligare konfigurationsarbete.
Nackdelen med det här tillvägagångssättet är att AEM som standard respekterar åtkomstkontrollistor och därmed döljer resultat som en användare inte har tillgång till, men att externalisera sökningar till en Solr-server saknar stöd för den här funktionen. Om sökningen ska göras externt på det här sättet måste man se till att användarna inte får resultat som de inte ska se.
Potentiella användningsfall där denna metod kan vara lämplig är fall där sökdata från flera källor kan behöva sammanställas. Du kan till exempel ha en webbplats som AEM och en annan webbplats som är värd för en tredjepartsplattform. Solr kunde konfigureras för att crawla innehållet på båda webbplatserna och lagra dem i ett aggregerat index. Detta skulle möjliggöra sökningar mellan webbplatser.
I Oak-dokumentationen för Lucene-index finns flera saker att tänka på när du designar index:
Om frågan använder olika sökvägsbegränsningar använder du evaluatePathRestrictions
. Detta gör att frågan kan returnera delmängden av resultaten under den angivna sökvägen och sedan filtrera dem baserat på frågan. Annars söker frågan efter alla resultat som matchar frågeparametrarna i databasen och filtrerar dem sedan baserat på sökvägen.
Om frågan använder sortering, har du en explicit egenskapsdefinition för den sorterade egenskapen och anger ordered
till true
för den. Detta gör att resultaten kan sorteras som sådana i indexet och sparas på kostsamma sorteringsåtgärder vid körning av frågor.
Placera bara det som behövs i indexet. Om du lägger till funktioner eller egenskaper som inte behövs växer indexet och prestandan blir långsam.
I ett egenskapsindex kan det vara till hjälp att minska storleken på ett index om du har ett unikt egenskapsnamn, men för Lucene-index kan du använda nodeTypes
och mixins
bör göras för att uppnå sammanhängande index. Fråga en viss nodeType
eller mixin
blir mer prestandaförbättrande än att fråga nt:base
. När du använder det här arbetssättet definierar du indexRules
för nodeTypes
i fråga.
Om dina frågor bara körs under vissa sökvägar skapar du dessa index under dessa sökvägar. Index behöver inte finnas i databasens rot.
Du bör använda ett enda index när alla egenskaper som indexeras är relaterade så att Lucene kan utvärdera så många egenskapsbegränsningar som möjligt internt. Dessutom kommer en fråga endast att använda ett index, även när en koppling görs.
Om NodeStore
fjärrlagras ett alternativ som anropas CopyOnRead
kan aktiveras. Alternativet gör att fjärrindexet skrivs till det lokala filsystemet när det läses. Detta kan förbättra prestanda för frågor som ofta körs mot dessa fjärrindex.
Detta kan konfigureras i OSGi-konsolen under LuceneIndexProvider och aktiveras som standard från och med Oak 1.0.13.
När du tar bort ett index bör du alltid inaktivera indexet tillfälligt genom att ställa in type
egenskap till disabled
och testa för att säkerställa att programmet fungerar korrekt innan du tar bort det. Ett index uppdateras inte när det är inaktiverat, så det kanske inte har rätt innehåll om det är återaktiverat och kan behöva indexeras om.
När du har tagit bort ett egenskapsindex för en tarMK-instans måste komprimeringen köras för att frigöra diskutrymme som användes. För Lucene-index finns det faktiska indexinnehållet i BlobStore, vilket innebär att en skräpinsamling för datalagring krävs.
När du tar bort ett index för en MongoDB-instans är borttagningskostnaden proportionerlig till antalet noder i indexet. Eftersom det kan uppstå problem när du tar bort ett stort index rekommenderar vi att du inaktiverar indexet och tar bort det endast under en underhållsperiod, med ett verktyg som oak-mongo.js. Observera att den här metoden inte bör användas för vanligt nodinnehåll eftersom det kan medföra inkonsekvenser i data.
Mer information om oak-mongo.js finns i Verktyg för kommandorad i dokumentationen för eken.
För att skapa effektiva JCR-frågor och indexdefinitioner har JCR Query Cheat Sheet finns att hämta och använda som referens under utvecklingen. Den innehåller exempelfrågor för QueryBuilder, XPath och SQL-2, som omfattar flera scenarier som beter sig på olika sätt när det gäller frågeprestanda. Här finns också rekommendationer för hur du skapar eller anpassar ekindexeringar. Innehållet i detta värmeblad gäller AEM 6.5 och AEM as a Cloud Service.
I det här avsnittet beskrivs endast godtagbara orsaker att indexera om index för ekv.
Utanför de orsaker som anges nedan kan omindexering av index för Oak-index not ändra beteende eller lösa problem och öka inläsningen i onödan AEM.
Omindexering av ekindexering skall undvikas om inte annat anges i tabellen nedan.
Innan du läser tabellerna nedan för att avgöra om omindexering är användbar, alltid verifiera:
De enda tillåtna felskrivningsvillkoren för omindexering av ekindexeringar är om konfigurationen för ett ekindexvärde har ändrats.
Omindexering bör alltid ske med vederbörlig hänsyn till hur den påverkar AEM övergripande prestanda och utföras under perioder med låg aktivitet eller underhållsperioder.
Här följer information om möjliga problem tillsammans med lösningar:
Gäller för/om:
Symtom:
Verifiera:
jcr:created
eller jcr:lastModified
egenskaper för noder som saknas i förhållande till indexets ändrade tidSå här löser du:
Indexera om lucene-indexet
Du kan även trycka (utföra en benign write-åtgärd) på de noder som saknas
Gäller för/om:
Symtom:
Verifiera:
diffStoredIndexDefinition
.Så här löser du:
Eak-versioner före 1.6:
Oak version 1.6+
Om befintligt innehåll inte påverkas av ändringarna behövs bara en uppdatering
Annars, reindex lucene-indexet
I följande tabell beskrivs den enda godtagbara felsökningen och exceptionella situationer där omindexering av ekindexering löser problemet.
Om ett problem uppstår med AEM som inte uppfyller villkoren nedan ska du not indexera om index eftersom problemet inte kan lösas.
Här följer information om möjliga problem tillsammans med lösningar:
Gäller för/om:
Symtom:
Verifiera:
Så här löser du:
Genomför en genomgång av databasen, till exempel:
http://localhost:4502/system/console/repositorycheck
genom att gå igenom databasen avgör om andra binära filer (förutom lucene-filer) saknas
Om andra binärfiler än lucene-index saknas kan du återställa från en säkerhetskopia
I annat fall reindex alla lucene-index
Obs!
Det här villkoret indikerar ett felkonfigurerat datalager som kan resultera i att ett binärt värde (till exempel binära resurser) saknas.
I det här fallet återställer du till den senast fungerande versionen av databasen för att återställa alla binära filer som saknas.
Gäller för/om:
Symtom:
Verifiera:
The AsyncIndexUpdate
(var femte sekund) kommer att misslyckas med ett undantag i error.log:
...a Lucene index file is corrupt...
Så här löser du:
Ta bort den lokala kopian av lucene-indexet
crx-quickstart/repository/index
Om detta inte löser problemet, och AsyncIndexUpdate
undantag kvarstår då:
I AEM 6.5 oak-run.jar är den ENDA metoden som stöds för omindexering i MongoMK- eller RDBMK-databaser.
Använd oak-run.jar indexera om egenskapsindexet
Ange egenskapen async-reindex till true för egenskapsindexet
[oak:queryIndexDefinition]@reindex-async=true
Indexera om egenskapsindexet asynkront med webbkonsolen via PropertyIndexAsyncReindex MBean;
till exempel
Använd oak-run.jar för omindexering indexet för Lucene-egenskapen.
Ställ in egenskapen async-reindex på true i egenskapsindexet lucene
[oak:queryIndexDefinition]@reindex-async=true
I föregående avsnitt sammanfattas och bildas riktlinjerna för omindexering av eko i Apache Oak-dokumentation i AEM.
Textförextrahering är processen att extrahera och bearbeta text från binärfiler, direkt från datalagret via en isolerad process, och direkt exponera den extraherade texten för efterföljande omindexering/indexering av Oak-index.
/oak:index/damAssetLucene
.Indexera om en befintlig lucenindex med binär extrahering aktiverad
Stöd för driftsättning av en new lucenindex till AEM med binär extrahering aktiverad
Textförextrahering kan inte användas för nytt innehåll som läggs till i databasen och är inte heller nödvändigt.
Nytt innehåll läggs till i databasen naturligt och inkrementellt efter den asynkrona fulltextindexeringsprocessen (som standard var femte sekund).
Vid normal AEM, till exempel överföring av resurser via webbgränssnittet eller programmatisk import av resurser, indexeras det nya binära innehållet automatiskt och stegvis i heltextindexet av AEM. Eftersom datamängden är inkrementell och relativt liten (ungefär den datamängd som kan sparas i databasen på 5 sekunder) kan AEM utföra fulltextextraheringen från binärfilerna under indexeringen utan att påverka den övergripande systemprestandan.
Du kommer att indexera om ett indexvärde som utför binär extrahering i heltext eller distribuera ett nytt index som kommer att innehålla binära fulltextindex
Innehållet (binärfiler) som texten ska förextraheras från måste finnas i databasen
Ett underhållsfönster där CSV-filen och den slutliga omindexeringen genereras
Oak-version: 1.0.18+, 1.2.3+
oak-run.jarversion 1.7.4+
En mapp/resurs i filsystemet för lagring av extraherad text som är tillgänglig från AEM indexinstanser
Kommandona oak-run.jar som beskrivs nedan räknas upp fullständigt på https://jackrabbit.apache.org/oak/docs/query/pre-extract-text.html
Diagrammet och stegen nedan beskriver och kompletterar de tekniska textförextraheringsstegen som beskrivs i dokumentationen för Apache Oak.
Generera en lista med innehåll som ska extraheras i förväg
Kör steg 1(a-b) under en underhållsperiod/en period med låg användning när nodarkivet bläddras igenom under den här åtgärden, vilket kan innebära en avsevärd belastning på systemet.
1a. Kör oak-run.jar --generate
om du vill skapa en lista med noder som ska ha texten förextraherad.
1b. Lista över noder (1a) lagras i filsystemet som en CSV-fil
Hela nodarkivet gås igenom (enligt sökvägarna i kommandot eka run) varje gång --generate
körs, och new CSV-filen skapas. CSV-filen är not återanvänds mellan olika exekveringar av textförextraheringsprocessen (steg 1-2).
Extrahera text i filsystemet
Steg 2(a-c) kan utföras under normal AEM om det bara interagerar med datalagret.
2a. Kör oak-run.jar --tika
att förextrahera text för binära noder som räknas upp i CSV-filen som genereras i (1b)
2b. Den process som initieras i (2a) får direkt åtkomst till binära noder som definieras i CSV-filen i datalagret och extraherar text.
2c. Extraherad text lagras i ett filsystem i ett format som kan hanteras av omindexeringsprocessen för eken (3a)
Förextraherad text identifieras i CSV-filen av det binära fingeravtrycket. Om den binära filen är densamma kan samma extraherade text användas i alla AEM. Eftersom AEM Publish vanligtvis är en delmängd av AEM Author kan den förextraherade texten från AEM Author ofta användas för att omindexera AEM Publish (förutsatt att AEM Publish har tillgång till de extraherade textfilerna).
Förutextraherad text kan läggas till stegvis över tid. Extrahering av text i förväg hoppar över extrahering för tidigare extraherade binärfiler, så det är bäst att behålla den extraherade texten om omindexering måste ske igen i framtiden (förutsatt att det extraherade innehållet inte är oöverkomligt stort). Om den är det, bör du utvärdera om innehållet i mellanrummet ska zippa, eftersom texten komprimeras väl).
Indexera om index, hämta fulltext från extraherade textfiler
Kör omindexering (steg 3a-b) under en underhålls-/låganvändningsperiod när nodarkivet gås igenom under den här åtgärden, vilket kan innebära en avsevärd belastning på systemet.
3a. Indexera om av Lucene-index anropas i AEM.
3b. Apache Jackrabbit Oak DataStore PreExtractTextProvider OSGi-konfigurationen (konfigurerad att peka på den extraherade texten via en filsystemsökväg) instruerar Oak att hämta fulltext från de extraherade filerna och undviker att direkt hitta och bearbeta data som lagras i databasen.