Odhad a správa kapacity vyhledávací služby

Než vytvoříte vyhledávací službu a uzamknete ji v konkrétní cenové úrovni, pochopíte si, jak kapacita funguje a jak se můžou upravovat repliky a oddíly, aby odpovídaly výkyvům úloh.

V Azure Kognitivní hledání kapacita je založena na replikách a oddílech. Repliky jsou kopie vyhledávacího modulu. Oddíly jsou jednotky úložiště. Každá nová vyhledávací služba začíná jednou, ale každý prostředek můžete škálovat nezávisle na tom, aby vyhovoval výkyvům úloh. Přidání prostředku je Fakturovatelné.

Fyzické vlastnosti replik a oddílů, jako je například rychlost zpracování a vstupně-výstupní operace disku, se liší podle úrovně služeb. Pokud jste zřídili Standard, repliky a oddíly budou rychlejší a větší než na úrovni Basic.

Změna kapacity není okamžitá. Může trvat až hodinu na oddíly provize nebo vyřazení z provozu, zejména na služby s velkým objemem dat.

Při škálování vyhledávací služby si můžete vybrat z následujících nástrojů a přístupů:

• Azure Portal
• Azure PowerShell
• Azure CLI
• Rozhraní REST API pro správu

Koncepty: jednotky hledání, repliky, oddíly, horizontálních oddílů

Kapacita se vyjadřuje v jednotkách vyhledávání , které se dají přidělit v kombinaci oddílů a replik, a to pomocí základního mechanismu horizontálního dělení pro podporu flexibilních konfigurací:

Následující diagram znázorňuje vztah mezi replikami, oddíly, horizontálních oddílů a jednotkami pro hledání. Ukazuje příklad toho, jak je jeden index rozložen mezi čtyři jednotky vyhledávání ve službě se dvěma replikami a dvěma oddíly. Každá ze čtyř jednotek hledání uchovává pouze polovinu horizontálních oddílůy indexu. Jednotky vyhledávání v levém sloupci ukládají první polovinu horizontálních oddílů, včetně prvního oddílu, zatímco ta v pravém sloupci ukládají druhou polovinu horizontálních oddílů, která zahrnuje druhý oddíl. Vzhledem k tomu, že existují dvě repliky, existují dvě kopie každého indexu horizontálních oddílů. Jednotky vyhledávání v horním řádku ukládají jednu kopii, která se skládá z první repliky, zatímco ta v dolním řádku ukládá další kopii, která se skládá z druhé repliky.

Výše uvedený diagram je pouze jeden příklad. Je možné mnoha kombinací oddílů a replik, maximálně až 36 jednotek hledání (celkem až).

V Kognitivní hledání je Správa horizontálních oddílůa detailem implementace a nedá se konfigurovat, ale s vědomím, že index je horizontálně dělené, pomáhá pochopit občasné anomálie v pořadí a chování při automatickém dokončování:

• Řazení anomálií: skóre hledání se nejprve vypočítávají na úrovni horizontálních oddílů a pak se agreguje do jedné sady výsledků. V závislosti na charakteristikách horizontálních oddílů obsahu může být shoda z jedné horizontálních oddílů seřazená na vyšší hodnotu než shoda v jiném typu. Pokud si všimnete, že se ve výsledcích hledání zobrazí intuitivní hodnocení, je nejpravděpodobnější vzhledem k efektům horizontálního dělení, zejména pokud jsou indexy malé. Těmto anomáliím se můžete vyhnout tak, že vyberete možnost vypočítat skóre globálně napříč celým indexem, ale dojde k snížení výkonu.

• Gramatiky automatického dokončování: Automatické dokončování dotazů, kde se shody provádějí na prvních několika znakech částečně zadaného výrazu, přijměte přibližný parametr, který forgives malé odchylky v pravopisu. Pro automatické dokončování je přibližné porovnání omezené na výrazy v rámci aktuální horizontálních oddílů. Například pokud horizontálních oddílů obsahuje "Microsoft" a částečný výraz "micor", vyhledávací web bude v tomto horizontálních oddílů odpovídat "Microsoft", ale ne v jiném horizontálních oddílů, které obsahují zbývající části indexu.

Blíží se odhad

Kapacita a náklady na provoz služby se dostanou rukou. Vrstvy ukládají omezení na dvou úrovních: obsah (například počet indexů ve službě) a úložiště. Je důležité vzít v úvahu, protože podle toho, co se vám limit dosahuje, je platný limit.

Počty indexů a dalších objektů jsou obvykle vypočítány provozními a technickými požadavky. Například můžete mít více verzí stejného indexu pro aktivní vývoj, testování a produkci.

