Tipy pro lepší výkon ve službě Azure AI Search

Článek
12/10/2024

Tento článek je kolekce tipů a osvědčených postupů pro zvýšení výkonu dotazů a indexování pro vyhledávání klíčových slov. Znalost faktorů, které s největší pravděpodobností ovlivňují výkon vyhledávání, vám může pomoct vyhnout se neektivosti a maximálně využít vyhledávací službu. Mezi klíčové faktory patří:

Složení indexu (schéma a velikost)
Návrh dotazu
Kapacita služby (úroveň a počet replik a oddílů)

Poznámka:

Hledáte strategie indexování s velkým objemem? Viz Indexování velkých datových sad ve službě Azure AI Search.

Velikost a schéma indexu

Dotazy běží rychleji na menších indexech. Je to částečně funkce menšího počtu polí ke kontrole, ale je to také kvůli tomu, jak systém ukládá obsah do mezipaměti pro budoucí dotazy. Po prvním dotazu zůstane nějaký obsah v paměti, kde se prohledávají efektivněji. Vzhledem k tomu, že velikost indexu v průběhu času roste, jedním z osvědčených postupů je pravidelné opakování složení indexů, jak schémata, tak dokumenty, aby se vyhledaly příležitosti ke snížení obsahu. Pokud je ale index správně velký, jedinou další kalibrací, kterou můžete provést, je zvýšit kapacitu: buď přidáním replik, nebo upgradem úrovně služby. Část Tip: Upgrade na úroveň Standard S2 popisuje rozhodnutí vertikálního navýšení kapacity a horizontálního navýšení kapacity.

Složitost schématu může také nepříznivě ovlivnit výkon indexování a dotazů. Nadměrné přisuzování polí se vytváří v omezeních a požadavcích na zpracování. Indexování a dotazování složitých typů trvá déle. V dalších několika částech se seznámíte s každou podmínkou.

Tip: Přisuzovat pole selektivně

Běžnou chybou, kterou správci a vývojáři dělají při vytváření indexu vyhledávání, je výběr všech dostupných vlastností pro pole, a ne jen výběru potřebných vlastností. Pokud například pole nemusí být prohledávatelné fulltextově, při nastavování prohledávatelného atributu toto pole přeskočte.

Podpora filtrů, omezujících znaků a řazení může násobit požadavky na úložiště. Pokud přidáte návrhy, požadavky na úložiště se ještě více zrychlí. Obrázek o dopadu atributů na úložiště najdete v tématu Atributy a velikost indexu.

Shrnutí, důsledky nadměrného přisuzování zahrnují:

Snížení výkonu indexování kvůli nadbytečné práci potřebné ke zpracování obsahu v poli a jeho následnému uložení do invertovaného indexu vyhledávání (nastavte atribut "prohledávatelný" pouze u polí, která obsahují prohledávatelný obsah).
Vytvoří větší plochu, kterou každý dotaz musí pokrýt. Všechna pole označená jako prohledávatelná se prohledávají v fulltextovém vyhledávání.
Zvyšuje provozní náklady kvůli dodatečnému úložišti. Filtrování a řazení vyžaduje další místo pro ukládání původních (neanalyzovaných) řetězců. Vyhněte se nastavení filtrování nebo řazení u polí, která je nepotřebují.
V mnoha případech omezuje přisouzení možnosti pole. Pokud je například pole tabulkovatelné, filtrovatelné a prohledávatelné, můžete do pole uložit pouze 16 kB textu, zatímco prohledávatelné pole může obsahovat až 16 MB textu.

Poznámka:

Měli byste se vyhnout pouze nepotřebným přisuzování. Filtry a omezující vlastnosti jsou často nezbytné pro vyhledávání a v případech, kdy se filtry používají, často potřebujete řazení, abyste mohli výsledky uspořádat (filtry se samy vrátí v neuspořádané sadě).

Tip: Zvažte alternativy ke složitým typům

Složité datové typy jsou užitečné v případě, že data mají složitou vnořenou strukturu, například elementy nadřazené-podřízené nalezené v dokumentech JSON. Nevýhodou složitých typů jsou dodatečné požadavky na úložiště a další prostředky potřebné k indexování obsahu v porovnání s nesložitým datovým typem.

V některých případech se můžete těmto kompromisům vyhnout tím, že namapujete složitou datovou strukturu na jednodušší typ pole, například kolekci. Alternativně můžete zvolit zplošťování hierarchie polí do jednotlivých polí kořenové úrovně.

