Indexen in Azure Cognitive Search

In Azure Cognitive Search is een zoekindex uw doorzoekbare inhoud, die beschikbaar is voor de zoekmachine voor indexering, zoeken in volledige tekst en gefilterde query's. Een index wordt gedefinieerd door een schema en opgeslagen in de zoekservice, met gegevensimport als tweede stap. Deze inhoud bevindt zich in uw zoekservice, afgezien van uw primaire gegevensopslag, wat nodig is voor de reactietijden van milliseconden die in moderne toepassingen worden verwacht. Met uitzondering van specifieke indexeringsscenario's kan de zoekservice nooit verbinding maken met uw lokale gegevens of er query's op uitvoeren.

Als u een zoekindex maakt en beheert, helpt dit artikel u het volgende te begrijpen:

  • Inhoud (documenten en schema)
  • Fysieke weergave
  • Basisbewerkingen

Wilt u liever direct aan de praktijk doen? Zie in plaats daarvan Een zoekindex maken.

Inhoud van een zoekindex

In Cognitive Search bevatten indexen zoekdocumenten. Conceptueel gezien is een document één eenheid met doorzoekbare gegevens in uw index. Een detailhandelaar kan bijvoorbeeld een document voor elk product hebben, een nieuwsorganisatie heeft mogelijk een document voor elk artikel, een reissite kan een document hebben voor elk hotel en elke bestemming, enzovoort. Deze concepten toewijzen aan meer vertrouwde database-equivalenten: een zoekindex is gelijk aan een tabel en documenten zijn ongeveer gelijk aan rijen in een tabel.

De structuur van een document wordt bepaald door het indexschema, zoals hieronder wordt geïllustreerd. De verzameling 'velden' is doorgaans het grootste deel van een index, waarbij elk veld een naam krijgt, een gegevenstype wordt toegewezen en met toegestane gedragingen wordt toegewezen die bepalen hoe het wordt gebruikt. 

{
  "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){ }
  }
}

Andere elementen zijn samengevouwen voor de beknoptheid, maar de volgende koppelingen kunnen de details bevatten:

Velddefinities

Een zoekdocument wordt gedefinieerd door de verzameling 'velden' in de hoofdverzameling van Indexaanvraag maken. U hebt velden nodig voor documentidentificatie (sleutels), het opslaan van doorzoekbare tekst en velden voor ondersteunende filters, facetten en sorteert. Mogelijk hebt u ook velden nodig voor gegevens die een gebruiker nooit ziet. U wilt bijvoorbeeld velden voor winstmarges of marketingacties die u kunt gebruiken om de zoekrangschikking te wijzigen.

Als binnenkomende gegevens hiërarchisch van aard zijn, kunt u deze in een index als een complex typevertegenwoordigen, dat wordt gebruikt om geneste structuren weer te geven. De ingebouwde voorbeeldgegevensset Hotels illustreert complexe typen met behulp van een adres (bevat meerdere subvelden) met een een-op-een-relatie met elk hotel en een complexe verzameling Ruimten, waarbij meerdere ruimten aan elk hotel zijn gekoppeld.

Veldkenmerken

Veldkenmerken bepalen hoe een veld wordt gebruikt, bijvoorbeeld of het wordt gebruikt voor zoeken in volledige tekst, facetnavigatie, sorteerbewerkingen, enzovoort.

Tekenreeksvelden worden vaak gemarkeerd als 'doorzoekbaar' en 'ophaalbaar'. Velden die worden gebruikt om zoekresultaten te beperken, zijn 'sorteerbaar', 'filterbaar' en 'facetbaar'.

Kenmerk Beschrijving
'doorzoekbaar' Zoeken in volledige tekst mogelijk, onderworpen aan lexicale analyse, zoals het afbreken van woorden tijdens het indexeren. Als u een doorzoekbaar veld instelt op een waarde als 'zonnige dag', wordt de waarde intern gesplitst in de afzonderlijke tokens 'zonnige' en 'dag'. Zie Hoe zoeken in de volledige tekst werkt voor meer informatie.
'filterbaar' Hier wordt naar verwezen in $filter-query's. Bij filterbare velden van het type Edm.String of Collection(Edm.String) worden woorden niet afgebroken, dus vergelijkingen gelden alleen voor exacte overeenkomsten. Als u zo'n veld bijvoorbeeld instelt op 'zonnige dag', worden er met $filter=f eq 'sunny' geen overeenkomsten gevonden, maar met $filter=f eq 'sunny day' wel.
'sorteerbaar' Het systeem sorteert de resultaten standaard op score, maar u kunt het sorteren configureren op basis van velden in de documenten. Velden van het type Collection(Edm.String) kunnen niet 'sorteerbaar' zijn.
'Facetable' Wordt doorgaans gebruikt bij een weergave van zoekresultaten met een treffertelling per categorie (bijvoorbeeld hotels in een specifieke stad). Deze optie kan niet worden gebruikt bij velden van het type Edm.GeographyPoint. Velden van het type die filterbaar, sorteerbaar of facetbaar zijn, kunnen uit een lengte van Edm.String 32 kilobytes komen. Zie Index maken (REST API) voor meer informatie.
'sleutel' Unieke id voor documenten binnen de index. Er moet precies één veld worden uitgekozen als sleutelveld. Dit veld moet van het type Edm.String zijn.
'Ophalen mogelijk' Hiermee bepaalt u of het veld in een zoekresultaat kan worden geretourneerd. Dit is handig als u een veld (zoals winstmarge) wilt gebruiken als filter-, sorteer- of scoremechanisme, maar niet wilt dat het veld zichtbaar is voor de eindgebruiker. Dit kenmerk moet true zijn voor key-velden.

