Index i Azure Cognitive Search

I Azure Cognitive Search är ett sökindex ditt sökbara innehåll som är tillgängligt för sökmotorn för indexering, fulltextsökning och filtrerade frågor. Ett index definieras av ett schema och sparas i söktjänsten, där dataimporten följer som ett andra steg. Det här innehållet finns i söktjänsten, förutom dina primära datalager, vilket är nödvändigt för de millisekunders svarstider som förväntas i moderna program. Förutom specifika indexeringsscenarier ansluter söktjänsten aldrig till eller frågar dina lokala data.

Om du skapar och hanterar ett sökindex hjälper den här artikeln dig att förstå följande:

  • Innehåll (dokument och schema)
  • Fysisk representation
  • Grundläggande åtgärder

Föredrar du att vara praktisk direkt? Se Skapa ett sökindex i stället.

Innehållet i ett sökindex

I Cognitive Search innehåller index sökdokument. Konceptuellt är ett dokument en enda enhet med sökbara data i ditt index. En återförsäljare kan till exempel ha ett dokument för varje produkt, en nyhetsorganisation kan ha ett dokument för varje artikel, en resewebbplats kan ha ett dokument för varje hotell och destination och så vidare. Mappa dessa begrepp till mer välbekanta databasmotsvarigheter: ett sökindex motsvarar en tabell och dokument motsvarar i stort sett rader i en tabell.

Strukturen för ett dokument bestäms av indexschemat enligt nedan. Samlingen "fält" är vanligtvis den största delen av ett index, där varje fält namnges, tilldelas en datatyp och tillskrivs tillåtna beteenden som avgör hur det används.

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "synonymMaps": [ "name_of_synonym_map" ] (optional, only one synonym map per field is currently supported)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ }
  }
}

Andra element döljs för korthet, men följande länkar kan ge information:

Fältdefinitioner

Ett sökdokument definieras av samlingen "fält" i brödtexten i Begäran om att skapa index. Du behöver fält för dokumentidentifiering (nycklar), lagring av sökbar text och fält för stödfilter, faser och sortering. Du kan också behöva fält för data som en användare aldrig ser. Du kanske till exempel vill ha fält för vinstmarginaler eller marknadsföringskampanjer som du kan använda för att ändra sökrankning.

Om inkommande data är hierarkiska kan du representera dem i ett index som en komplex typ som används för att representera kapslade strukturer. Den inbyggda exempeldatauppsättningen Hotels illustrerar komplexa typer med hjälp av en adress (innehåller flera underfält) som har en en-till-en-relation med varje hotell och en komplex samling rum, där flera rum är associerade med varje hotell.

Fältattribut

Fältattributen avgör hur ett fält används, till exempel om det används i fulltextsökning, fasetterad navigering, sorteringsåtgärder och så vidare.

Strängfält markeras ofta som "sökbara" och "hämtningsbara". Fält som används för att begränsa sökresultaten är "sortable", "filterable" och "facetable".

Attribut Beskrivning
"sökbar" Fulltextsökbart och omfattas av lexikal analys som radbrytning under indexering. Om du anger ett sökbart fält till ett värde som ”solig dag” delas det upp internt i två enskilda token, ”solig” och ”dag”. Mer information finns i Hur fulltextsökning fungerar.
"filterbar" Refereras till i $filter-frågor. Filtrerbara fält av typen Edm.String eller Collection(Edm.String) genomgår inte ordseparation, så jämförelserna gäller endast exakta matchningar. Om du till exempel anger ”solig dag” för ett sådant fält hittar inte $filter=f eq 'sunny' några matchningar, men det gör $filter=f eq 'sunny day'.
"sorterbar" Som standard sorterar systemet resultaten efter bedömning, men du kan konfigurera sortering som baseras på fält i dokumenten. Fält av typen Collection(Edm.String) kan inte vara "sorterbara".
"facetable" Används vanligtvis i en presentation av sökresultat som innehåller ett antal träffar efter kategori (till exempel hotell på en viss ort). Det här alternativet kan inte användas med fält av typen Edm.GeographyPoint. Fält av typen Edm.String som är filterbara, "sorterbara" eller "fasettbara" kan vara högst 32 kilobyte långa. Mer information finns i Skapa index (REST-API).
"nyckel" Unik identifierare för dokument i indexet. Exakt ett fält måste väljas som nyckelfält, och det måste vara av typen Edm.String.
"Hämtningsbar" Anger om fältet kan returneras i ett sökresultat. Detta är användbart om du vill använda ett fält (som vinstmarginal) som ett filter eller en sorterings- eller bedömningsmekanism, men inte vill att fältet ska visas för användaren. Det här attributet måste vara true för key-fält.