Návrh dotazu

Složení a složitost dotazů jsou jedním z nejdůležitějších faktorů výkonu a optimalizace dotazů může výrazně zlepšit výkon. Při návrhu dotazů se zamyslete nad následujícími body:

Počet prohledávatelných polí Každé další prohledávatelné pole bude ve vyhledávací službě fungovat víc. Pole, která se prohledávají v době dotazu, můžete omezit pomocí parametru "searchFields". V zájmu zvýšení výkonu je nejlepší zadat pouze pole, která vás zajímají.
Množství vrácených dat Načítání velkého množství obsahu může zpomalit dotazy. Při strukturování dotazu nastavte vrácení pouze těch polí, která potřebujete k vykreslení stránky výsledků, a zbývající pole pak načtěte pomocí rozhraní API pro vyhledávání, jakmile uživatel vybere shodu.
Použití částečného hledání termínů Částečné hledání termínů, jako je vyhledávání předpon, přibližné vyhledávání a vyhledávání regulárních výrazů, jsou výpočetně dražší než typické vyhledávání klíčových slov, protože k vytvoření výsledků vyžadují úplné prohledávání indexu.
Počet omezujících vlastností Při přidání omezujících vlastností do dotazů se pro každý dotaz vyžaduje agregace. Vyžadování vyššího počtu omezujících vlastností také od služby vyžaduje další práci. Obecně platí, že byste měli přidávat pouze omezující vlastnosti, které chcete v aplikaci vykreslit, a pokud to není nutné, neměli byste žádat o velký počet omezujících vlastností.
Vysoké přeskočení hodnot. Nastavením parametru $skip na vysokou hodnotu (například v řádu tisíců) se zvýší latence vyhledávání, protože modul pro každý požadavek načítá a hodnotí větší množství dokumentů. Z důvodu zajištění lepšího výkonu je nejlepší nepoužívat vysoké hodnoty parametru $skip, a místo toho k načítání velkého množství dokumentů používat jiné techniky, jako je filtrování.
Omezte počet polí s vysokou kardinalitou. Pole s vysokou kardinalitou odkazuje na facetable nebo filtrovatelné pole, které má významný počet jedinečných hodnot, a v důsledku toho spotřebovává významné zdroje při výpočtu výsledků. Například nastavení pole ID produktu nebo popisu jako omezující a filtrovatelné by se spočítalo jako vysoká kardinalita, protože většina hodnot z dokumentu do dokumentu je jedinečná.

Tip: Použití vyhledávacích funkcí místo přetížení kritérií filtru

Vzhledem k tomu, že dotaz používá stále složitější kritéria filtru, výkon vyhledávacího dotazu se sníží. Podívejte se na následující příklad, který ukazuje použití filtrů k oříznutí výsledků na základě identity uživatele:

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

V tomto případě se výrazy filtru používají ke kontrole, jestli se jedno pole v každém dokumentu rovná jedné z mnoha možných hodnot identity uživatele. Tento model pravděpodobně najdete v aplikacích, které implementují oříznutí zabezpečení (kontrola pole obsahující jedno nebo více ID objektu zabezpečení na seznamu ID objektů zabezpečení představujících uživatele, který dotaz vydává).

Efektivnější způsob, jak spustit filtry obsahující velký počet hodnot, je použít search.in funkci, jak je znázorněno v tomto příkladu:

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

Tip: Přidání oddílů pro pomalé jednotlivé dotazy

Pokud se obecně zpomaluje výkon dotazů, často problém řeší přidávání dalších replik. Ale co když je problém jediný dotaz, který trvá příliš dlouho? V tomto scénáři vám přidání replik nepomůže, ale může se stát, že se jedná o další oddíly. Oddíl rozděluje data mezi další výpočetní prostředky. Dva oddíly rozdělují data na polovinu, třetí oddíl je rozdělí na třetí a tak dále.

Jedním z pozitivních vedlejších účinků přidávání oddílů je, že pomalejší dotazy někdy provádějí rychleji kvůli paralelnímu computingu. Poznamenali jsme paralelizaci dotazů s nízkou selektivitou, jako jsou dotazy, které odpovídají mnoha dokumentům, nebo omezující vlastnosti poskytující počty nad velkým počtem dokumentů. Vzhledem k tomu, že k určení skóre relevance dokumentů nebo ke spočítání počtu dokumentů se vyžaduje významné výpočty, přidání dalších oddílů pomáhá dotazy dokončit rychleji.