Hoewel u op elk gewenst moment nieuwe velden kunt toevoegen, worden bestaande velddefinities voor de hele levensduur van de index vergrendeld. Daarom gebruiken ontwikkelaars de portal doorgaans om eenvoudige indexen te maken, om ideeën uit te testen of om een instelling op te zoeken met behulp van de portalpagina's. Een frequente iteratie van een index-ontwerp is efficiënter als u een op code gebaseerde benadering hanteert, zodat u uw index eenvoudig kunt herbouwen.

Notitie

De API's die u gebruikt om een index te bouwen, hebben verschillend standaardgedrag. Voor de REST API'szijn de meeste kenmerken standaard ingeschakeld (bijvoorbeeld 'doorzoekbaar' en 'ophaalbaar' zijn waar voor tekenreeksvelden) en hoeft u deze vaak alleen in te stellen als u ze wilt uitschakelen. Voor de .NET SDK is het tegenovergestelde waar. Voor elke eigenschap die u niet expliciet in stelt, wordt standaard het bijbehorende zoekgedrag uitgeschakeld, tenzij u dit specifiek inschakelen.

Fysieke structuur en grootte

In Azure Cognitive Search is de fysieke structuur van een index grotendeels een interne implementatie. U kunt het schema openen, de inhoud ervan opvragen, de grootte ervan controleren en de capaciteit beheren, maar de clusters zelf (indexen, shardsen andere bestanden en mappen) worden intern beheerd door Microsoft.

De grootte van een index wordt bepaald door:

  • Hoeveelheid en samenstelling van uw documenten
  • Indexconfiguratie (met name of u suggesters op te nemen)
  • Kenmerken van afzonderlijke velden

U kunt de indexgrootte controleren op het tabblad Indexen in de Azure Portal of door een GET INDEX-aanvraag uit te geven voor uw zoekservice.

Factoren die invloed hebben op de indexgrootte

De samenstelling en hoeveelheid van het document worden bepaald door wat u wilt importeren. Een zoekindex mag alleen doorzoekbare inhoud bevatten. Als brondocumenten binaire velden bevatten, laat u deze velden doorgaans weg uit het indexschema (tenzij u AI-verrijking gebruikt om de inhoud te kraken en te analyseren om doorzoekbare tekstinformatie te maken.)

Indexconfiguratie kan naast documenten ook andere onderdelen bevatten, zoals suggesters, klantanalyses, scoreprofielen, CORS-instellingen en informatie over versleutelingssleutels. In de bovenstaande lijst zijn suggesters het enige onderdeel dat invloed kan hebben op de indexgrootte. Suggesties zijn constructies die ondersteuning bieden voor type-ahead- of automatisch aanvullen van query's. Als u dus een suggester op neemt, worden tijdens het indexeringsproces de gegevensstructuren gemaakt die nodig zijn voor verbatimtekens. Suggesties worden geïmplementeerd op veldniveau, dus kies alleen de velden die redelijk zijn voor type-ahead.

Veldkenmerken zijn de derde overweging van de indexgrootte. Kenmerken bepalen gedrag. Ter ondersteuning van dit gedrag worden tijdens het indexeringsproces de ondersteunende gegevensstructuren gemaakt. 'Doorzoekbaar' roept bijvoorbeeld zoeken in volledige tekst aan,waarmee omgekeerde indexen worden gescand op de tokenized term. Een filterbaar of sorteerbaar kenmerk ondersteunt daarentegen iteratie over ongewijzigde tekenreeksen.

Voorbeeld van het demonstreren van de opslag-implicaties van kenmerken en suggesties

In de volgende schermopname ziet u de opslagpatronen van de index die het gevolg zijn van verschillende combinaties van kenmerken. De index is gebaseerd op de voorbeeldindex voor onroerend goed, die u eenvoudig kunt maken met behulp van de wizard Gegevens importeren en ingebouwde voorbeeldgegevens. Hoewel de indexschema's niet worden weergegeven, kunt u de kenmerken afleiden op basis van de indexnaam. De index realestate-searchable heeft bijvoorbeeld het kenmerk 'doorzoekbaar' geselecteerd en niets anders, de index 'ophaalbaar' is geselecteerd en niets anders, enzovoort.

