Indexering av stora datamängder i Azure AI Search

  • Artikel

Om dina söklösningskrav omfattar indexering av stordata eller komplexa data formulerar den här artikeln strategier för att hantera tidskrävande processer i Azure AI Search.

Den här artikeln förutsätter att du är bekant med de två grundläggande metoderna för att importera data: push-överföra data till ett index eller hämta data från en datakälla som stöds med hjälp av en sökindexerare. Om ditt scenario omfattar beräkningsintensiv AI-berikning krävs indexerare med tanke på indexerarnas kompetensuppsättningsberoende.

Den här artikeln kompletterar Tips för bättre prestanda, som erbjuder metodtips för index- och frågedesign. Ett väl utformat index som endast innehåller de fält och attribut du behöver är en viktig förutsättning för storskalig indexering.

Vi rekommenderar att du använder en nyare söktjänst som skapats efter den 3 april 2024 för högre lagring per partition.

Kommentar

De strategier som beskrivs i den här artikeln förutsätter en enda stor datakälla. Om din lösning kräver indexering från flera datakällor kan du läsa Indexera flera datakällor i Azure AI Search för en rekommenderad metod.

Indexering av stora data med push-API:er

"Push"-API:er, till exempel Documents Index REST API eller IndexDocuments-metoden (Azure SDK för .NET), är den vanligaste formen av indexering i Azure AI Search. För lösningar som använder ett push-API har strategin för långvarig indexering en eller båda av följande komponenter:

  • Batchbearbetningsdokument
  • Hantera trådar

Batch flera dokument per begäran

En enkel mekanism för att indexera en stor mängd data är att skicka flera dokument eller poster i en enda begäran. Så länge hela nyttolasten är under 16 MB kan en begäran hantera upp till 1 000 dokument i en massuppladdningsåtgärd. Dessa gränser gäller oavsett om du använder REST API för dokumentindex eller metoden IndexDocuments i .NET SDK. För båda API:erna paketerade du 1 000 dokument i brödtexten för varje begäran.

Batchbearbetning av dokument förkortar avsevärt den tid det tar att arbeta med en stor datavolym. Att fastställa den optimala batchstorleken för dina data är en viktig komponent för att optimera indexeringshastigheter. De två primära faktorerna som påverkar den optimala batchstorleken är:

  • Schemat för ditt index
  • Storleken på dina data

Eftersom den optimala batchstorleken beror på ditt index och dina data är den bästa metoden att testa olika batchstorlekar för att avgöra vilket som resulterar i de snabbaste indexeringshastigheterna för ditt scenario. Självstudie: Optimera indexering med push-API :et innehåller exempelkod för testning av batchstorlekar med hjälp av .NET SDK.

Lägga till trådar och en strategi för återförsök

Indexerare har inbyggd trådhantering, men när du använder push-API:erna måste programkoden hantera trådar. Se till att det finns tillräckligt med trådar för att utnyttja den tillgängliga kapaciteten fullt ut, särskilt om du nyligen har ökat partitionerna eller har uppgraderat till en söktjänst på högre nivå.

  1. Öka antalet samtidiga trådar i klientkoden.

  2. När du ökar antalet begäranden som når söktjänsten kan det uppstå HTTP-statuskoder som anger att begäran inte lyckades helt. Under indexeringen är två vanliga HTTP-statuskoder:

    • 503 Tjänsten är inte tillgänglig – Det här felet innebär att systemet är hårt belastat och att din begäran inte kan bearbetas just nu.

    • 207 Multi-Status – Det här felet innebär att vissa dokument lyckades, men minst ett misslyckades.

  3. För att hantera fel bör begäranden försökas igen med hjälp av en exponentiell strategi för återförsök av backoff.

Azure .NET SDK försöker automatiskt 503:e och andra misslyckade begäranden igen, men du måste implementera din egen logik för att försöka 207:e igen. Verktyg med öppen källkod, till exempel Polly , kan också användas för att implementera en återförsöksstrategi.

Index med indexerare och "pull"-API:er

Indexerare har flera funktioner som är användbara för långvariga processer:

  • Batchbearbetningsdokument
  • Parallell indexering över partitionerade data
  • Schemaläggning och ändringsidentifiering för indexering bara nya och ändra dokument över tid

Indexerarens scheman kan återuppta bearbetningen vid den senaste kända stopppunkten. Om data inte är helt indexerade i bearbetningsfönstret fortsätter indexeraren var den än slutade vid nästa körning, förutsatt att du använder en datakälla som tillhandahåller ändringsidentifiering.

Partitionering av data i mindre enskilda datakällor möjliggör parallell bearbetning. Du kan dela upp källdata, till exempel i flera containrar i Azure Blob Storage, skapa en datakälla för varje partition och sedan köra indexerarna parallellt, med förbehåll för antalet sökenheter i söktjänsten.

Kontrollera indexerarens batchstorlek

Precis som med push-API:et kan indexerare konfigurera antalet objekt per batch. För indexerare som baseras på REST-API:et Skapa indexerare kan du ange argumentet för att anpassa den batchSize här inställningen så att den bättre matchar egenskaperna för dina data.

Standard batchstorlekar är specifika för datakällan. Azure SQL Database och Azure Cosmos DB har en standard batchstorlek på 1 000. Azure Blob-indexering anger däremot batchstorleken till 10 dokument som en igenkänning av den större genomsnittliga dokumentstorleken.

Schemalägga indexerare för tidskrävande processer

Schemaläggning av indexerare är en viktig mekanism för bearbetning av stora datamängder och för att hantera långsamma processer som bildanalys i en berikningspipeline.

Normalt körs indexerarens bearbetning inom ett 2-timmarsfönster. Om indexeringsarbetsbelastningen tar dagar i stället för timmar att slutföra kan du placera indexeraren enligt ett återkommande schema i följd som startar varannan timme. Förutsatt att datakällan har aktiverat ändringsspårning återupptar indexeraren bearbetningen där den senast slutade. I det här läget kan en indexerare arbeta sig igenom en dokumentlogg under en serie dagar tills alla obearbetade dokument bearbetas.

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

När det inte längre finns några nya eller uppdaterade dokument i datakällan rapporterar 0/0 indexerarens körningshistorik bearbetade dokument och ingen bearbetning sker.

Mer information om hur du ställer in scheman finns i Skapa Indexer REST API eller så här schemalägger du indexerare för Azure AI Search.

Kommentar

Vissa indexerare som körs i en äldre körningsarkitektur har en 24-timmars i stället för 2-timmars maximal bearbetningsperiod. Gränsen på 2 timmar gäller för nyare innehållsprocessorer som körs i en internt hanterad miljö för flera klientorganisationer. När det är möjligt försöker Azure AI Search avlasta indexeraren och kunskapsuppsättningsbearbetningen till miljön för flera klientorganisationer. Om indexeraren inte kan migreras körs den i den privata miljön och kan köras så länge som 24 timmar. Om du schemalägger en indexerare som uppvisar dessa egenskaper antar du ett 24-timmars bearbetningsfönster.

Köra indexerare parallellt

Om du partitionera dina data kan du skapa flera kombinationer av indexerare-datakälla som hämtar från varje datakälla och skriver till samma sökindex. Eftersom varje indexerare är distinkt kan du köra dem samtidigt och fylla i ett sökindex snabbare än om du körde dem sekventiellt.

Kontrollera att du har tillräckligt med kapacitet. En sökenhet i tjänsten kan köra en indexerare när som helst. Att skapa flera indexerare är bara användbart om de kan köras parallellt.

Antalet indexeringsjobb som kan köras samtidigt varierar för textbaserad och kunskapsbaserad indexering. Mer information finns i Indexer-körning.

Om din datakälla är en Azure Blob Storage-container eller Azure Data Lake Storage Gen 2 kan det ta lång tid att räkna upp ett stort antal blobar (till och med timmar) tills åtgärden har slutförts. Detta gör att indexerarens dokument lyckades inte ökas under den tiden och det kan verka som om den inte gör några framsteg, när den är det. Om du vill att dokumentbearbetningen ska gå snabbare för ett stort antal blobar kan du överväga att partitionera dina data i flera containrar och skapa parallella indexerare som pekar på ett enda index.

  1. Logga in på Azure-portalen och kontrollera antalet sökenheter som används av söktjänsten. Välj Inställningar> Skala för att visa talet överst på sidan. Antalet indexerare som ska köras parallellt är ungefär lika med antalet sökenheter.

  2. Partitionering av källdata mellan flera containrar eller flera virtuella mappar i samma container.

  3. Skapa flera datakällor, en för varje partition, tillsammans med sin egen indexerare.

  4. Ange samma målsökningsindex i varje indexerare.

  5. Schemalägg indexerarna.

  6. Granska indexerarens status och körningshistorik för bekräftelse.

Det finns vissa risker som är kopplade till parallell indexering. Kom först ihåg att indexering inte körs i bakgrunden, vilket ökar sannolikheten för att frågor begränsas eller tas bort.

För det andra låser Inte Azure AI Search indexet för uppdateringar. Samtidiga skrivningar hanteras och anropar ett nytt försök om en viss skrivning inte lyckas vid första försöket, men du kanske märker en ökning av indexeringsfel.

Även om flera indexerare-data-källuppsättningar kan rikta in sig på samma index, bör du vara försiktig med indexeringskörningar som kan skriva över befintliga värden i indexet. Om en andra indexerare-datakälla riktar in sig på samma dokument och fält skrivs alla värden från den första körningen över. Fältvärden ersätts i sin helhet. En indexerare kan inte slå samman värden från flera körningar till samma fält.

Indexering av stordata på Spark

Om du har en arkitektur för stordata och dina data finns i ett Spark-kluster rekommenderar vi SynapseML för inläsning och indexering av data. Självstudien innehåller steg för att anropa Azure AI-tjänster för AI-berikning, men du kan också använda AzureSearchWriter API för textindexering.

Se även