Nagyméretű adathalmazok indexelése az Azure AI Keresésben

Megjegyzés

Azure AI Keresés a Azure portálon, REST API-kon és Azure SDK-k keresztül érhető el. Emellett a Foundry IQ-t is támogatja, amely a vállalati tartalmakat újrafelhasználható, engedélytudatos tudásbázisokká alakítja át az Microsoft Foundry portálon található ügynökök számára.

Ha nagy vagy összetett adathalmazokat kell indexelnie a keresési megoldásban, ez a cikk az Azure AI Keresés hosszú ideig futó folyamatainak megoldására vonatkozó stratégiákat ismerteti.

Ezek a stratégiák feltételezik, hogy ismerik az adatok importálásának két alapvető módszerét: az adatok indexbe való beküldését , vagy egy támogatott adatforrásból való adatbeolvasást egy keresési indexelő használatával. Ha a forgatókönyv számításigényes AI-bővítést igényel, akkor indexelőkre van szükség, tekintettel az indexelőkre vonatkozó képességkészlet-függőségre.

Ez a cikk kiegészíti a tippeket a jobb teljesítmény érdekében, amely ajánlott eljárásokat kínál az index- és lekérdezéstervezéshez. A nagy léptékű indexelés fontos előfeltétele egy jól megtervezett index, amely csak a szükséges mezőket és attribútumokat tartalmazza.

Használjon egy 2024. április 3. után létrehozott keresési szolgáltatást a partíciónkénti nagyobb tárterülethez. A régebbi szolgáltatásokat is frissítheti, hogy kihasználhassa a magasabb partíciós tárterület előnyeit.

Megjegyzés

A cikkben ismertetett stratégiák egyetlen nagy adatforrást feltételeznek. Ha a megoldás több adatforrásból való indexelést igényel, ajánlott megközelítésért tekintse meg a több adatforrás indexelését az Azure AI Keresésben .

Adatok indexelése leküldéses API-k használatával

Push API-k, mint például a Documents Index REST API vagy az IndexDocuments metódus (.NET Azure SDK), az Azure AI Keresés-ben az indexelés legelterjedtebb formáját képezik. A leküldéses API-t használó megoldások esetében a hosszú ideig futó indexelés stratégiája az alábbi összetevők egyikével vagy mindkettővel rendelkezik:

  • Dokumentumok kötegelése
  • Szálak kezelése

Több dokumentum kötegelt feldolgozása kérésenként

A nagy mennyiségű adat indexelésének egyszerű mechanizmusa több dokumentum vagy rekord egyetlen kérelemben való elküldése. Ha a teljes hasznos adat 16 MB alatt van, a kérelmek legfeljebb 1000 dokumentumot kezelhetnek tömeges feltöltési művelettel. Ezek a korlátozások érvényesek arra, hogy a Documents Index REST API-t vagy az IndexDocuments metódust használja-e a .NET SDK-ban. Bármelyik API használatával 1000 dokumentumot csomagolhat be az egyes kérések törzsébe.

A dokumentumok kötegelése jelentősen lerövidíti a nagy adatmennyiségen keresztüli munkához szükséges időt. Az indexelési sebesség optimalizálásának kulcsfontosságú összetevője az adatok optimális kötegméretének meghatározása. Az optimális kötegméretet befolyásolni képes két elsődleges tényező:

  • Az index sémája
  • Az adatok mérete

Mivel az optimális kötegméret az indextől és az adatoktól függ, a legjobb módszer a különböző kötegméretek tesztelése annak meghatározására, hogy melyik a leggyorsabb indexelési sebességet eredményezi a forgatókönyvhöz. A .NET SDK használatával a kötegméretek tesztelésére szolgáló mintakódért tekintse meg az oktatóanyagot: Indexelés optimalizálása a leküldéses API-val.

Szálak menedzselése és újrapróbálkozási stratégia

Az indexelők beépített szálkezeléssel rendelkeznek, de a leküldéses API-k használatakor az alkalmazás kódjának kezelnie kell a szálakat. Győződjön meg arról, hogy elegendő szál áll rendelkezésre a rendelkezésre álló kapacitás teljes kihasználásához, különösen akkor, ha nemrég frissítette a szolgáltatást, magasabb tarifacsomagra vagy nagyobb partíciókra váltott.

  1. Növelje az egyidejű szálak számát az ügyfélkódban.

  2. A keresési szolgáltatásra irányuló kérések felfuttatása során HTTP-állapotkódok jelenhetnek meg, amelyek azt jelzik, hogy a kérés nem sikerült teljes mértékben. Az indexelés során két gyakori HTTP-állapotkód:

    • 503 Szolgáltatás nem érhető el: Ez a hiba azt jelenti, hogy a rendszer nagy terhelés alatt áll, és a kérés jelenleg nem dolgozható fel.

    • 207 Többállapotú: Ez a hiba azt jelenti, hogy egyes dokumentumok sikeresek voltak, de legalább egy sikertelen volt.

  3. A hibák kezeléséhez a kéréseket exponenciális visszalépési újrapróbálkozási stratégiával kell újrapróbálkoznia.

Az Azure .NET SDK automatikusan újrapróbálkozza az 503-at és más sikertelen kéréseket, de saját logikát kell implementálnia a 207-ek újrapróbálkozásához. A nyílt forráskódú eszközök, például a Polly is használhatók újrapróbálkozési stratégia implementálásához.

Indexelők és lekéréses API-k használata

Az indexelők számos olyan képességet kínálnak, amelyek hasznosak a hosszú ideig futó folyamatokhoz:

  • Dokumentumok kötegelése
  • Párhuzamos indexelés particionált adatokon keresztül
  • Az ütemezés és a változás érzékelése az új és megváltozott dokumentumok indexeléséhez az idő folyamán

Az indexelő ütemezései a legutóbbi ismert leállítási ponton folytathatják a feldolgozást. Ha az adatok nincsenek teljes mértékben indexelve a feldolgozási ablakban, az indexelő a következő futtatáskor ott lép fel, ahol abbahagyta, feltéve, hogy egy olyan adatforrást használ, amely lehetővé teszi a változásészlelést.

Az adatok kisebb önálló adatforrásokba való particionálása párhuzamos feldolgozást tesz lehetővé. Feloszthatja a forrásadatokat, például több tárolóra az Azure Blob Storage-ban, létrehozhat egy adatforrást minden partícióhoz, majd párhuzamosan futtathatja az indexelőket a keresési szolgáltatás keresési egységeinek számától függően.

Indexelő kötegméretének ellenőrzése

A push API-hoz hasonlóan az indexelők lehetővé teszik az elemek kötegenkénti számának konfigurálását. Az Indexelő REST API-n alapuló indexelőknél állítsa be az batchSize argumentumot úgy, hogy a beállítás jobban megfeleljen az adatok jellemzőinek.

Az alapértelmezett kötegméretek adatforrás-specifikusak. Az Azure SQL Database és az Azure Cosmos DB alapértelmezett kötegmérete 1000. Ezzel szemben Azure Blob és SharePoint (előzetes verzió) indexelése 10 dokumentumra állítja a kötegméretet a nagyobb átlagos dokumentumméret felismerése érdekében.

Indexelők ütemezése hosszú ideig futó folyamatokhoz

Az indexelő ütemezés fontos mechanizmus a nagy adathalmazok feldolgozására és a lassan futó folyamatok, mint például a képelemzés kezelésére egy dúsítási folyamatban.

Az indexelő feldolgozása általában két órán belül fut. Ha az indexelési munkaterhelés órák helyett napokat vesz igénybe, az indexelőt két óránként kezdődő, egymást követő, ismétlődő ütemezésre helyezheti. Feltéve, hogy az adatforráson engedélyezve van a változáskövetés, az indexelő folytatja a feldolgozást, ahol utoljára abbahagyta. Ebben az ütemben az indexelők napok alatt végigvezethetik a dokumentum-hátralékot, amíg az összes feldolgozatlan dokumentum feldolgozásra nem kerül. Ez a minta különösen fontos a kezdeti futtatás vagy a nagy blobtárolók indexelése során, ahol a blobok listázási fázisa önmagában több órát vagy napot is igénybe vehet. Ez idő alatt az indexelő nem jeleníti meg a feldolgozandó blobokat, de ha nem jelentkezik hiba, akkor valószínűleg továbbra is végigvezeti a bloblistán. A dokumentumfeldolgozás és -bővítés csak a fázis befejeződése után kezdődik, és ez a viselkedés várható.

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

Ha már nincsenek új vagy frissített dokumentumok az adatforrásban, az indexelő futtatási előzményei jelentik a 0/0 feldolgozott dokumentumok számát, és nem történik további feldolgozás.

Az ütemezések beállításáról további információt az Indexelő REST API létrehozása vagy az Indexelők ütemezése az Azure AI Keresés szolgáltatásban című témakörben talál.

Megjegyzés

A maximális feldolgozási időszak attól függ, hogy az indexelő rendelkezik-e képességkészletekkel. A képességkészleteket használó indexelők belső kezelésű, több-bérlős környezetben futnak, legfeljebb 2 órás futási idővel. A megosztott privát hivatkozások használatára konfigurált indexelők legfeljebb 24 órás sebességgel futnak. A készségkészlet nélküli indexelők legfeljebb 24 órán át futnak.

Ha az indexelője olyan képességkészletet használ, amely dúsítási gyorsítótárazást alkalmaz, tekintse át az alábbi információkat, mielőtt engedélyezi a gyorsítótárazást nagyméretű terhelésekhez.

Caution

A hosszú ideig futó készségekkel, ismétlődő megszakításokkal vagy gyakori hibákkal rendelkező számítási feladatok esetében a bővítési gyorsítótár növelheti a teljes újrafeldolgozást a kezdeti betöltés vagy helyreállítás során. A bővítési gyorsítótár nem biztonsági mentés, és nem követi nyomon, hogy mely dokumentumok fejezték be a feldolgozást.

Indexelők futtatása párhuzamosan

Ha particionálja az adatokat, létrehozhat több indexelő-adatforrás kombinációt, amelyek lekéri az egyes adatforrásokat, és ugyanarra a keresési indexre írnak. Mivel mindegyik indexelő eltérő, futtathatja őket egyszerre, így gyorsabban tölt fel egy keresési indexet, mintha egymás után futtatná őket.

Győződjön meg arról, hogy elegendő kapacitással rendelkezik. A szolgáltatás egyik keresési egysége bármikor futtathat egy indexelőt. Több indexelő létrehozása csak akkor hasznos, ha párhuzamosan futtathatók.

Az egyidejűleg futtatható indexelési feladatok száma szövegalapú és képességalapú indexelés esetén eltérő. További információ: Indexelő végrehajtása.

Ha az adatforrás egy Azure Blob Storage-tároló vagy az Azure Data Lake Storage Gen 2, akkor a nagy számú blob számbavétele a művelet befejezéséig hosszú időt (akár órákat) is igénybe vehet. Ennek eredményeként az indexelő sikeresen feldolgozott dokumentumainak száma ebben az időszakban nem növekszik, ezért úgy tűnhet, hogy nem halad előre, pedig valójában igen. Ha azt szeretné, hogy a dokumentumfeldolgozás gyorsabb legyen nagy számú blob esetében, fontolja meg az adatok több tárolóba való particionálását, és hozzon létre párhuzamos indexelőket egyetlen indexre mutatva.

  1. Nyissa meg a keresési szolgáltatást az Azure Portalon.

  2. Ellenőrizze a keresési szolgáltatás által használt keresési egységek számát. Válassza a Beállítások>méretezése lehetőséget a lap tetején található szám megtekintéséhez. A párhuzamosan futó indexelők száma körülbelül megegyezik a keresési egységek számával.

  3. Forrásadatok partícionálása több tároló között vagy ugyanazon tárolón belül több virtuális mappa között.

  4. Hozzon létre több adatforrást, egyet az egyes partíciókhoz, és párosítsa a saját indexelővel.

  5. Adja meg ugyanazt a célkeresési indexet az egyes indexelőkben.

  6. Ütemezze az indexelőket.

  7. Tekintse át az indexelő állapotát és a végrehajtás történetét a megerősítéshez.

A párhuzamos indexelés bizonyos kockázatokkal jár. Először is ne feledje, hogy az indexelés nem fut a háttérben, ami megnöveli annak valószínűségét, hogy a lekérdezéseket korlátozzák vagy elvetik.

Másodszor, az Azure AI Keresés nem zárolja a frissítések indexét. Az egyidejű írások kezelése egy újrapróbálkozási kísérlet meghívásával történik, ha egy adott írás első próbálkozáskor nem sikerül, de előfordulhat, hogy az indexelési hibák megnőnek.

Bár több indexelő-adatforráskészlet is meg tudja célozni ugyanazt az indexet, ügyeljen arra, hogy az indexelő futtatás felülírja az indexben meglévő értékeket. Ha egy második indexelő adatforrás ugyanazokat a dokumentumokat és mezőket célozza meg, az első futtatásból származó értékek felülíródnak. A mezőértékek teljes mértékben lecserélődnek; az indexelők nem egyesíthetik több futtatás értékeit ugyanabba a mezőbe.

Big Data indexelése a Sparkban

Ha big data architektúrával rendelkezik, és az adatok Spark-fürtön vannak, használja a SynapseML-t az adatok betöltéséhez és indexeléshez. Az oktatóanyag a Foundry Tools aI-bővítéshez való meghívásának lépéseit tartalmazza, de az AzureSearchWriter API-t is használhatja a szövegindexeléshez.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: