Tips för bättre prestanda i Azure AI Search

  • Artikel

Den här artikeln är en samling tips och metodtips för att öka fråge- och indexeringsprestanda. Om du vet vilka faktorer som mest sannolikt påverkar sökprestanda kan du undvika ineffektivitet och få ut mesta möjliga av söktjänsten. Några viktiga faktorer är:

  • Indexsammansättning (schema och storlek)
  • Frågedesign
  • Tjänstkapacitet (nivå och antalet repliker och partitioner)

Kommentar

Letar du efter strategier för indexering av stora volymer? Se Indexering av stora datamängder i Azure AI Search.

Indexstorlek och schema

Frågor körs snabbare på mindre index. Detta är delvis en funktion av att ha färre fält att skanna, men det beror också på hur systemet cachelagrar innehåll för framtida frågor. Efter den första frågan finns en del innehåll kvar i minnet där det söks mer effektivt. Eftersom indexstorleken tenderar att öka med tiden är en metod att regelbundet gå tillbaka till indexsammansättningen, både schema och dokument, för att söka efter möjligheter till innehållsminskning. Men om indexet har rätt storlek är den enda andra kalibreringen du kan göra att öka kapaciteten: antingen genom att lägga till repliker eller uppgradera tjänstnivån. I avsnittet "Tips: Uppgradera till en Standard S2-nivå" beskrivs beslutet att skala upp och skala ut.

Schemakomplexitet kan också påverka indexerings- och frågeprestanda negativt. Överdriven fälttillskrivning bygger på begränsningar och bearbetningskrav. Komplexa typer tar längre tid att indexeras och frågas. De kommande avsnitten utforskar varje villkor.

Tips: Var selektiv i fält-attribution

Ett vanligt misstag som administratörer och utvecklare gör när de skapar ett sökindex är att välja alla tillgängliga egenskaper för fälten, i stället för att bara välja de egenskaper som behövs. Om ett fält till exempel inte behöver vara sökbart i fulltext hoppar du över det fältet när du anger det sökbara attributet.

Selektiv attribution

Stöd för filter, fasetter och sortering kan fyrdubbla lagringskraven. Om du lägger till förslagsgivare ökar lagringskraven ännu mer. En bild av attributens inverkan på lagringen finns i Attribut och indexstorlek.

Sammanfattningstal är konsekvenserna av överattribution:

  • Försämrad indexeringsprestanda på grund av det extra arbete som krävs för att bearbeta innehållet i fältet och sedan lagra det i det inverterade sökindexet (ange attributet "sökbart" endast för fält som innehåller sökbart innehåll).

  • Skapar en större yta som varje fråga måste täcka. Alla fält som är markerade som sökbara genomsöks i en fulltextsökning.

  • Ökar driftskostnaderna på grund av extra lagring. Filtrering och sortering kräver ytterligare utrymme för att lagra ursprungliga (icke-analyserade) strängar. Undvik att ange filterbara eller sorterbara fält som inte behöver det.

  • I många fall begränsar övertillskrivning funktionerna i fältet. Om ett fält till exempel är fasettbart, filterbart och sökbart kan du bara lagra 16 kB text i ett fält, medan ett sökbart fält kan innehålla upp till 16 MB text.

Kommentar

Endast onödig attribution bör undvikas. Filter och fasetter är ofta viktiga för sökupplevelsen, och i de fall filter används behöver du ofta sortera så att du kan sortera resultaten (filter returnerar själva i en osorterad uppsättning).

Tips: Överväg alternativ till komplexa typer

Komplexa datatyper är användbara när data har en komplicerad kapslad struktur, till exempel överordnade och underordnade element som finns i JSON-dokument. Nackdelen med komplexa typer är de extra lagringskrav och ytterligare resurser som krävs för att indexering av innehållet, jämfört med icke-komplexa datatyper.

I vissa fall kan du undvika dessa kompromisser genom att mappa en komplex datastruktur till en enklare fälttyp, till exempel en samling. Du kan också välja att platta ut en fälthierarki till enskilda fält på rotnivå.

utplattad fältstruktur

Frågedesign

