Beräkna och hantera kapacitet för en söktjänst

Innan du skapar en söktjänst och låser en specifik prisnivå bör du ta några minuter för att förstå hur kapaciteten fungerar och hur du kan justera repliker och partitioner för att hantera variationer i arbetsbelastningen.

I Azure Cognitive Search baseras kapaciteten på repliker och partitioner. Repliker är kopior av sökmotorn. Partitioner är lagringsenheter. Varje ny söktjänst börjar med en vardera, men du kan skala upp varje resurs oberoende för att hantera varierande arbetsbelastningar. Att lägga till någon av resurserna är fakturerbart.

De fysiska egenskaperna för repliker och partitioner, till exempel bearbetningshastighet och disk-I/S, varierar beroende på tjänstnivå. Om du har etablerat på Standard blir repliker och partitioner snabbare och större än Basic.

Det är inte omedelbart att ändra kapacitet. Det kan ta upp till en timme att provisionera eller inaktivera partitioner, särskilt för tjänster med stora mängder data.

När du skalar en söktjänst kan du välja bland följande verktyg och metoder:

• Azure Portal
• Azure PowerShell
• Azure CLI
• REST API för hantering

Begrepp: sökenheter, repliker, partitioner, shards

Kapaciteten uttrycks i sökenheter som kan allokeras i kombinationer av partitioner och repliker, med hjälp av en underliggande mekanism för horisontell partitionering för att stödja flexibla konfigurationer:

Följande diagram visar relationen mellan repliker, partitioner, shards och sökenheter. Den visar ett exempel på hur ett enda index sträcker sig över fyra sökenheter i en tjänst med två repliker och två partitioner. Var och en av de fyra sökenheterna lagrar endast hälften av indexets shards. Sökenheterna i den vänstra kolumnen lagrar den första halvan av shards, som består av den första partitionen, medan de i den högra kolumnen lagrar den andra halvan av shards, som består av den andra partitionen. Eftersom det finns två repliker finns det två kopior av varje indexshard. Sökenheterna på den översta raden lagrar en kopia, som består av den första repliken, medan de på den nedre raden lagrar en annan kopia, som består av den andra repliken.

Diagrammet ovan är bara ett exempel. Många kombinationer av partitioner och repliker är möjliga, upp till högst 36 totalt antal sökenheter.

I Cognitive Search är shardhantering en implementeringsdetalj som inte kan konfigureras, men att veta att ett index är fragmenterat hjälper till att förstå tillfälliga avvikelser i rangordning och automatisk komplettering:

• Rangordningsavvikelser: Sökpoäng beräknas först på shardnivå och aggregeras sedan till en enda resultatuppsättning. Beroende på egenskaperna för shardinnehåll kan matchningar från en shard rangordnas högre än matchningar i ett annat. Om du märker att det finns räknare för intuitiv rangordning i sökresultaten beror det troligen på effekterna av horisontell partitionering, särskilt om indexen är små. Du kan undvika dessa rangordningsavvikelser genom att välja att beräkna poäng globalt i hela indexet,men det medför en prestandaförseing.

• Avvikelser i automatisk komplettering: Komplettera frågor automatiskt, där matchningar görs på de första tecknen i en delvis angivet ord, accepterar en fuzzy-parameter som gör att det inte går att göra några mindre stavningsavvikelser. För automatisk komplettering är fuzzy-matchning begränsad till termer inom den aktuella sharden. Om till exempel en shard innehåller "Microsoft" och en partiell term på "micor" har angetts matchar sökmotorn "Microsoft" i det fragmentet, men inte i andra shards som innehåller de återstående delarna av indexet.

Närmar sig uppskattning

Kapaciteten och kostnaderna för att köra tjänsten går hand i hand. Nivåer har begränsningar på två nivåer: innehåll (till exempel antal index för en tjänst) och lagring. Det är viktigt att tänka på båda eftersom den gräns som du når först är den effektiva gränsen.

Antalet index och andra objekt styrs vanligtvis av affärs- och tekniska krav. Du kan till exempel ha flera versioner av samma index för aktiv utveckling, testning och produktion.

Storage beror på storleken på de index som du förväntar dig att skapa. Det finns ingen solid heuristik eller generalitet som hjälper till med uppskattningar. Det enda sättet att fastställa storleken på ett index är att skapa ett. Storleken baseras på importerade data, textanalys och indexkonfiguration, till exempel om du aktiverar förslagsarbetare, filtrering och sortering.