Pokud chcete přidat oddíly, použijte Azure Portal, PowerShell, Azure CLI nebo sadu SDK pro správu.

Kapacita služby

Služba se přetíží, když dotazy trvá příliš dlouho nebo když služba spouští žádosti. V takovém případě můžete problém vyřešit upgradem služby nebo přidáním kapacity.

Úroveň vyhledávací služby a počet replik/oddílů mají také velký dopad na výkon. Každá postupně vyšší úroveň poskytuje rychlejší procesory a více paměti, z nichž obě mají pozitivní dopad na výkon.

Tip: Vytvoření nové vyhledávací služby s vysokou kapacitou

Základní a standardní služby vytvořené v podporovaných oblastech po 3. dubnu 2024 mají více úložiště na oddíl než starší služby. Před upgradem na vyšší úroveň a vyšší fakturovatelnou sazbou se znovu podívejte na limity služby vrstvy, abyste zjistili, jestli stejná úroveň v novější službě poskytuje potřebné úložiště.

Tip: Upgrade na úroveň Standard S2

Vyhledávací úroveň Standard S1 je často tam, kde zákazníci začínají. Běžným vzorem pro služby S1 je, že se indexy v průběhu času zvětšují, což vyžaduje více oddílů. Další oddíly vedou k pomalejší době odezvy, takže se přidá více replik pro zpracování zatížení dotazu. Jak si můžete představit, náklady na provoz služby S1 se teď dostaly na úrovně nad rámec počáteční konfigurace.

V této bodě je důležitou otázkou, kterou je třeba položit, zda by bylo výhodné přejít na vyšší úroveň, a ne postupně zvýšit počet oddílů nebo replik aktuální služby.

Představte si následující topologii jako příklad služby, která se vzala na zvýšení úrovně kapacity:

Úroveň Standard S1
Velikost indexu: 190 GB
Počet oddílů: 8 (v S1, velikost oddílu je 25 GB na oddíl)
Počet replik: 2
Celkový počet jednotek vyhledávání: 16 (8 oddílů x 2 replik)
Hypotetická maloobchodní cena: ~4 000 USD / měsíc (předpokládejme 250 USD x 16 jednotek hledání)

Předpokládejme, že správce služby stále vidí vyšší latenci a zvažuje přidání další repliky. To by změnilo počet replik z 2 na 3 a v důsledku toho se počet jednotek vyhledávání změnil na 24 a výslednou cenu 6 000 USD za měsíc.

Pokud se ale správce rozhodl přejít na úroveň Standard S2, bude topologie vypadat takto:

Úroveň Standard S2
Velikost indexu: 190 GB
Počet oddílů: 2 (v S2, velikost oddílu je 100 GB na oddíl)
Počet replik: 2
Celkový počet jednotek vyhledávání: 4 (2 oddíly x 2 repliky)
Hypotetická maloobchodní cena: ~4 000 USD / měsíc (1 000 USD x 4 jednotky hledání)

Jak ukazuje tento hypotetický scénář, můžete mít konfigurace na nižších úrovních, které vedou k podobným nákladům, jako kdybyste se na prvním místě rozhodli pro vyšší úroveň. Vyšší úrovně jsou ale součástí premium storage, což zrychlová indexování. Vyšší úrovně mají také mnohem větší výpočetní výkon a také další paměť. U stejných nákladů můžete mít výkonnější infrastrukturu, která zálohuje stejný index.

Důležitou výhodou přidané paměti je, že větší část indexu se dá ukládat do mezipaměti, což vede k nižší latenci vyhledávání a většímu počtu dotazů za sekundu. S tímto dodatečným výkonem nemusí správce ani potřebovat zvýšit počet replik a může potenciálně platit méně než tím, že zůstane ve službě S1.

Tip: Zvažte alternativy k dotazům regulárních výrazů.

Dotazy regulárních výrazů nebo regulární výrazy můžou být zvláště nákladné. I když můžou být velmi užitečné pro pokročilá hledání, provádění může vyžadovat velké množství výpočetního výkonu, zejména pokud je regulární výraz komplikovaný nebo když hledáte velké množství dat. Všechny tyto faktory přispívají k vysoké latenci vyhledávání. Jako zmírnění rizik zkuste zjednodušit regulární výraz nebo rozdělit složitý dotaz na menší a lépe spravovatelné dotazy.

Další kroky

Projděte si tyto další články týkající se výkonu služby:

Sdílet prostřednictvím