Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op: Blob-indexeerfuncties, bestandsindexeerfuncties
Standaard behandelt een indexeerfunctie de inhoud van een blob of bestand als één zoekdocument. Als u een gedetailleerdere weergave in een zoekindex wilt, kunt u parsingMode-waarden instellen om meerdere zoekdocumenten te maken op basis van één blob of bestand. De parsingMode-waarden die resulteren in veel zoekdocumenten zijn onder andere delimitedText (voor CSV) en jsonArray ( jsonLines voor JSON).
Wanneer u een van deze parseringsmodi gebruikt, moeten de nieuwe zoekdocumenten die zich voordoen unieke documentsleutels hebben en ontstaat er een probleem bij het bepalen van waar die waarde vandaan komt. De bovenliggende blob heeft ten minste één unieke waarde in de vorm van metadata_storage_path property, maar als deze waarde bijdraagt aan meer dan één zoekdocument, is de sleutel niet meer uniek in de index.
Om dit probleem op te lossen, genereert de blob-indexeerfunctie een AzureSearch_DocumentKey unieke identificatie van elk onderliggend zoekdocument dat is gemaakt op basis van de bovenliggende blob. In dit artikel wordt uitgelegd hoe deze functie werkt.
Een-op-veel-documentsleutel
Een documentsleutel identificeert elk document in een index op unieke wijze. Wanneer er geen parseermodus is opgegeven en als er geen expliciete veldtoewijzing is in de definitie van de indexeerfunctie voor de zoekdocumentsleutel, wordt de blob-indexeerfunctie automatisch toegewezen metadata_storage_path property als de documentsleutel. Deze standaardtoewijzing zorgt ervoor dat elke blob wordt weergegeven als een afzonderlijk zoekdocument. Bovendien hoeft u deze veldtoewijzing niet handmatig te maken. Velden met identieke namen en typen zijn normaal gesproken de enige velden die automatisch worden toegewezen.
In een een-op-veel-documentscenario is een impliciete documentsleutel op basis van metadata_storage_path property niet mogelijk. Als tijdelijke oplossing kan Azure AI Search een documentsleutel genereren voor elke afzonderlijke entiteit die is geëxtraheerd uit een blob. Het systeem genereert een sleutel met de naam AzureSearch_DocumentKey en voegt deze toe aan elk zoekdocument. De indexeerfunctie houdt de 'veel documenten' bij die zijn gemaakt op basis van elke blob en kan gericht zijn op updates van de zoekindex wanneer de brongegevens na verloop van tijd worden gewijzigd.
Wanneer er standaard geen expliciete veldtoewijzingen voor het sleutelindexveld worden opgegeven, wordt het AzureSearch_DocumentKey eraan toegewezen met behulp van de base64Encode functie voor veldtoewijzing.
Opmerking
Stel dat u een indexdefinitie met de volgende velden hebt:
idtemperaturepressuretimestamp
En uw blobcontainer heeft blobs met de volgende structuur:
Blob1.json
{ "temperature": 100, "pressure": 100, "timestamp": "2024-02-13T00:00:00Z" }
{ "temperature" : 33, "pressure" : 30, "timestamp": "2024-02-14T00:00:00Z" }
Blob2.json
{ "temperature": 1, "pressure": 1, "timestamp": "2023-01-12T00:00:00Z" }
{ "temperature" : 120, "pressure" : 3, "timestamp": "2022-05-11T00:00:00Z" }
Wanneer u een indexeerfunctie maakt en de parsingModejsonLines instelt op - zonder expliciete veldtoewijzingen voor het sleutelveld op te geven, wordt de volgende toewijzing impliciet toegepast.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Deze instelling resulteert in ondubbelzinnige documentsleutels, vergelijkbaar met de volgende afbeelding (base64-gecodeerde id ingekort voor beknoptheid).
| Id | temperatuur | druk | tijdstempel |
|---|---|---|---|
| aHR0 ... YjEuanNvbjsx | 100 | 100 | 2024-02-13T00:00:00Z |
| aHR0 ... YjEuanNvbjsy | 33 | 30 | 2024-02-14T00:00:00Z |
| aHR0 ... YjIuanNvbjsx | 1 | 1 | 12 januari 2023 00:00:00 UTC |
| aHR0 ... YjIuanNvbjsy | 120 | 3 | 2022-05-11T00:00:00Z |
Aangepaste veldtoewijzing voor indexsleutelveld
Stel dat uw blobcontainer blobs met de volgende structuur heeft, uitgaande van dezelfde indexdefinitie als in het vorige voorbeeld:
Blob1.json
recordid, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z"
2, 33, 30,"2024-02-14T00:00:00Z"
Blob2.json
recordid, temperature, pressure, timestamp
1, 1, 1,"20123-01-12T00:00:00Z"
2, 120, 3,"2022-05-11T00:00:00Z"
Wanneer u een indexeerfunctie met delimitedTextparsingMode maakt, kan het logisch zijn om als volgt een functie voor veldtoewijzing in te stellen op het sleutelveld:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Deze toewijzing resulteert echter niet in vier documenten die in de index worden weergegeven, omdat het recordid veld niet uniek is in blobs. Daarom raden we u aan om gebruik te maken van de impliciete veldtoewijzing die van de AzureSearch_DocumentKey eigenschap is toegepast op het sleutelindexveld voor 'een-op-veel'-parseringsmodi.
Als u een expliciete veldtoewijzing wilt instellen, moet u ervoor zorgen dat het sourceField voor elke afzonderlijke entiteit uniek is voor alle blobs.
Notitie
De benadering die wordt gebruikt om AzureSearch_DocumentKey ervoor te zorgen dat de uniekheid per geëxtraheerde entiteit wordt gewijzigd en daarom moet u niet afhankelijk zijn van de waarde ervan voor de behoeften van uw toepassing.
Geef het indexsleutelveld op in uw gegevens
Ervan uitgaande dat dezelfde indexdefinitie als in het vorige voorbeeld en parsingMode is ingesteld jsonLines zonder expliciete veldtoewijzingen op te geven, zodat de toewijzingen eruitzien in het eerste voorbeeld, stel dat uw blobcontainer blobs met de volgende structuur heeft:
Blob1.json
id, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z"
2, 33, 30,"2024-02-14T00:00:00Z"
Blob2.json
id, temperature, pressure, timestamp
1, 1, 1,"2023-01-12T00:00:00Z"
2, 120, 3,"2022-05-11T00:00:00Z"
Elk document bevat het id veld, dat is gedefinieerd als het key veld in de index. In dit geval genereert het systeem een uniek AzureSearch_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theid-sleutelveldfield is mapped to the.
Net als in het vorige voorbeeld resulteert deze toewijzing niet in vier documenten die in de index worden weergegeven, omdat het id veld niet uniek is in blobs. Wanneer deze situatie zich voordoet, zorgt elke JSON-vermelding die een id aangeeft ervoor dat er een samenvoeging met het bestaande document plaatsvindt in plaats van het uploaden van een nieuw document. De index geeft dan de meest recente status van de opgegeven vermelding weer met de id.
Beperkingen
Wanneer een documentvermelding in de index wordt gemaakt op basis van een regel in een bestand, zoals wordt uitgelegd in dit artikel, verwijdert u die regel uit het bestand niet automatisch de bijbehorende vermelding uit de index. Als u de documentvermelding wilt verwijderen, moet u handmatig een verwijderingsaanvraag indienen bij de index met behulp van de REST API-verwijderingsbewerking.
Volgende stappen
Als u nog niet bekend bent met de basisstructuur en werkstroom van blobindexering, moet u eerst Azure Blob Storage indexeren met Azure AI Search . Raadpleeg de volgende artikelen voor meer informatie over parseringsmodi voor verschillende blob-inhoudstypen.