Indexování velkých datových sad ve službě Azure AI Search

  • Článek

Pokud požadavky na řešení vyhledávání zahrnují indexování velkých objemů dat nebo složitá data, tento článek popisuje strategie pro přizpůsobení dlouhotrvajících procesů ve službě Azure AI Search.

Tento článek předpokládá znalost dvou základních přístupů k importu dat: nahrání dat do indexu nebo načtení dat z podporovaného zdroje dat pomocí indexeru vyhledávání. Pokud váš scénář zahrnuje výpočetně náročné rozšiřování AI, vyžadují se indexery vzhledem k závislostem sady dovedností na indexerech.

Tento článek doplňuje Tipy pro lepší výkon, který nabízí osvědčené postupy pro návrh indexů a dotazů. Dobře navržený index, který obsahuje jenom pole a atributy, které potřebujete, je důležitým předpokladem pro rozsáhlé indexování.

Pro vyšší úložiště na oddíl doporučujeme použít novější vyhledávací službu vytvořenou po 3. dubnu 2024.

Poznámka:

Strategie popsané v tomto článku předpokládají jeden velký zdroj dat. Pokud vaše řešení vyžaduje indexování z více zdrojů dat, vyhledejte doporučený postup v tématu Indexování více zdrojů dat ve službě Azure AI Search .

Indexování velkých dat pomocí nabízených rozhraní API

Rozhraní API "Push", jako jsou rozhraní REST API indexu dokumentů nebo metoda IndexDocuments (Azure SDK pro .NET), představují nejběžnější formu indexování ve službě Azure AI Search. U řešení, která používají rozhraní API nabízených oznámení, bude mít strategie dlouhodobého indexování jednu nebo obě následující komponenty:

  • Dávkové dokumenty
  • Správa vláken

Batch multiple documents per request

Jednoduchým mechanismem indexování velkého množství dat je odeslání více dokumentů nebo záznamů v jediné žádosti. Pokud je celá datová část pod 16 MB, může požadavek zpracovat až 1 000 dokumentů v operaci hromadného nahrávání. Tato omezení platí bez ohledu na to, jestli používáte rozhraní REST API indexu dokumentů nebo metodu IndexDocuments v sadě .NET SDK. Pro každé rozhraní API byste v textu každého požadavku zabalí 1000 dokumentů.

Dávkové dokumenty výrazně zkracují dobu potřebnou k práci s velkým objemem dat. Určení optimální velikosti dávky pro vaše data je klíčovou součástí optimalizace rychlosti indexování. Optimální velikost dávky ovlivňují dva primární faktory:

  • Schéma indexu
  • Velikost dat

Vzhledem k tomu, že optimální velikost dávky závisí na indexu a vašich datech, nejlepším přístupem je otestovat různé velikosti dávek a určit, která z nich má za následek nejrychlejší rychlost indexování pro váš scénář. Kurz: Optimalizace indexování pomocí rozhraní PUSH API poskytuje vzorový kód pro testování velikostí dávek pomocí sady .NET SDK.

Přidání vláken a strategie opakování

Indexery mají integrovanou správu vláken, ale když používáte rozhraní API nabízených oznámení, bude kód aplikace muset spravovat vlákna. Ujistěte se, že máte dostatek vláken, aby se plně využila dostupná kapacita, zejména pokud jste nedávno zvýšili oddíly nebo jste upgradovali na vyhledávací službu vyšší vrstvy.

  1. Zvyšte počet souběžných vláken v kódu klienta.

  2. Při zprovoznění požadavků do vyhledávací služby můžete narazit na stavové kódy HTTP, které značí, že požadavek nebyl plně úspěšný. Během indexování jsou dva běžné stavové kódy HTTP:

    • 503 Služba není k dispozici – Tato chyba znamená, že systém je zatížený velkým zatížením a v tuto chvíli nelze vaši žádost zpracovat.

    • 207 Multi-Status – Tato chyba znamená, že některé dokumenty byly úspěšné, ale alespoň jeden selhal.

  3. Aby bylo možné zpracovávat chyby, měly by se žádosti opakovat pomocí strategie exponenciálního opakování opakování.

Sada Azure .NET SDK automaticky opakuje 503 a další neúspěšné požadavky, ale pro opakování 207 budete muset implementovat vlastní logiku. K implementaci strategie opakování je možné použít také opensourcové nástroje, jako je Polly .

Indexování pomocí indexerů a rozhraní API pro vyžádání změn

Indexery mají několik funkcí, které jsou užitečné pro dlouhotrvající procesy:

  • Dávkové dokumenty
  • Paralelní indexování nad dělenými daty
  • Plánování a detekce změn pro indexování pouze nových a změn dokumentů v průběhu času

Plány indexeru mohou pokračovat ve zpracování v posledním známém zastavovacím bodu. Pokud data nejsou v okně zpracování plně indexovaná, indexer převezme při dalším spuštění všude, kde skončil, za předpokladu, že používáte zdroj dat, který poskytuje detekci změn.

Rozdělení dat do menších jednotlivých zdrojů dat umožňuje paralelní zpracování. Ve službě Azure Blob Storage můžete rozdělit zdrojová data, například do několika kontejnerů, vytvořit zdroj dat pro každý oddíl a pak spustit indexery paralelně, a to v závislosti na počtu jednotek vyhledávání ve vyhledávací službě.

Kontrola velikosti dávky indexeru

Stejně jako u rozhraní API nabízených oznámení umožňují indexery nakonfigurovat počet položek na dávku. U indexerů založených na rozhraní REST API pro vytvoření indexeru můžete argument nastavit batchSize tak, aby lépe odpovídal charakteristikám vašich dat.