Storage potřeby jsou určeny podle velikosti indexů, které očekáváte sestavit. Neexistují žádné tuhé heuristické a obecné informace, které vám pomůžou s odhady. Jediným způsobem, jak určit velikost indexu, je sestavení jednoho. Jeho velikost bude založena na importovaných datech, analýze textu a konfiguraci indexu, například na tom, jestli povolíte moduly pro návrhy, filtrování a řazení.

Pro fulltextové vyhledávání je primární strukturou dat obrácená struktura indexu , která má jiné charakteristiky než zdrojová data. U převráceného indexu se velikost a složitost určují podle obsahu, nikoli nutně podle množství dat, která do něj zadáte. Velký zdroj dat s vysokou redundancí může mít za následek menší index než menší datová sada, která obsahuje vysoce proměnlivý obsah. Je proto možné pouze odvodit velikost indexu na základě velikosti původní datové sady.

Atributy indexu, jako je povolení filtrů a řazení, budou mít vliv na požadavky na úložiště. Použití modulu pro návrhy má také dopady na úložiště. Další informace najdete v tématu atributy a velikost indexu.

Odhad s úrovní Free

Jedním z přístupů k odhadu kapacity je začít s úrovní Free. Mějte na paměti, že bezplatná služba nabízí až tři indexy, 50 MB úložiště a 2 minuty času indexování. Může být náročné odhadnout velikost předpokládaného indexu s těmito omezeními, ale postup je následující:

• Vytvořte bezplatnou službu.

• Připravte malou, reprezentativní datovou sadu.

• Vytvořte index a načtěte data. Pokud je možné datovou sadu hostovat ve zdroji dat Azure podporovaném indexery, můžete k vytvoření a načtení indexu použít Průvodce importem dat na portálu . v opačném případě byste k vytvoření indexu a vložení dat měli použít REST a post nebo Visual Studio Code . Model nabízených oznámení vyžaduje, aby data byla ve formátu dokumentů JSON, kde pole v dokumentu odpovídají polím v indexu.

• Shromažďování informací o indexu, například velikost Funkce a atributy mají dopad na úložiště. Například přidání návrhů (dotazy hledání podle typu) zvýší požadavky na úložiště.

  Pomocí stejné datové sady můžete zkusit vytvořit několik verzí indexu s různými atributy každého pole, abyste viděli, jak se požadavky na úložiště liší. další informace najdete v části "Storage dopady" v tématu vytvoření základního indexu.

V případě hrubého odhadu se může tato částka zdvojnásobit do rozpočtu pro dva indexy (vývoj a produkce) a odpovídajícím způsobem zvolit svou úroveň.

Odhad s fakturovatelnou úrovní

Vyhrazené prostředky můžou sloužit k většímu počtu vzorkování a zpracování za účelem realističtějších odhadů množství indexu, velikosti a svazků dotazů během vývoje. Někteří zákazníci najdou přímo v rámci Fakturovatelné úrovně a pak se znovu vyhodnotí jako vývoj projektu vývoje.

1. Zkontrolujte omezení služeb na jednotlivých úrovních , abyste zjistili, jestli nižší úrovně můžou podporovat potřebný počet indexů. V úrovních Basic, S1 a S2 jsou limity indexu 15, 50 a 200, v uvedeném pořadí. Storage optimalizovaná úroveň má limit 10 indexů, protože je navržena tak, aby podporovala nízký počet velmi rozsáhlých indexů.

2. Vytvoření služby v Fakturovatelné úrovni:

   • Pokud si nejste jisti plánovaným zatížením, začněte na stránce Basic nebo S1 nízká.
   • Začíná vysoká, v S2 nebo dokonce S3, pokud testování zahrnuje rozsáhlé indexování a načítání dotazů.
   • pokud indexuje velké množství dat a zatížení dotazů je poměrně nízké, stejně jako u interní obchodní aplikace, začněte s Storage optimalizovanou v L1 nebo L2.

3. Vytvořte počáteční index, abyste zjistili, jak se zdrojová data překládají na index. Toto je jediný způsob, jak odhadnout velikost indexu.

4. Monitorujte úložiště, limity služeb, objem dotazů a latenci na portálu. Portál zobrazuje dotazy za sekundu, omezování dotazů a latenci vyhledávání. Všechny tyto hodnoty vám můžou pomoct při rozhodování, jestli jste vybrali správnou úroveň.

5. Pokud potřebujete vysokou dostupnost nebo pokud dochází k pomalému výkonu dotazů, přidejte repliky.

   Neexistují žádné pokyny týkající se toho, kolik replik je potřeba k přizpůsobení načítání dotazů. Výkon dotazů závisí na složitosti dotazu a konkurenčních úlohách. Přestože přidání replik jasně vede k lepšímu výkonu, není výsledek striktně lineární: přidáním tří replik nezaručíte trojitou propustnost. Pokyny k odhadování QPS pro vaše řešení najdete v tématu Škálování pro výkona Monitorování dotazů.

