Indexy v Azure Kognitivní hledání

Ve službě Azure Kognitivní hledání je Rejstřík hledání obsahem, který je k dispozici pro vyhledávací web pro indexování, fulltextové vyhledávání a filtrované dotazy. Index je definován schématem a uložen do vyhledávací služby, přičemž import dat probíhá jako druhý krok. Tento obsah se nachází v rámci vaší vyhledávací služby od primárních úložišť dat, která jsou nezbytná pro doby odezvy milisekund v moderních aplikacích. S výjimkou konkrétních scénářů indexování se služba Search nikdy nepřipojí k místním datům nebo se do ní bude dotazovat.

Pokud vytváříte a spravujete vyhledávací index, Tento článek vám pomůže pochopit následující:

• Obsah (dokumenty a schéma)
• Fyzická reprezentace
• Základní operace

Přejete si se hned hned začít? Místo toho se podívejte na téma Vytvoření indexu vyhledávání .

Obsah indexu hledání

V Kognitivní hledání indexy obsahují dokumenty pro hledání. V koncepčním dokumentu je dokument jediná jednotka prohledávatelných dat v indexu. Například prodejce může mít dokument pro každý produkt, organizace zpráv může mít dokument pro každý článek, cestovní web může mít dokument pro každý Hotel a cíl a tak dále. Mapování těchto konceptů na podrobnější ekvivalenty databáze: Index vyhledávání se rovná tabulce a dokumenty zhruba odpovídají řádkům v tabulce.

Struktura dokumentu je určena schématem indexu, jak je znázorněno níže. Kolekce "Fields" je obvykle největší částí indexu, kde se každé pole jmenuje, přiřadí datový typa má atribut s povoleným chováním, který určuje, jak se používá.

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

Další prvky jsou sbaleny pro zkrácení, ale následující odkazy mohou poskytnout podrobnosti:

• Moduly pro návrhy podporují dotazy typu dopředu, jako je automatické dokončování.
• Profily vyhodnocování se používají pro optimalizaci závažnosti.
• Analyzátory se používají ke zpracování řetězců do tokenů podle lingvistických pravidel nebo jiných vlastností, které analyzátor podporuje.
• Pro aplikace, které vystavují požadavky z různých domén, se používá vzdálené SKRIPTOVÁNÍ CORS (pro více zdrojů) .
• Šifrovací klíč se používá pro dvojité šifrování citlivého obsahu v indexu.

Definice polí

Dokument hledání je definován kolekcí "pole" v těle žádosti o vytvoření indexu. Budete potřebovat pole pro identifikaci dokumentu (klíče), ukládání vyhledávaného textu a pole pro podpůrné filtry, omezující vlastnosti a řazení. Můžete také potřebovat pole pro data, která se uživateli nikdy nevidí. Můžete například potřebovat pole pro ziskové marže nebo marketingové propagační akce, které můžete použít k úpravě pořadí hledání.

Pokud jsou příchozí data hierarchicky vymezena, můžete ji reprezentovat v rámci indexu jako komplexní typ, který se používá k reprezentaci vnořených struktur. Integrovaná Ukázková sada dat, hotely, znázorňuje komplexní typy pomocí adresy (obsahuje několik dílčích polí), které mají vztah 1:1 s každým hotelem, a prostorově komplexní kolekci, kde je k jednotlivým hotelům přidruženo více místností.

Atributy polí

Atributy polí určují, jak se pole používá, například jestli se používá ve fulltextovém vyhledávání, fasetové navigaci, operacích řazení a tak dále.

Pole řetězců jsou často označena jako "prohledávatelné" a "získatelné". Mezi pole, která se používají k zúžení výsledků hledání, patří "seřaditelné", "filtrovatelné" a "FACET".

I když můžete nová pole přidat kdykoliv, jsou existující definice polí zamknuté v indexu po dobu jeho existence. Z tohoto důvodu vývojáři obvykle používají portál k vytváření jednoduchých indexů, testování nápadů nebo k vyhledání nastavení pomocí stránek portálu. Časté změny návrhu indexu jsou efektivnější, pokud budete postupovat pomocí kódu, aby bylo možné index snadno znovu sestavit.

Fyzická struktura a velikost

Ve službě Azure Kognitivní hledání má fyzická struktura indexu převážně interní implementaci. Můžete mít přístup ke svému schématu, dotazovat se na jeho obsah, monitorovat jeho velikost a spravovat kapacitu, ale samotné clustery (indexy, horizontálních oddílůa další soubory a složky) jsou interně spravované společností Microsoft.

Velikost indexu Určuje:

• Množství a složení dokumentů
• Konfigurace indexu (konkrétně bez ohledu na to, jestli jste zahrnuli moduly pro návrhy)
• Atributy u jednotlivých polí

Velikost indexu můžete monitorovat na kartě indexy v Azure Portal nebo vyvoláním žádosti o získání indexu na vyhledávací službě.

Faktory ovlivňující velikost indexu

Složení a množství dokumentu se určí podle toho, co se rozhodnete importovat. Pamatujte, že index vyhledávání by měl obsahovat pouze prohledávatelný obsah. Pokud zdrojové dokumenty obsahují binární pole, obvykle byste tato pole vynechal ze schématu indexu (Pokud nepoužíváte rozšíření AI k prolomení a analýze obsahu pro vytváření vyhledávaných informací.)