Výchozí velikosti dávek jsou specifické pro zdroj dat. Azure SQL Database a Azure Cosmos DB mají výchozí velikost dávky 1000. Indexování objektů blob v Azure naopak nastavuje velikost dávky na 10 dokumentů při rozpoznávání větší průměrné velikosti dokumentu.

Plánování indexerů pro dlouhotrvající procesy

Plánování indexeru je důležitým mechanismem pro zpracování velkých datových sad a pro umožnění pomalých procesů, jako je analýza obrázků v kanálu rozšiřování.

Zpracování indexeru se obvykle spouští během 2hodinového intervalu. Pokud úloha indexování trvá několik dní, než hodiny, můžete indexer umístit do po sobě jdoucího plánu opakování, který se spustí každé dvě hodiny. Za předpokladu, že je u zdroje dat povolené sledování změn, indexer obnoví zpracování tam, kde naposledy skončil. V tomto tempu může indexer procházet backlog dokumentů po celou řadu dnů, dokud nebudou zpracovány všechny nezpracované dokumenty.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Pokud už ve zdroji dat nejsou žádné nové nebo aktualizované dokumenty, historie provádění indexeru bude hlásit 0/0 dokumenty zpracovávané a nedojde k žádnému zpracování.

Další informace o nastavení plánů najdete v tématu Vytvoření rozhraní REST API indexeru nebo informace o plánování indexerů pro Azure AI Search.

Poznámka:

Některé indexery, které běží ve starší architektuře modulu runtime, mají místo 2hodinového intervalu maximálního zpracování 24 hodin. 2hodinový limit platí pro novější procesory obsahu, které běží v interně spravovaném prostředí s více tenanty. Kdykoli je to možné, Azure AI Search se pokusí indexer a zpracování sady dovedností přesměrovat do prostředí s více tenanty. Pokud indexer nejde migrovat, spustí se v privátním prostředí a může běžet po dobu 24 hodin. Pokud plánujete indexer, který tyto vlastnosti vykazuje, předpokládejme 24hodinový interval zpracování.

Paralelní spouštění indexerů

Pokud data rozdělíte do oddílů, můžete vytvořit několik kombinací indexeru zdroje dat, které načítá z každého zdroje dat a zapisují se do stejného indexu vyhledávání. Vzhledem k tomu, že každý indexer je odlišný, můžete je spustit současně a naplnit index vyhledávání rychleji, než kdybyste je spustili postupně.

Ujistěte se, že máte dostatečnou kapacitu. Jedna jednotka vyhledávání ve vaší službě může kdykoli spustit jeden indexer. Vytváření více indexerů je užitečné jenom v případě, že se můžou spouštět paralelně.

Počet úloh indexování, které se dají spustit současně, se liší pro indexování založené na textu a na základě dovedností. Další informace naleznete v tématu Spuštění indexeru.

Pokud je zdrojem dat kontejner Azure Blob Storage nebo Azure Data Lake Storage Gen2, může vytvoření výčtu velkého počtu objektů blob trvat dlouhou dobu (i hodiny), než se tato operace dokončí. To způsobí, že počet úspěšných dokumentů indexeru se během této doby nezvýší a může se zdát, že neprobíhá žádný pokrok, pokud ano. Pokud chcete zrychlit zpracování dokumentů pro velký počet objektů blob, zvažte rozdělení dat do více kontejnerů a vytvoření paralelních indexerů odkazujících na jeden index.

  1. Přihlaste se k webu Azure Portal a zkontrolujte počet jednotek vyhledávání, které používá vaše vyhledávací služba. Výběrem možnosti Nastavení> Škálování zobrazíte číslo v horní části stránky. Počet indexerů, které se budou spouštět paralelně, se přibližně rovná počtu jednotek hledání.

  2. Rozdělte zdrojová data mezi více kontejnerů nebo více virtuálních složek uvnitř stejného kontejneru.

  3. Vytvořte několik zdrojů dat, jeden pro každý oddíl spárovaný s vlastním indexerem.

  4. V každém indexeru zadejte stejný cílový index vyhledávání.

  5. Naplánujte indexery.

  6. Zkontrolujte stav indexeru a historii spuštění a zkontrolujte potvrzení.

K paralelnímu indexování jsou spojená určitá rizika. Nejprve si vzpomeňte, že indexování se nespustí na pozadí, což zvyšuje pravděpodobnost, že se dotazy omezí nebo zahodí.

Za druhé, Azure AI Search nezamkne index aktualizací. Souběžné zápisy se spravují a vyvolávají opakování, pokud se při prvním pokusu nepodaří provést konkrétní zápis, ale můžete si všimnout zvýšení počtu selhání indexování.

Přestože více sad zdrojů dat indexeru může cílit na stejný index, buďte opatrní při spuštění indexeru, která můžou přepsat existující hodnoty v indexu. Pokud druhý indexer-zdroj dat cílí na stejné dokumenty a pole, všechny hodnoty z prvního spuštění budou přepsány. Hodnoty polí jsou nahrazeny v plném rozsahu; indexer nemůže sloučit hodnoty z více běhů do stejného pole.

Indexování velkých objemů dat ve Sparku

Pokud máte architekturu velkých objemů dat a vaše data jsou v clusteru Spark, doporučujeme SynapseML pro načítání a indexování dat. Tento kurz obsahuje kroky pro volání služeb Azure AI pro rozšiřování AI, ale k indexování textu můžete použít také rozhraní API AzureSearchWriter.

Viz také