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, med dataimport som 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 för 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åll 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. Mappning av dessa begrepp till mer bekanta databasekvivalenter: ett sökindex motsvarar en tabell och dokument motsvarar ungefär rader i en tabell.

Strukturen för ett dokument bestäms av indexschemat, som du ser nedan. Samlingen "fält" är vanligtvis den största delen av ett index, där varje fält namnges, tilldelas en datatypoch tillskrivs med 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 är minimerade av utrymmes skull, men följande länkar kan ge information:

• Förslagslösare stöder förslagsfrågor som automatisk komplettering
• Bedömningsprofiler används för relevansjustering
• Analysverktyg används för att bearbeta strängar till token enligt språkregler eller andra egenskaper som stöds av analysatorn
• CORS (Cross-Origin Remote Scripting) används för appar som utfärdar begäranden från olika domäner
• Krypteringsnyckeln används för dubbelkryptering av känsligt innehåll i indexet.

Fältdefinitioner

Ett sökdokument definieras av samlingen "fält" i brödtexten i Begäran om skapa index. Du behöver fält för dokumentidentifiering (nycklar), lagring av sökbar text och fält för stödfilter, fasetter och sorteringar. 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 till sin natur 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ökresultat är "sorterbara", "filtrerbara" och "faserbara".

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.

Fysisk struktur och storlek

I Azure Cognitive Search är den fysiska strukturen för ett index i stort sett 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, shardsoch andra filer och mappar) hanteras internt av Microsoft.

Storleken på ett index bestäms av:

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

Du kan övervaka indexstorleken på fliken Index i Azure Portal eller genom att skicka en GET INDEX-begäran mot din söktjänst.

Faktorer som påverkar indexstorleken

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älldokumenten innehåller binära fält utelämnar du vanligtvis dessa fält från indexschemat (såvida du inte använder AI-berikning för att knäcka och analysera innehållet för att skapa sökbar textinformation.)

Indexkonfigurationen kan innehålla andra komponenter förutom dokument, till exempel förslagsarbetare, kundanalysverktyg, bedömningsprofiler, CORS-inställningar och krypteringsnyckelinformation. I listan ovan är den enda komponenten som kan påverka indexstorleken förslagshållare. Förslagslösare är konstruktioner som stöder frågor i förväg eller komplettera automatiskt. När du inkluderar en förslagstecken skapar indexeringsprocessen därför de datastrukturer som krävs för ordagranna teckenmatchning. Förslags föreslåre implementeras på fältnivå, så välj bara de fält som är rimliga för i förväg.

Fältattribut är det tredje övervägandet när det gäller indexstorlek. Attribut avgör beteenden. För att stödja dessa beteenden skapar indexeringsprocessen de stödjande datastrukturerna. Till exempel anropar "sökbar" fulltextsökning, som söker igenom inverterade index för den tokeniserade termen. Däremot stöder ett "filtrerbart" eller "sorterbart" attribut iteration över oförändrade strängar.

Exempel som demonstrerar lagringskonsekvenserna av attribut och förslagshållare

Följande skärmbild visar indexlagringsmönster som är resultatet av 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ärda attributen baserat på indexnamnet. Till exempel har realestate-searchable index attributet "searchable" valt och inget annat, realestate-retrievable index har attributet "hämtningsbar" valt och inget annat och så vidare.

Ä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.
• "filtrerbar", "sorterbar", "fasbar" förbrukar mer lagringsutrymme.
• föreslåre har stor potential för att öka indexstorleken, men inte så mycket som skärmbilden skulle visa (alla fält som kan göras förslagsmedveten har valts, vilket inte är ett troligt scenario i de flesta index).

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

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 att ansluta till och skydda ett enda index.

Indexisolering

I Cognitive Search arbetar du med ett index i taget, där alla indexrelaterade åtgärder har ett enda index som mål. Det finns inget begrepp för relaterade index eller sammanfogning av oberoende index för antingen indexering eller frågor.

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 innehållet 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 sammanträffar 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 byggsom väljer vissa kunder som gör små ändringar att "versionsutjämna" 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 definitioner för anpassade analysverktyg, 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 livscykelhanteringen för index.

Slutpunktsanslutning och säkerhet

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

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 bör 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.

• Skapa ett sökindex

• Översikt över dataimport

• Lägga till, uppdatera eller ta bort dokument (REST)