Grote gegevenssets indexeren in Azure AI Search

  • Artikel

Als uw zoekoplossingsvereisten het indexeren van big data of complexe gegevens omvatten, worden in dit artikel strategieën beschreven voor het inschakelen van langlopende processen in Azure AI Search.

In dit artikel wordt ervan uitgegaan dat u bekend bent met de twee basismethoden voor het importeren van gegevens: gegevens naar een index pushen of gegevens ophalen uit een ondersteunde gegevensbron met behulp van een zoekindexeerfunctie. Als uw scenario rekenintensieve AI-verrijking omvat, zijn indexeerfuncties vereist, gezien de afhankelijkheid van de vaardighedenset van indexeerfuncties.

Dit artikel vormt een aanvulling op tips voor betere prestaties, die aanbevolen procedures biedt voor index- en queryontwerp. Een goed ontworpen index die alleen de velden en kenmerken bevat die u nodig hebt, is een belangrijke vereiste voor grootschalige indexering.

U wordt aangeraden een nieuwere zoekservice te gebruiken die na 3 april 2024 is gemaakt voor een hogere opslag per partitie.

Notitie

Bij de strategieën die in dit artikel worden beschreven, wordt uitgegaan van één grote gegevensbron. Als voor uw oplossing indexering van meerdere gegevensbronnen is vereist, raadpleegt u Meerdere gegevensbronnen indexeren in Azure AI Search voor een aanbevolen benadering.

Grote gegevens indexeren met behulp van de push-API's

'Push'-API's, zoals Documents Index REST API of de Methode IndexDocuments (Azure SDK voor .NET), zijn de meest voorkomende vorm van indexering in Azure AI Search. Voor oplossingen die een push-API gebruiken, heeft de strategie voor langlopende indexering een of beide van de volgende onderdelen:

  • Documenten batcheren
  • Threads beheren

Meerdere documenten per aanvraag batchgewijs verwerken

Een eenvoudig mechanisme voor het indexeren van een grote hoeveelheid gegevens is het indienen van meerdere documenten of records in één aanvraag. Zolang de volledige nettolading minder is dan 16 MB, kan een aanvraag maximaal 1000 documenten verwerken in een bulksgewijs uploadbewerking. Deze limieten zijn van toepassing, ongeacht of u de REST API van Documents Index of de methode IndexDocuments in de .NET SDK gebruikt. Voor beide API's verpakt u 1000 documenten in de hoofdtekst van elke aanvraag.

Batchverwerking van documenten verkort de hoeveelheid tijd die nodig is om een groot gegevensvolume te doorlopen. Het vaststellen van de optimale batchgrootte voor uw gegevens is een belangrijk onderdeel van voor het optimaliseren van de indexeringssnelheid. De twee primaire factoren die van invloed zijn op de optimale batchgrootte zijn:

  • Het schema van uw index
  • De hoeveelheid gegevens

Omdat de optimale batchgrootte afhankelijk is van uw index en uw gegevens, kunt u het beste verschillende batchgrootten testen om te bepalen welke de snelste indexeringssnelheden voor uw scenario oplevert. Zelfstudie: Indexering optimaliseren met de push-API biedt voorbeeldcode voor het testen van batchgrootten met behulp van de .NET SDK.

Threads en een strategie voor opnieuw proberen toevoegen

Indexeerfuncties hebben ingebouwd threadbeheer, maar wanneer u de push-API's gebruikt, moet uw toepassingscode threads beheren. Zorg ervoor dat er voldoende threads zijn om volledig gebruik te maken van de beschikbare capaciteit, met name als u onlangs partities hebt verhoogd of een upgrade hebt uitgevoerd naar een zoekservice met een hogere laag.

  1. Verhoog het aantal gelijktijdige threads in uw clientcode.

  2. Wanneer u de aanvragen voor de zoekservice opvoert, kunt u HTTP-statuscodes tegenkomen die aangeven dat de aanvraag niet volledig is geslaagd. Twee veelvoorkomende HTTP-statuscodes die zich tijdens het indexeren kunnen voordoen, zijn:

    • 503: service niet beschikbaar: deze fout betekent dat het systeem zwaar belast wordt en uw aanvraag op dit moment niet kan worden verwerkt.

    • 207: meerdere statussen: deze fout betekent dat sommige documenten zijn geslaagd, maar dat er ten minste één is mislukt.

  3. Als u fouten wilt afhandelen, moeten aanvragen opnieuw worden geprobeerd met behulp van een strategie voor exponentieel uitstel.