Du kan visserligen lägga till nya fält när som helst, men befintliga fältdefinitioner är låsta under indexets hela livslängd. Av den anledningen använder många utvecklare portalen för att skapa enkla index, testa idéer och använda portalsidorna för att söka reda på en inställning. Frekvent upprepning av en indexdesign är mer effektiv om du följer en kodbaserad metod så att du enkelt kan återskapa indexet.

Anteckning

De API:er som du använder för att skapa ett index har olika standardbeteenden. För REST-API:er är de flesta attribut aktiverade som standard (till exempel "sökbara" och "hämtningsbara" är sanna för strängfält) och du behöver ofta bara ange dem om du vill inaktivera dem. För .NET SDK är det motsatta sant. På alla egenskaper som du inte uttryckligen anger är standardinställningen att inaktivera motsvarande sökbeteende såvida du inte uttryckligen aktiverar det.

Fysisk struktur och storlek

I Azure Cognitive Search är den fysiska strukturen för ett index till stor del en intern implementering. Du kan komma åt dess schema, fråga dess innehåll, övervaka dess storlek och hantera kapacitet, men själva klustren (index, shards och andra filer och mappar) hanteras internt av Microsoft.

Du kan övervaka indexstorleken på fliken Index i Azure-portalen eller genom att utfärda en GET INDEX-begäran mot din söktjänst. Du kan också utfärda en tjänststatistikbegäran och kontrollera värdet för lagringsstorleken.

Storleken på ett index bestäms av:

  • Kvantitet och sammansättning av dina dokument
  • Attribut för enskilda fält
  • Indexkonfiguration (specifikt om du inkluderar förslagsgivare)

Dokumentsammansättning och kvantitet bestäms av vad du väljer att importera. Kom ihåg att ett sökindex endast ska innehålla sökbart innehåll. Om källdata innehåller binära fält utelämnar du dessa fält om du inte använder AI-berikning för att knäcka och analysera innehållet för att skapa sökbar textinformation.

Fältattribut bestämmer beteenden. För att stödja dessa beteenden skapar indexeringsprocessen nödvändiga datastrukturer. Till exempel anropar "sökbar" fulltextsökning, som genomsöker inverterade index för den tokeniserade termen. Däremot stöder ett "filterbart" eller "sorterbart" attribut iteration över oförändrade strängar. Exemplet i nästa avsnitt visar variationer i indexstorleken baserat på de valda attributen.

Förslagsgivare är konstruktioner som stöder frågor av typen framåt eller komplettera automatiskt. När du inkluderar en förslagsvisare skapar indexeringsprocessen därför de datastrukturer som krävs för ordagranna teckenmatchningar. Förslagsgivare implementeras på fältnivå, så välj bara de fält som är rimliga för typ framåt.

Exempel som visar lagringskonsekvenserna av attribut och förslagsgivare

Följande skärmbild illustrerar indexlagringsmönster som beror på olika kombinationer av attribut. Indexet baseras på exempelindexet för fastigheter, som du enkelt kan skapa med hjälp av guiden Importera data och inbyggda exempeldata. Även om indexscheman inte visas kan du härleda attributen baserat på indexnamnet. Till exempel har realestate-searchable index attributet "searchable" markerat och inget annat, realestate-retrievable index har attributet "retrievable" markerat och inget annat och så vidare.

Index size based on attribute selection