Indexgrootte op basis van kenmerkselectie

Hoewel deze indexvarianten enigszins kunstmatig zijn, kunnen we hier naar verwijzen voor algemene vergelijkingen van hoe kenmerken van invloed zijn op opslag:

  • 'Ophalen mogelijk' heeft geen invloed op de indexgrootte.
  • 'filterbaar', 'sorteerbaar', 'facetbaar' verbruiken meer opslag.
  • suggester heeft een groot potentieel voor het vergroten van de indexgrootte, maar niet zo veel als de schermopname zou aangeven (alle velden die kunnen worden gemaakt met suggesties zijn geselecteerd, wat in de meeste indexen waarschijnlijk geen scenario is).

Ook niet weergegeven in de bovenstaande tabel is de impact van analyse. Als u de edgeNgram-tokenizer gebruikt voor het opslaan van verbatimreeksen van tekens (a, ab, abc, abcd), is de grootte van de index groter dan wanneer u een standaardanalyse gebruikt.

Basisbewerkingen en interactie

Nu u een beter beeld hebt van wat een index is, worden in deze sectie run time-bewerkingen voor indexen introduceert, waaronder het verbinden met en beveiligen van één index.

Notitie

Wanneer u een index beheert, moet u er rekening mee houden dat er geen portal- of API-ondersteuning is voor het verplaatsen of kopiëren van een index. In plaats daarvan wijzen klanten hun toepassingsimplementatieoplossing doorgaans naar een andere zoekservice (als ze dezelfde indexnaam gebruiken), of herzien ze de naam om een kopie te maken van de huidige zoekservice en bouwen ze deze vervolgens.

Indexisolatie

In Cognitive Search werkt u met één index tegelijk, waarbij alle indexgerelateerde bewerkingen zijn gericht op één index. Er is geen concept van gerelateerde indexen of het samenvoegen van onafhankelijke indexen voor indexering of query's.

Continu beschikbaar

Een index is continu beschikbaar, zonder de mogelijkheid om deze te onderbreken of offline te halen. Omdat het is ontworpen voor continue werking, vinden updates van de inhoud of toevoegingen aan de index zelf in realtime uit. Als gevolg hiervan kunnen query's tijdelijk onvolledige resultaten retourneren als een aanvraag samenvalt met een documentupdate.

U ziet dat er querycontinuïteit bestaat voor documentbewerkingen (vernieuwen of verwijderen) en voor wijzigingen die geen invloed hebben op de bestaande structuur en integriteit van de huidige index (zoals het toevoegen van nieuwe velden). Als u structurele updates moet maken (bestaande velden moet wijzigen), worden deze doorgaans beheerd met behulp van een werkstroom voor neerzetten en opnieuw opbouwen in een ontwikkelomgeving of door een nieuwe versie van de index te maken in de productieservice.

Om te voorkomen dat een indexopnieuw wordt opgebouwd, kiezen sommige klanten die kleine wijzigingen aanbrengen ervoor om een veld te 'versien' door een nieuw veld te maken dat naast een eerdere versie wordt gebruikt. Na een periode leidt dit tot zwevende inhoud in de vorm van verouderde velden of verouderde aangepaste analyzerdefinities, met name in een productie-index die duur is om te repliceren. U kunt deze problemen bij geplande updates van de index oplossen als onderdeel van het levenscyclusbeheer van de index.

Eindpuntverbinding en -beveiliging

Alle indexerings- en queryaanvragen zijn gericht op een index. Eindpunten zijn meestal een van de volgende:

Eindpunt Verbindings- en toegangsbeheer
<your-service>.search.windows.net/indexes Is gericht op de verzameling indexen. Wordt gebruikt bij het maken, in een lijst bekijken of verwijderen van een index. Beheerdersrechten zijn vereist voor deze bewerkingen, die beschikbaar zijn via API-sleutels voor beheerders of de rol Inzender voor zoeken.
<your-service>.search.windows.net/indexes/<your-index>/docs Is gericht op de verzameling documenten van één index. Wordt gebruikt bij het uitvoeren van query's op een index of het vernieuwen van gegevens. Voor query's zijn leesrechten voldoende en beschikbaar via API-sleutels voor query's of een rol gegevenslezer. Voor het vernieuwen van gegevens zijn beheerdersrechten vereist.

Volgende stappen

U kunt praktijkervaring opdoen met het maken van een index met behulp van vrijwel elk voorbeeld of overzicht voor Cognitive Search. Om te beginnen kunt u een van de quickstarts uit de inhoudsopgave kiezen.

Maar u wilt ook vertrouwd raken met methodologieën voor het laden van een index met gegevens. Strategieën voor indexdefinitie en gegevensimport worden samen gedefinieerd. De volgende artikelen bevatten meer informatie over het maken en laden van een index.