Důležité informace o objemu dotazů

Dotazy za sekundu (QPS) jsou důležitou metrikou během ladění výkonu, ale obecně je to aspekt úrovně, pokud od začátku očekáváte vysoký objem dotazů.

Úrovně Standard mohou poskytovat rovnováhu mezi replikami a oddíly. Zvýšení počtu dotazů můžete zvýšit přidáním replik pro vyrovnávání zatížení nebo přidáním oddílů pro paralelní zpracování. Po zřízení služby pak můžete ladit výkon.

Pokud od počátku očekáváte vysoce udržované svazky dotazů, měli byste zvážit vyšší úrovně Standard s výkonnějším hardwarem. Pak můžete oddíly a repliky přepněte do režimu offline nebo dokonce přepnout na službu nižší úrovně, pokud k těmto svazkům dotazů nedojde. Další informace o tom, jak vypočítat propustnost dotazů, najdete v Azure Cognitive Search výkonu a optimalizaci.

Úrovně Storage jsou užitečné pro úlohy s velkými objemy dat a podporují celkově dostupné úložiště indexů, pokud jsou požadavky na latenci dotazů méně důležité. Stále byste měli používat další repliky pro vyrovnávání zatížení a další oddíly pro paralelní zpracování. Po zřízení služby pak můžete ladit výkon.

Smlouvy o úrovni služeb

Na funkce úrovně Free a Preview se nevztahují smlouvy o úrovni služeb (SLA). U všech fakturovatelných úrovní se smlouvy SLA projeví, když pro vaši službu zř vyjádřete dostatečnou redundanci. Pro dotazování (čtení) smluv SLA musíte mít dvě nebo více replik. Pro smlouvy SLA pro dotazy a indexování (čtení i zápis) musíte mít tři nebo více replik. Počet oddílů nemá vliv na smlouvy SLA.

Tipy pro plánování kapacity

• Povolí metrikám vytvářet dotazy a shromažďovat data týkající se vzorců využití (dotazy během pracovní doby, indexování mimo špičku). Tato data můžete použít k informování o rozhodnutích o zřizování služeb. I když to není praktické každou hodinu nebo každý den, můžete dynamicky upravovat oddíly a prostředky tak, aby vyhovovaly plánovaným změnám ve svazcích dotazů. Můžete také pojmout neplánované, ale trvalé změny, pokud jsou úrovně dostatečně dlouhé, aby bylo možné provést akci.

• Mějte na paměti, že jedinou nevýhodou v rámci zřizování je, že pokud jsou skutečné požadavky větší než vaše předpovědi, možná budete muset službu z provozu vytrhnout. Pokud se chcete vyhnout přerušení služeb, vytvořte novou službu na vyšší úrovni a spusťte ji vedle sebe, dokud se všechny aplikace a požadavky nezaměří na nový koncový bod.

Kdy přidat kapacitu

Na začátku je službě přidělena minimální úroveň prostředků sestávajících z jednoho oddílu a jedné repliky. Úroveň, kterou zvolíte, určuje velikost a rychlost oddílů a každá úroveň je optimalizovaná na základě sady charakteristik, které jsou vhodné pro různé scénáře. Pokud zvolíte vyšší úroveň, budete možná potřebovat méně oddílů než u S1. Jednou z otázek, na kterou budete muset odpovědět prostřednictvím samosměrových testů, je to, jestli větší a dražší oddíl poskytuje lepší výkon než dva levnější oddíly ve službě zřízené na nižší úrovni.

Jedna služba musí mít dostatek prostředků pro zpracování všech úloh (indexování a dotazy). Žádná úloha nes běží na pozadí. Indexování můžete naplánovat na dobu, kdy jsou požadavky na dotazy přirozeně méně časté, ale služba jinak nebude upřednostňovat jeden úkol před jiným. Kromě toho určitá úroveň redundance vyhlazení výkonu dotazů při interní aktualizaci služeb nebo uzlů.

Mezi pokyny pro určení, jestli se má přidat kapacita, patří:

• Splnění kritérií vysoké dostupnosti pro smlouvu o úrovni služeb
• Frekvence chyb HTTP 503 se zvyšuje
• Očekávají se velké svazky dotazů.

Obecně platí, že vyhledávací aplikace obvykle potřebují více replik než oddíly, zejména pokud jsou operace služby zkreslené vůči úlohám dotazů. Každá replika je kopií vašeho indexu, což službě umožňuje vyvážit požadavky na více kopií. Veškeré vyrovnávání zatížení a replikace indexu spravuje Azure Cognitive Search a počet replik přidělených pro vaši službu můžete kdykoli změnit. Ve službě Vyhledávání na úrovni Standard můžete přidělit až 12 replik a 3 repliky v základní vyhledávací službě. Přidělení repliky se může přidělovat buď Azure Portal nebo jedné z programových možností.