För fulltextsökning är den primära datastrukturen en inverterad indexstruktur som har andra egenskaper än källdata. För ett inverterat index bestäms storlek och komplexitet av innehåll, inte nödvändigtvis av mängden data som du matar in i det. En stor datakälla med hög redundans kan resultera i ett mindre index än en mindre datamängd som innehåller mycket varierande innehåll. Därför är det sällan möjligt att dra slutsatsen av indexstorleken baserat på storleken på den ursprungliga datauppsättningen.

Attribut i indexet, till exempel aktivering av filter och sortering, påverkar lagringskraven. Användningen av förslagsörer har också lagringskonsekvenser. Mer information finns i Attribut och indexstorlek.

Beräkna med den kostnadsfria nivån

En metod för att uppskatta kapacitet är att börja med den kostnadsfria nivån. Kom ihåg att den kostnadsfria tjänsten erbjuder upp till tre index, 50 MB lagring och 2 minuters indexeringstid. Det kan vara svårt att uppskatta en beräknad indexstorlek med dessa begränsningar, men det här är stegen:

• Skapa en kostnadsfri tjänst.

• Förbered en liten, representativ datamängd.

• Skapa ett index och läs in dina data. Om datauppsättningen kan finnas i en Azure-datakälla som stöds av indexerare kan du använda guiden Importera data i portalen för att både skapa och läsa in indexet. Annars bör du använda REST och Postman eller Visual Studio Code för att skapa indexet och skicka data. Push-modellen kräver att data är i form av JSON-dokument, där fält i dokumentet motsvarar fält i indexet.

• Samla in information om indexet, till exempel storlek. Funktioner och attribut påverkar lagringen. Om du till exempel lägger till förslagshållare (sök efter du-skriver frågor) ökar lagringskraven.

  Med samma datauppsättning kan du försöka skapa flera versioner av ett index, med olika attribut för varje fält, för att se hur lagringskraven varierar. Mer information finns i "Storage konsekvenser" i Skapa ett grundläggande index.

Med en ungefärlig uppskattning kan du fördubbla budgetbeloppet för två index (utveckling och produktion) och sedan välja din nivå.

Uppskattning med en fakturerbar nivå

Dedikerade resurser kan hantera större samplings- och bearbetningstider för mer realistiska uppskattningar av indexkvantitet, storlek och frågevolymer under utvecklingen. Vissa kunder kommer direkt till en fakturerbar nivå och utvärderar sedan om allt eftersom utvecklingsprojektet mognar.

1. Granska tjänstbegränsningar på varje nivå för att avgöra om lägre nivåer har stöd för det antal index du behöver. På nivåerna Basic, S1 och S2 är indexgränserna 15, 50 respektive 200. Nivån Storage har en gräns på 10 index eftersom den är utformad för att stödja ett lågt antal mycket stora index.

2. Skapa en tjänst på en fakturerbar nivå:

   • Börja lågt på Basic eller S1 om du inte är säker på den projicerade belastningen.
   • Börja högt, på S2 eller till och med S3, om testningen omfattar storskalig indexering och frågebelastningar.
   • Börja med Storage optimerad, L1 eller L2, om du indexerar en stor mängd data och frågebelastningen är relativt låg, som med ett internt affärsprogram.

3. Skapa ett initialt index för att avgöra hur källdata översätts till ett index. Det här är det enda sättet att uppskatta indexstorleken.

4. Övervaka lagring, tjänstbegränsningar, frågevolym och svarstid i portalen. Portalen visar frågor per sekund, begränsade frågor och söksvarstid. Alla dessa värden kan hjälpa dig att avgöra om du har valt rätt nivå.

5. Lägg till repliker om du behöver hög tillgänglighet eller om frågeprestandan är långsam.

   Det finns inga riktlinjer för hur många repliker som behövs för att hantera frågebelastningar. Frågeprestanda beror på frågans komplexitet och konkurrerande arbetsbelastningar. Även om tillägg av repliker ger bättre prestanda är resultatet inte strikt linjärt: att lägga till tre repliker garanterar inte tredubbelt dataflöde. Vägledning i att uppskatta QPS för din lösning finns i Skala för prestandaoch Övervaka frågor.

Överväganden för frågevolym

