Sdílet prostřednictvím

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

  • Článek

Pokud potřebujete indexovat velké nebo složité datové sady ve vyhledávacím řešení, tento článek popisuje strategie pro zpracování dlouhotrvajících procesů ve službě Azure AI Search.

Tyto strategie předpokládají 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í dat pomocí nabízených rozhraní API

Rozhraní API nabízených oznámení , jako je rozhraní REST API indexu dokumentů nebo metoda IndexDocuments (Azure SDK pro .NET), jsou nejrozšířenější formou indexování ve službě Azure AI Search. Pro řešení, která používají rozhraní API nabízených oznámení, má 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 rámci operace 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. Pomocí některého rozhraní API můžete v textu každého požadavku zabalit 1 000 dokumentů.

Dávkování dokumentů výrazně zkracuje 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ář. Ukázkový kód pro testování velikostí dávek pomocí sady .NET SDK najdete v tématu Kurz: Optimalizace indexování pomocí rozhraní PUSH API.

Správa 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í, kód aplikace musí spravovat vlákna. Ujistěte se, že máte dostatek vláken k plnému využití dostupné kapacity, zejména pokud jste nedávno zvýšili oddíly nebo 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 je potřeba implementovat vlastní logiku. K implementaci strategie opakování je možné použít také opensourcové nástroje, jako je Polly .

Použití 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ěné dokumenty 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 1 000. 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 dvouhodinové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 spouštění indexeru hlásí 0/0 zpracovávané dokumenty a nedojde k žádnému zpracování.

Další informace o nastavení plánů najdete v tématu Vytvoření rozhraní REST API indexeru nebo v tématu 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. Dvouhodinový limit platí pro novější procesory obsahu, které běží v interně spravovaném víceklientských prostředích. 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, běží 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čí. Výsledkem je, ž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 Měřítko nastavení>zobrazíte číslo v horní části stránky. Počet indexerů, které běží 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 omezování nebo vyřazení dotazů.

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í se přepíšou. 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.

Související obsah