Vyhledávací aplikace, které vyžadují aktualizaci dat v reálném čase, budou potřebovat proporcionálně více oddílů než replik. Přidání oddílů rozprostírá operace čtení a zápisu mezi větší počet výpočetních prostředků. Poskytuje také více místa na disku pro ukládání dalších indexů a dokumentů.

Nakonec dotazování větších indexů trvá déle. Proto můžete zjistit, že každé přírůstkové zvýšení oddílů vyžaduje menší, ale proporcionální zvýšení počtu replik. Složitost dotazů a objemu dotazů bude mít za to, jak rychle se provádění dotazů obměnalo.

Přidání nebo snížení počtu replik a oddílů

1. Přihlaste se k Azure Portal a vyberte vyhledávací službu.

2. V Nastavení otevřete stránku Škálování a upravte repliky a oddíly.

   Následující snímek obrazovky ukazuje základní standard zřízený s jednou replikou a oddílem. Vzorec v dolní části určuje, kolik jednotek hledání se používá (1). Pokud by jednotková cena byla 100 USD (nikoli skutečná cena), měsíční náklady na provoz této služby by byly v průměru 100 USD.

   

3. Pomocí posuvníku zvyšte nebo snižte počet oddílů. Vyberte Uložit.

   Tento příklad přidá druhou repliku a oddíl. Všimněte si počtu jednotek hledání. Teď je to čtyři, protože fakturační vzorec se repliky vynásobí oddíly (2 x 2). Zdvojnásobení kapacity více než dvojnásobné náklady na provoz služby. Pokud by náklady na jednotku hledání byly 100 USD, nová měsíční faktura by teď byla 400 USD.

   Aktuální náklady na jednotku jednotlivých úrovní najdete na stránce s cenami.

   

4. Po uložení můžete zkontrolovat oznámení a potvrdit, že byla akce úspěšná.

   

   Dokončení změn kapacity může trvat 15 minut až několik hodin. Po spuštění procesu není možné operaci zrušit a v reálném čase není možné monitorovat úpravy replik a oddílů. Během rozbíhajících se změn ale zůstává viditelná následující zpráva.

   

Jak se zpracovávají požadavky na škálování

Po přijetí žádosti o škálování vyhledávací služba:

1. Zkontroluje, jestli je požadavek platný.
2. Spustí zálohování dat a systémových informací.
3. Kontroluje, jestli už je služba ve stavu zřizování (aktuálně přidává nebo odstraňuje repliky nebo oddíly).
4. Spustí zřizování.

Škálování služby může trvat až 15 minut nebo i hodinu v závislosti na velikosti služby a rozsahu požadavku. Zálohování může trvat několik minut v závislosti na množství dat a počtu oddílů a replik.

Výše uvedené kroky nejsou zcela po sobě. Systém například spustí zřizování, když ho může bezpečně učinit, což by mohlo být při ukončování zálohování.

Chyby při škálování

Chybová zpráva: operace aktualizace služby nejsou v tuto chvíli povolené, protože zpracováváme předchozí požadavek. je to způsobeno opakováním žádosti o horizontální navýšení nebo snížení kapacity, když služba už zpracovává předchozí požadavek.

Tuto chybu vyřešíte tak, že zkontrolujete stav služby a ověříte stav zřizování:

1. pro získání stavu služby použijte REST API pro správu, Azure PowerShellnebo Azure CLI .
2. Volat službu Get
3. Ověřte odpověď pro "provisioningState": "zřizování"

Pokud se jedná o stav zřizování, počkejte na dokončení žádosti. Před pokusem o provedení jiné žádosti by měl být stav buď "úspěch" nebo "neúspěšný". Není k dispozici žádný stav zálohování. Zálohování je interní operace a není pravděpodobné, že by to bylo v případě výpadku škálování náročné na výkon.

Kombinace oddílů a repliky

Základní služba může mít přesně jeden oddíl a až tři repliky, a to maximálním limitem tři služby SUs. Jediným upravitelným prostředkem jsou repliky. Pro zajištění vysoké dostupnosti dotazů potřebujete minimálně dvě repliky.

všechny standardní a Storage optimalizované vyhledávací služby mohou předpokládat následující kombinace replik a oddílů v závislosti na limitu 36-SU povoleného pro tyto úrovně.

Služba SUs, ceny a kapacita jsou podrobně vysvětleny na webu Azure. Další informace najdete v podrobnostech o cenách.

Další kroky