Även om dessa indexvarianter är något artificiella kan vi referera till dem för breda jämförelser av hur attribut påverkar lagring:

  • "Hämtningsbar" påverkar inte indexstorleken.
  • "filterable", "sortable", "facetable" förbrukar mer lagringsutrymme.
  • suggester har en stor potential för att öka indexstorleken, men inte så mycket som skärmbilden skulle indikera (alla fält som kan göras suggestermedvetna har valts, vilket inte är ett troligt scenario i de flesta index).

Inte heller visas i tabellen ovan effekten av analysverktyg. Om du använder edgeNgram-tokeniseraren för att lagra ordagrant sekvenser med tecken (a, ab, abc, abcd) blir indexets storlek större än om du använde en standardanalys.

Grundläggande åtgärder och interaktion

Nu när du har en bättre uppfattning om vad ett index är introducerar det här avsnittet åtgärder för indexkörning, inklusive anslutning till och skydd av ett enda index.

Anteckning

När du hanterar ett index bör du vara medveten om att det inte finns något portal- eller API-stöd för att flytta eller kopiera ett index. I stället pekar kunderna vanligtvis sin programdistributionslösning på en annan söktjänst (om de använder samma indexnamn) eller ändrar namnet för att skapa en kopia av den aktuella söktjänsten och skapar den sedan.

Indexisolering

I Cognitive Search arbetar du med ett index i taget, där alla indexrelaterade åtgärder riktar in sig på ett enda index. Det finns inget begrepp om relaterade index eller sammanfogning av oberoende index för antingen indexering eller frågekörning.

Kontinuerligt tillgänglig

Ett index är kontinuerligt tillgängligt, utan möjlighet att pausa eller ta det offline. Eftersom det är utformat för kontinuerlig drift sker alla uppdateringar av dess innehåll, eller tillägg till själva indexet, i realtid. Därför kan frågor tillfälligt returnera ofullständiga resultat om en begäran sammanfaller med en dokumentuppdatering.

Observera att frågekontinuitet finns för dokumentåtgärder (uppdatering eller borttagning) och för ändringar som inte påverkar den befintliga strukturen och integriteten för det aktuella indexet (till exempel att lägga till nya fält). Om du behöver göra strukturella uppdateringar (ändra befintliga fält) hanteras de vanligtvis med hjälp av ett drop-and-rebuild-arbetsflöde i en utvecklingsmiljö eller genom att skapa en ny version av indexet för produktionstjänsten.

För att undvika att index återskapas väljer vissa kunder som gör små ändringar att "version" ett fält genom att skapa ett nytt som samexisterar tillsammans med en tidigare version. Med tiden leder detta till överblivet innehåll i form av föråldrade fält eller föråldrade anpassade analysdefinitioner, särskilt i ett produktionsindex som är dyrt att replikera. Du kan åtgärda dessa problem vid planerade uppdateringar av indexet som en del av indexets livscykelhantering.

Slutpunktsanslutning och säkerhet

Alla indexerings- och frågebegäranden riktar sig mot ett index. Slutpunkter är vanligtvis något av följande:

Slutpunkt Anslutning och åtkomstkontroll
<your-service>.search.windows.net/indexes Mål för indexsamlingen. Används när du skapar, listar eller tar bort ett index. Administratörsrättigheter krävs för dessa åtgärder, som är tillgängliga via administratörs-API-nycklar eller en sökdeltagareroll.
<your-service>.search.windows.net/indexes/<your-index>/docs Riktar in sig på dokumentsamlingen för ett enda index. Används när du kör frågor mot ett index eller en datauppdatering. För frågor är läsbehörigheter tillräckliga och tillgängliga via fråge-API-nycklar eller en dataläsarroll. För datauppdatering krävs administratörsbehörighet.

Nästa steg

Du kan få praktisk erfarenhet av att skapa ett index med nästan alla exempel eller genomgångar för Cognitive Search. Till att börja med kan du välja någon av snabbstarterna från innehållsförteckningen.

Men du vill också bekanta dig med metoder för att läsa in ett index med data. Strategier för indexdefinition och dataimport definieras tillsammans. Följande artiklar innehåller mer information om hur du skapar och läser in ett index.