Frågesammansättning och komplexitet är en av de viktigaste faktorerna för prestanda och frågeoptimering kan avsevärt förbättra prestandan. Tänk på följande när du utformar frågor:

  • Antal sökbara fält. Varje ytterligare sökbart fält resulterar i mer arbete för söktjänsten. Du kan begränsa vilka fält som söks vid frågetillfället med hjälp av parametern "searchFields". Det är bäst att bara ange de fält som du bryr dig om för att förbättra prestanda.

  • Mängden data som returneras. Om du hämtar en stor mängd innehåll kan frågor bli långsammare. När du utformar en fråga ska du bara returnera de fält som du behöver för att återge resultatsidan. Hämta sedan återstående fält med hjälp av uppslags-API:et när en användare väljer en matchning.

  • Användning av partiella termsökningar.Partiella termsökningar, till exempel prefixsökning, fuzzy-sökning och reguljär uttryckssökning, är mer beräkningsmässigt dyra än vanliga nyckelordssökningar, eftersom de kräver fullständiga indexgenomsökningar för att ge resultat.

  • Antal fasetter. Om du lägger till fasetter i frågor krävs sammansättningar för varje fråga. Om du begär ett högre ”antal” för en fasett krävs också extra arbete av tjänsten. Normalt lägger du bara till de fasetter som du tänker återge i din app och undviker att begära ett stort antal fasetter om det inte behövs.

  • Höga överhoppsvärden. Om parametern $skip anges till ett högt värde (till exempel i tusental) ökar svarstiden för sökningen eftersom motorn hämtar och rangordnar en större mängd dokument för varje begäran. Av prestandaskäl är det bäst att undvika höga $skip-värden och använda andra tekniker i stället, till exempel filtrering, för att hämta ett stort antal dokument.

  • Begränsa fält med hög kardinalitet. Ett fält med hög kardinalitet refererar till ett fasettbart eller filterbart fält som har ett stort antal unika värden och som därför förbrukar betydande resurser när resultatet beräknas. Om du till exempel anger ett produkt-ID eller ett beskrivningsfält som fasettbart och filterbart räknas det som hög kardinalitet eftersom de flesta värden från dokument till dokument är unika.

Tips: Använd sökfunktioner i stället för att överbelasta filtervillkor

Eftersom en fråga använder allt mer komplexa filtervillkor försämras prestandan för sökfrågan. Tänk på följande exempel som visar användningen av filter för att trimma resultat baserat på en användaridentitet:

$filter= userid eq 123 or userid eq 234 or userid eq 345 or userid eq 456 or userid eq 567

I det här fallet används filteruttrycken för att kontrollera om ett enda fält i varje dokument är lika med ett av många möjliga värden för en användaridentitet. Det är troligt att du hittar det här mönstret i program som implementerar säkerhetstrimning (kontrollerar ett fält som innehåller ett eller flera huvud-ID mot en lista med huvud-ID:t som representerar användaren som utfärdar frågan).

Ett effektivare sätt att köra filter som innehåller ett stort antal värden är att använda search.in funktionen, som du ser i det här exemplet:

search.in(userid, '123,234,345,456,567', ',')

Tips: Lägga till partitioner för långsamma enskilda frågor

När frågeprestandan i allmänhet blir långsammare löser det ofta problemet genom att lägga till fler repliker. Men vad händer om problemet är en enskild fråga som tar för lång tid att slutföra? I det här scenariot hjälper det inte att lägga till repliker, men fler partitioner kan göra det. En partition delar upp data mellan extra databehandlingsresurser. Två partitioner delar upp data i hälften, en tredje partition delar upp dem i tredjedelar och så vidare.

En positiv bieffekt av att lägga till partitioner är att långsammare frågor ibland fungerar snabbare på grund av parallell databehandling. Vi har noterat parallellisering på frågor med låg selektivitet, till exempel frågor som matchar många dokument eller fasetter som ger antal över ett stort antal dokument. Eftersom betydande beräkningar krävs för att bedöma dokumentens relevans, eller för att räkna antalet dokument, hjälper tillägg av extra partitioner frågor att slutföras snabbare.

Om du vill lägga till partitioner använder du Azure-portalen, PowerShell, Azure CLI eller ett hanterings-SDK.

Tjänstkapacitet

En tjänst överbelastas när frågor tar för lång tid eller när tjänsten börjar släppa begäranden. Om detta händer kan du åtgärda problemet genom att uppgradera tjänsten eller genom att lägga till kapacitet.

Nivån för söktjänsten och antalet repliker/partitioner har också stor inverkan på prestandan. Varje progressivt högre nivå ger snabbare processorer och mer minne, som båda har en positiv inverkan på prestanda.

Tips: Skapa en ny söktjänst med hög kapacitet

Grundläggande tjänster och standardtjänster som skapats [i regioner som stöds](regioner som stöds efter den 3 april 2024 har mer lagringsutrymme per partition än äldre tjänster. Innan du uppgraderar till en högre nivå och en högre fakturerbar hastighet går du tillbaka till tjänstgränserna på nivån för att se om samma nivå på en nyare tjänst ger dig nödvändig lagring.

Tips: Uppgradera till en Standard S2-nivå

Standard S1-söknivån är ofta där kunderna börjar. Ett vanligt mönster för S1-tjänster är att index växer med tiden, vilket kräver fler partitioner. Fler partitioner leder till långsammare svarstider, så fler repliker läggs till för att hantera frågebelastningen. Som du kan föreställa dig har kostnaden för att köra en S1-tjänst nu gått vidare till nivåer utöver den ursprungliga konfigurationen.

I det här läget är en viktig fråga att ställa om det skulle vara fördelaktigt att flytta till en högre nivå, i stället för att gradvis öka antalet partitioner eller repliker av den aktuella tjänsten.

Tänk på följande topologi som ett exempel på en tjänst som har fått ökade kapacitetsnivåer:

  • Standard S1-nivå
  • Indexstorlek: 190 GB
  • Antal partitioner: 8 (på S1 är partitionsstorleken 25 GB per partition)
  • Antal repliker: 2
  • Totalt antal sökenheter: 16 (8 partitioner x 2 repliker)
  • Hypotetiskt detaljhandelspris: ~$4 000 USD/månad (anta 250 USD x 16 sökenheter)

Anta att tjänstadministratören fortfarande ser högre svarstider och överväger att lägga till en annan replik. Detta skulle ändra antalet repliker från 2 till 3 och därmed ändra antalet sökenheter till 24 och ett resulterande pris på 6 000 USD/månad.

Men om administratören väljer att flytta till en Standard S2-nivå skulle topologin se ut så här:

  • Standard S2-nivå
  • Indexstorlek: 190 GB
  • Antal partitioner: 2 (på S2 är partitionsstorleken 100 GB per partition)
  • Antal repliker: 2
  • Totalt antal sökenheter: 4 (2 partitioner x 2 repliker)
  • Hypotetiskt detaljhandelspris: ~$4 000 USD/månad (1 000 USD x 4 sökenheter)

Som det här hypotetiska scenariot illustrerar kan du ha konfigurationer på lägre nivåer som resulterar i liknande kostnader som om du hade valt en högre nivå i första hand. Högre nivåer har dock premiumlagring, vilket gör indexeringen snabbare. Högre nivåer har också mycket mer beräkningskraft samt extra minne. För samma kostnader kan du ha en kraftfullare infrastruktur som stöder samma index.

En viktig fördel med extra minne är att mer av indexet kan cachelagras, vilket resulterar i lägre svarstid för sökning och ett större antal frågor per sekund. Med den här extra kraften kanske administratören inte ens behöver öka antalet repliker och kan eventuellt betala mindre än genom att stanna kvar på S1-tjänsten.

Tips: Överväg alternativ till vanliga uttrycksfrågor

Reguljära uttrycksfrågor eller regex kan vara särskilt dyra. Även om de kan vara mycket användbara för avancerade sökningar kan körning kräva mycket bearbetningskraft, särskilt om det reguljära uttrycket är komplicerat eller om du söker igenom en stor mängd data. Alla dessa faktorer bidrar till långa svarstider för sökning. Som en åtgärd kan du försöka förenkla det reguljära uttrycket eller dela upp den komplexa frågan i mindre, mer hanterbara frågor.

Nästa steg

Läs de här andra artiklarna om tjänstprestanda: