Nagyméretű adathalmazok indexelése az Azure AI Searchben

Ha a keresési megoldás követelményei közé tartozik a big data vagy az összetett adatok indexelése, ez a cikk a hosszú ideig futó folyamatok Azure AI Searchben való elhelyezésére vonatkozó stratégiákat ismerteti.

Ez a cikk feltételezi, hogy ismeri 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 jobb teljesítmény érdekében Tippek, 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.

Javasoljuk, hogy egy újabb keresési szolgáltatást használjon, amely 2024. április 3. után jött létre a partíciónkénti nagyobb tárterülethez.

Feljegyzé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 Searchben .

Nagyméretű adatok indexelése leküldéses API-k használatával

A "Push" API-k, például a Documents Index REST API vagy az IndexDocuments metódus (.NET-hez készült Azure SDK) az Azure AI Searchben az indexelés legelterjedtebb formája. 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ötegelve 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-hoz 1000 dokumentumot csomagolna 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ásoló 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. Oktatóanyag: Az indexelés optimalizálása a push API-val mintakódot biztosít a kötegméretek teszteléséhez a .NET SDK használatával.

Szálak hozzáadása és újrapróbálkozás stratégiája

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 növelte a partíciókat, vagy magasabb szintű keresési szolgáltatásra frissített.

  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 a 207-ek újrapróbálkozásához saját logikát kell implementálnia. 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és indexelőkkel és "lekéréses" API-kkal

Az indexelők számos olyan képességgel rendelkeznek, amelyek hasznosak a hosszú ideig futó folyamatokhoz:

  • Dokumentumok kötegelése
  • Párhuzamos indexelés particionált adatokon keresztül
  • Ütemezés és változásészlelés csak az új és a dokumentumok időben történő módosításához

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 a változásészlelést biztosítja.

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ők esetében az batchSize argumentumot úgy állíthatja be, 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 az Azure Blob indexelése 10 dokumentumra állítja be a kötegméretet a nagyobb átlagos dokumentumméret elismeréseként.

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

Az indexelőütemezés fontos mechanizmus a nagy adathalmazok feldolgozásához és a lassú folyamatokat, például a képelemzést egy bővítési folyamatban.

Az indexelő feldolgozása általában egy 2 órás időszakon 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ásban engedélyezve van a változáskövetés, az indexelő folytatja a feldolgozást ott, 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.

{
    "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őzmények a feldolgozott dokumentumokat jelentik 0/0 , és nem történik 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 Search szolgáltatásban című témakörben talál.

Feljegyzés

A régebbi futtatókörnyezeti architektúrán futó indexelők egy része 24 órás, nem pedig 2 órás maximális feldolgozási időszakkal rendelkezik. A 2 órás korlát az újabb tartalomfeldolgozókra vonatkozik, amelyek belsőleg felügyelt több-bérlős környezetben futnak. Amikor csak lehetséges, az Azure AI Search megpróbálja kiszervezni az indexelőt és a készségkészlet-feldolgozást a több-bérlős környezetbe. Ha az indexelő nem migrálható, akkor a privát környezetben fog futni, és akár 24 óráig is futtatható. Ha olyan indexelőt ütemez, amely ezeket a jellemzőket jeleníti meg, feltételezze a 24 órás feldolgozási időszakot.

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 az egyes indexelők eltérőek, futtathatja őket egyszerre, és gyorsabban feltöltheti a 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. Ez azt eredményezi, hogy az indexelő dokumentumainak sikeres száma ebben az időszakban nem növekedett, és úgy tűnhet, hogy nem halad előre, ha 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. Jelentkezzen be az Azure Portalra , és ellenőrizze a keresési szolgáltatás által használt keresési egységek számát. Válassza a Gépház> Skálázás lehetőséget a lap tetején lévő 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.

  2. Particionálási forrásadatok több tároló vagy több virtuális mappa között ugyanabban a tárolóban.

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

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

  5. Ütemezze az indexelőket.

  6. Tekintse át az indexelőzmények állapotát és végrehajtási előzményeit 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 növeli a lekérdezések szabályozásának vagy elvetésének valószínűségét.

Másodszor, az Azure AI Search nem zárolja a frissítések indexét. Az egyidejű írások kezelése újrapróbálkozást vált ki, ha egy adott írás első próbálkozáskor nem sikerül, de az indexelési hibák számának növekedése észlelhető.

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, javasoljuk, hogy a SynapseML-t az adatok betöltéséhez és indexeléshez. Az oktatóanyag az Azure AI-szolgáltatások 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.

Lásd még