Frågor per sekund (QPS) är ett viktigt mått vid prestandajustering, men det är vanligtvis bara ett nivåindelat övervägande om du förväntar dig hög frågevolym från början.

Standard-nivåerna kan ge en balans mellan repliker och partitioner. Du kan öka frågefördrundningen genom att lägga till repliker för belastningsutjämning eller lägga till partitioner för parallell bearbetning. Du kan sedan finjustera prestandan när tjänsten har etablerats.

Om du förväntar dig hög varaktiga frågevolymer från början bör du överväga högre Standard-nivåer som backas upp av kraftfullare maskinvara. Du kan sedan ta partitioner och repliker offline eller till och med växla till en tjänst på lägre nivå om dessa frågevolymer inte uppstår. Mer information om hur du beräknar frågegenomflödet finns i Azure Cognitive Search prestanda och optimering.

De Storage optimerade nivåerna är användbara för stora dataarbetsbelastningar, vilket ger stöd för mer övergripande tillgänglig indexlagring för när kraven på frågesvarstid är mindre viktiga. Du bör fortfarande använda ytterligare repliker för belastningsutjämning och ytterligare partitioner för parallell bearbetning. Du kan sedan finjustera prestandan när tjänsten har etablerats.

Serviceavtal

Funktionerna på den kostnadsfria nivån och förhandsversionen omfattas inte av serviceavtal (SLA). För alla fakturerbara nivåer gäller serviceavtalen när du etablerar tillräckligt med redundans för din tjänst. Du måste ha två eller flera repliker för fråge-SLA:er (läs). Du måste ha tre eller flera repliker för serviceavtal för frågor och indexering (läs/skriv). Antalet partitioner påverkar inte serviceavtal.

Tips kapacitetsplanering

• Tillåt att mått bygger runt frågor och samlar in data om användningsmönster (frågor under arbetstid, indexering vid låg belastning). Använd dessa data för att fatta beslut om tjänstetablering. Även om det inte är praktiskt i tim- eller daglig takt kan du justera partitioner och resurser dynamiskt för att hantera planerade ändringar i frågevolymer. Du kan också hantera oplanerade men varaktiga förändringar om nivåerna håller tillräckligt länge för att åtgärden ska kunna vidtas.

• Kom ihåg att den enda nackdelen med etablering är att du kan behöva ta bort en tjänst om de faktiska kraven är större än dina förutsägelser. För att undvika avbrott i tjänsten skapar du en ny tjänst på en högre nivå och kör den sida vid sida tills alla appar och begäranden riktar sig mot den nya slutpunkten.

När du ska lägga till kapacitet

Inledningsvis allokeras en tjänst en minimal nivå av resurser som består av en partition och en replik. Den nivå du väljer avgör partitionens storlek och hastighet, och varje nivå är optimerad kring en uppsättning egenskaper som passar olika scenarier. Om du väljer en högre nivå kan du behöva färre partitioner än om du väljer S1. En av de frågor som du måste besvara via själv riktad testning är om en större och dyrare partition ger bättre prestanda än två billigare partitioner på en tjänst som etablerats på en lägre nivå.

En enda tjänst måste ha tillräckligt med resurser för att hantera alla arbetsbelastningar (indexering och frågor). Ingen av arbetsbelastningarna körs i bakgrunden. Du kan schemalägga indexering för tider när frågebegäranden är naturligt mindre frekventa, men tjänsten prioriterar annars inte en uppgift framför en annan. Dessutom jämnar en viss mängd redundans ut frågeprestanda när tjänster eller noder uppdateras internt.

Några riktlinjer för att avgöra om du ska lägga till kapacitet är:

• Uppfylla kriterierna för hög tillgänglighet för serviceavtal
• Frekvensen för HTTP 503-fel ökar
• Stora frågevolymer förväntas

Som en allmän regel tenderar sökprogram att behöva fler repliker än partitioner, särskilt när tjänståtgärderna riktas mot frågearbetsbelastningar. Varje replik är en kopia av ditt index, så att tjänsten kan belastningsutjämna begäranden mot flera kopior. All belastningsutjämning och replikering av ett index hanteras av Azure Cognitive Search och du kan ändra antalet repliker som allokeras för din tjänst när som helst. Du kan allokera upp till 12 repliker i en standardsöktjänst och 3 repliker i en grundläggande söktjänst. Replikeringsallokering kan göras antingen från Azure Portal eller något av de programmässiga alternativen.

Sökprogram som kräver datauppdatering nästan i realtid behöver proportionellt fler partitioner än repliker. Genom att lägga till partitioner sprids läs-/skrivåtgärder över ett större antal beräkningsresurser. Det ger dig också mer diskutrymme för att lagra ytterligare index och dokument.

Slutligen tar det längre tid att köra frågor mot större index. Därför kanske du upptäcker att varje inkrementell ökning i partitioner kräver en mindre men proportionell ökning av repliker. Komplexiteten i dina frågor och frågevolymen tar hänsyn till hur snabbt frågekörningen omvandlas.

Lägga till eller minska repliker och partitioner

1. Logga in på Azure Portal och välj söktjänsten.

2. Under Inställningar öppnar du sidan Skala för att ändra repliker och partitioner.

   Följande skärmbild visar en Basic Standard som etablerats med en replik och partition. Formeln längst ned anger hur många sökenheter som används (1). Om enhetspriset var 100 USD (inte ett verkligt pris) skulle månadskostnaden för att köra den här tjänsten i genomsnitt vara 100 USD.

   

3. Använd skjutreglaget för att öka eller minska antalet partitioner. Välj Spara.

   Det här exemplet lägger till en andra replik och partition. Lägg märke till antalet sökenhet; det är nu fyra eftersom faktureringsformeln är repliker multiplicerat med partitioner (2 x 2). En fördubbling av kapaciteten är mer än dubbelt så stor som kostnaden för att köra tjänsten. Om kostnaden för sökenheten var 100 USD skulle den nya månadsfakturan nu vara 400 USD.

   För aktuella kostnader per enhet för varje nivå går du till sidan Prissättning.

   

4. När du har sparat kan du kontrollera meddelanden för att bekräfta att åtgärden lyckades.

   

   Kapacitetsändringar kan ta allt från 15 minuter upp till flera timmar att slutföra. Du kan inte avbryta när processen har startat och det inte finns någon realtidsövervakning för replik- och partitionsjusteringar. Följande meddelande förblir dock synligt medan ändringar pågår.

   

Så här hanteras skalningsbegäranden

När en skalningsbegäran har mottagits gör söktjänsten följande:

1. Kontrollerar om begäran är giltig.
2. Börjar backa upp data och systeminformation.
3. Kontrollerar om tjänsten redan är i ett etableringstillstånd (för närvarande lägger du till eller tar bort repliker eller partitioner).
4. Startar etableringen.

Skalning av en tjänst kan ta upp till 15 minuter eller mer än en timme, beroende på tjänstens storlek och omfånget för begäran. Säkerhetskopieringen kan ta flera minuter, beroende på mängden data och antalet partitioner och repliker.

Stegen ovan är inte helt i följd. Systemet börjar till exempel etableras när det på ett säkert sätt kan göra det, vilket kan vara när säkerhetskopieringen tas ned.

Fel under skalning

Felmeddelandet "Tjänstuppdateringsåtgärder tillåts inte just nu eftersom vi bearbetar en tidigare begäran" orsakas av att en begäran upprepas för att skala ned eller upp när tjänsten redan bearbetar en tidigare begäran.

Lös det här felet genom att kontrollera tjänststatus för att verifiera etableringsstatusen:

1. Använd Hanterings-REST API, Azure PowerShelleller Azure CLI för att hämta tjänststatus.
2. Anropa Hämta tjänst
3. Kontrollera svaret för "provisioningState": "provisioning"

Om statusen är "Etablering" väntar du tills begäran har slutförts. Statusen ska vara antingen "Lyckades" eller "Misslyckades" innan en annan begäran görs. Det finns ingen status för säkerhetskopiering. Säkerhetskopiering är en intern åtgärd och det är troligen inte en faktor i något avbrott i en skalningsövning.

Kombinationer av partitioner och repliker

En Basic-tjänst kan ha exakt en partition och upp till tre repliker för en maxgräns på tre SUS: er. Den enda justerbara resursen är repliker. Du behöver minst två repliker för hög tillgänglighet för frågor.

Alla standard- och Storage optimerade söktjänster kan anta följande kombinationer av repliker och partitioner, med den gräns på 36 SU som tillåts för dessa nivåer.

SUs, priser och kapacitet förklaras i detalj på Azure-webbplatsen. Mer information finns i Prisinformation.

Nästa steg