Konfigurace indexu může zahrnovat další součásti kromě dokumentů, jako jsou moduly pro návrhy, analyzátory zákazníků, profily vyhodnocování, nastavení CORS a informace o šifrovacích klíčích. V seznamu výše jsou jedinými součástmi, které mají potenciální dopad na velikost indexu, návrhy. Moduly pro návrhy jsou konstrukce, které podporují dotazy typu dopředu nebo automatické dokončování. V takovém případě, když zahrnete návrh, proces indexování vytvoří datové struktury nezbytné pro doslovné shody znaků. Moduly pro návrhy jsou implementovány na úrovni pole, takže vyberte pouze ta pole, která jsou pro typ dopředu přiměřená.

Atributy pole jsou třetí aspektem velikosti indexu. Atributy určují chování. Pro podporu tohoto chování vytvoří proces indexování podpůrné datové struktury. Například "prohledávatelné" vyvolá fulltextové vyhledávání, které kontroluje obrácené indexy pro termín s tokenem. Naproti tomu atribut "Filtered" nebo "řaditelné" podporuje iteraci v nezměněných řetězcích.

Příklad demonstrující důsledky pro úložiště atributů a návrhů

Následující snímek obrazovky znázorňuje vzory úložiště indexů, které jsou výsledkem různých kombinací atributů. Index je založen na indexu ukázek reálného majetku, který můžete snadno vytvořit pomocí Průvodce importem dat a vestavěných ukázkových dat. I když nejsou uvedena schémata indexu, můžete odvodit atributy na základě názvu indexu. Index s možností prohledávání realestate má například vybraný atribut "prohledávatelné" a nic jiného, index realestate má vybraný atribut "získatelné" a nic jiného a tak dále.

I když jsou tyto varianty indexu trochu umělé, můžeme na ně odkazovat, aby bylo možné využít široké porovnání atributů úložiště:

• možnost "získatelné" nemá žádný vliv na velikost indexu.
• "filtrovatelné", "seřaditelné" a "FACET" spotřebovávají větší úložiště.
• modul pro návrhy má velký potenciál pro zvýšení velikosti indexu, ale ne tak daleko, jak by snímek obrazovky označoval (všechna pole, která by se dala udělat, což není pravděpodobný scénář ve většině indexů).

Nereflektují se také v tabulce výše je dopad analyzátorů. Pokud používáte edgeNgram provádějících tokenizaci k ukládání doslovnéch sekvencí znaků (a, AB, ABC, abcd), velikost indexu bude větší než při použití standardního analyzátoru.

Základní operace a interakce

Teď, když máte lepší představu o tom, co index je, Tato část zavádí operace indexu v době běhu, včetně připojení a zabezpečení jediného indexu.

Izolace indexu

V Kognitivní hledání budete pracovat s jedním indexem v čase, kde všechny operace související s indexem cílí na jeden index. Neexistuje žádný koncept souvisejících indexů ani připojování nezávislých indexů pro indexování nebo dotazování.

Nepřetržitě dostupné

Index je nepřetržitě dostupný bez možnosti pozastavit nebo převést do režimu offline. Vzhledem k tomu, že je navržená pro nepřetržitou práci, všechny aktualizace jeho obsahu nebo dodatky samotného indexu probíhá v reálném čase. V důsledku toho mohou dotazy dočasně vracet neúplné výsledky, pokud se požadavek shoduje s aktualizací dokumentu.

Všimněte si, že kontinuita dotazů existuje pro operace dokumentů (aktualizace nebo odstraňování) a pro úpravy, které neovlivňují stávající strukturu a integritu aktuálního indexu (například přidávání nových polí). Pokud potřebujete provést strukturální aktualizace (změna stávajících polí), jsou obvykle spravovány pomocí pracovního postupu pro opětovné sestavení ve vývojovém prostředí nebo vytvořením nové verze indexu v produkční službě.

Aby se zabránilo opětovnému sestavení indexu, můžou někteří zákazníci, kteří provádějí malé změny, zvolit pole "verze" a vytvořit nové, které společně s předchozí verzí. V průběhu času to vede k osamocenému obsahu ve formě zastaralých polí nebo zastaralých definicí vlastního analyzátoru, zejména v produkčním indexu, který je náročný na replikaci. Tyto problémy s plánovanými aktualizacemi můžete vyřešit v indexu v rámci správy životního cyklu indexu.

Připojení a zabezpečení koncového bodu

Všechny požadavky na indexování a dotazy cílí na index. Koncovými body jsou obvykle jedna z následujících:

Další kroky

Praktické zkušenosti s vytvářením indexu můžete získat téměř jakoukoli ukázkou nebo návodem pro Kognitivní hledání. Pro Starter můžete zvolit některý z rychlých startů z obsahu.

Ale taky budete chtít seznámit s metodologiemi pro načítání indexu s daty. Definice indexu a strategie importu dat jsou definovány společně. Následující články poskytují další informace o vytvoření a načtení indexu.

• Vytvoření vyhledávacího indexu

• Přehled importu dat

• Přidávání, aktualizace a odstraňování dokumentů (REST)