De Azure .NET SDK probeert automatisch 503's en andere mislukte aanvragen opnieuw, maar u moet uw eigen logica implementeren om 207s opnieuw te proberen. Opensource-hulpprogramma's als Polly kunnen ook worden gebruikt voor het implementeren van een herhaalstrategie.

Indexeren met indexeerfuncties en de pull-API's

Indexeerfuncties hebben verschillende mogelijkheden die handig zijn voor langlopende processen:

  • Documenten batcheren
  • Parallelle indexering over gepartitioneerde gegevens
  • Plannings- en wijzigingsdetectie voor het indexeren van alleen nieuwe en gewijzigde documenten in de loop van de tijd

Indexeerschema's kunnen de verwerking hervatten op het laatst bekende stoppunt. Als gegevens niet volledig zijn geïndexeerd in het verwerkingsvenster, wordt de indexeerfunctie opgehaald waar deze zich bij de volgende uitvoering bevinden, ervan uitgaande dat u een gegevensbron gebruikt die wijzigingsdetectie biedt.

Het partitioneren van gegevens in kleinere afzonderlijke gegevensbronnen maakt parallelle verwerking mogelijk. U kunt brongegevens opsplitsen, zoals in meerdere containers in Azure Blob Storage, een gegevensbron maken voor elke partitie en vervolgens de indexeerfuncties parallel uitvoeren, afhankelijk van het aantal zoekeenheden van uw zoekservice.

De batchgrootte van de indexeerfunctie controleren

Net als bij de push-API kunt u met indexeerfuncties het aantal items per batch configureren. Voor indexeerfuncties op basis van de REST API voor Indexeerfunctie maken kunt u het batchSize argument instellen om deze instelling aan te passen zodat deze beter overeenkomt met de kenmerken van uw gegevens.

Standaard batchgrootten zijn gegevensbronspecifiek. Azure SQL Database en Azure Cosmos DB hebben een standaard batchgrootte van 1000. Azure Blob-indexering stelt daarentegen de batchgrootte in op 10 documenten in de herkenning van de grotere gemiddelde documentgrootte.

Indexeerfuncties plannen voor langlopende processen

Het plannen van indexeerfuncties is een belangrijk mechanisme voor het verwerken van grote gegevenssets en voor het ondersteunen van traaglopende processen zoals afbeeldingsanalyse in een verrijkingspijplijn.

Normaal gesproken wordt de verwerking van de indexeerfunctie binnen een periode van 2 uur uitgevoerd. Als de indexeringsworkload dagen in plaats van uren duurt, kunt u de indexeerfunctie op een opeenvolgende, terugkerende planning plaatsen die om de twee uur begint. Ervan uitgaande dat wijzigingen bijhouden is ingeschakeld voor de gegevensbron, wordt de verwerking hervat waar deze het laatst is gebleven. Bij deze frequentie kan een indexeerfunctie een documentachterstand gedurende een reeks dagen doorlopen totdat alle niet-verwerkte documenten worden verwerkt.

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

Wanneer er geen nieuwe of bijgewerkte documenten meer in de gegevensbron staan, worden documenten verwerkt en 0/0 vindt er geen verwerking plaats.

Zie REST API voor indexeerfunctie maken of indexeerfuncties plannen voor Azure AI Search voor meer informatie over het instellen van planningen.

Notitie

Sommige indexeerfuncties die worden uitgevoerd op een oudere runtime-architectuur hebben een periode van 24 uur in plaats van een maximaal verwerkingsvenster van 2 uur. De limiet van 2 uur is voor nieuwere inhoudsprocessors die worden uitgevoerd in een intern beheerde omgeving met meerdere tenants. Waar mogelijk probeert Azure AI Search indexeerfuncties en vaardighedensetverwerking te offloaden naar de omgeving met meerdere tenants. Als de indexeerfunctie niet kan worden gemigreerd, wordt deze uitgevoerd in de privéomgeving en kan deze gedurende 24 uur worden uitgevoerd. Als u een indexeerfunctie plant die deze kenmerken vertoont, gaat u uit van een verwerkingsvenster van 24 uur.

Indexeerfuncties parallel uitvoeren

Als u uw gegevens partitioneert, kunt u meerdere combinaties van indexeerfuncties voor gegevensbronnen maken die uit elke gegevensbron worden opgehaald en naar dezelfde zoekindex worden geschreven. Omdat elke indexeerfunctie uniek is, kunt u ze tegelijkertijd uitvoeren, waardoor een zoekindex sneller wordt gevuld dan wanneer u ze opeenvolgend hebt uitgevoerd.

Zorg ervoor dat u voldoende capaciteit hebt. Eén zoekeenheid in uw service kan op elk gewenst moment één indexeerfunctie uitvoeren. Het maken van meerdere indexeerfuncties is alleen nuttig als ze parallel kunnen worden uitgevoerd.

Het aantal indexeringstaken dat tegelijkertijd kan worden uitgevoerd, varieert voor indexering op basis van tekst en vaardigheden. Zie De uitvoering van de indexeerfunctie voor meer informatie.

Als uw gegevensbron een Azure Blob Storage-container of Azure Data Lake Storage Gen 2 is, kan het opsommen van een groot aantal blobs lang (zelfs uren) duren totdat deze bewerking is voltooid. Dit zorgt ervoor dat het aantal voltooide documenten van uw indexeerfunctie gedurende die tijd niet wordt verhoogd en het lijkt erop dat het geen voortgang maakt, wanneer dit het geval is. Als u wilt dat documentverwerking sneller verloopt voor een groot aantal blobs, kunt u overwegen uw gegevens te partitioneren in meerdere containers en parallelle indexeerfuncties te maken die verwijzen naar één index.

  1. Meld u aan bij Azure Portal en controleer het aantal zoekeenheden dat door uw zoekservice wordt gebruikt. Selecteer Instellingen> Schaal om het nummer boven aan de pagina weer te geven. Het aantal indexeerfuncties dat parallel wordt uitgevoerd, is ongeveer gelijk aan het aantal zoekeenheden.

  2. Partitiebrongegevens tussen meerdere containers of meerdere virtuele mappen in dezelfde container.

  3. Maak meerdere gegevensbronnen, één voor elke partitie, gekoppeld aan een eigen indexeerfunctie.

  4. Geef dezelfde doelzoekindex op in elke indexeerfunctie.

  5. Plan de indexeerfuncties.

  6. Controleer de status van de indexeerfunctie en uitvoeringsgeschiedenis voor bevestiging.

Er zijn enkele risico's verbonden aan parallelle indexering. U herinnert zich eerst dat indexering niet op de achtergrond wordt uitgevoerd, waardoor de kans toeneemt dat query's worden beperkt of verwijderd.

Ten tweede vergrendelt Azure AI Search de index niet voor updates. Gelijktijdige schrijfbewerkingen worden beheerd, waarbij u een nieuwe poging aanroept als een bepaalde schrijfbewerking niet lukt bij de eerste poging, maar u merkt mogelijk een toename in indexeringsfouten.

Hoewel meerdere indexeerfunctie-gegevensbronsets dezelfde index kunnen gebruiken, moet u voorzichtig zijn met indexeerfuncties die bestaande waarden in de index kunnen overschrijven. Als een tweede indexeerfunctie-gegevensbron gericht is op dezelfde documenten en velden, worden alle waarden van de eerste uitvoering overschreven. Veldwaarden worden volledig vervangen; een indexeerfunctie kan geen waarden uit meerdere uitvoeringen samenvoegen in hetzelfde veld.

Big data indexeren in Spark

Als u een big data-architectuur hebt en uw gegevens zich in een Spark-cluster bevinden, raden we SynapseML aan voor het laden en indexeren van gegevens. De zelfstudie bevat stappen voor het aanroepen van Azure AI-services voor AI-verrijking, maar u kunt ook de AzureSearchWriter-API gebruiken voor tekstindexering.

Zie ook