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 gespecificeerd en als er geen expliciete veldtoewijzing is in de definitie van de indexer voor de zoekdocumentsleutel, wordt de blob-indexer automatisch metadata_storage_path property als documentsleutel toegewezen. Deze standaardtoewijzing zorgt ervoor dat elke blob wordt weergegeven als een afzonderlijk zoekdocument. Bovendien hoeft u deze veldtoewijzing niet handmatig te maken. Normaal gesproken zijn velden met identieke namen en typen de enige die automatisch zijn toegewezen.
In een zoekdocumentscenario van één-op-veel is een impliciete documentensleutel 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.
Example
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-kaart | temperatuur | druk | tijdstempel |
|---|---|---|---|
| aHR0 ... YjEuanNvbjsx | 100 | 100 | 13 februari 2024 00:00:00 UTC |
| aHR0 ... YjEuanNvbjsy | 33 | 30 | 2024-02-14T00:00:00Z |
| aHR0 ... YjIuanNvbjsx | 1 | 1 | 2023-01-12T00:00:00Z |
| 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 mapping leidt echter niet tot vier documenten die in de index worden weergegeven, omdat het recordid veld niet uniek is over 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.
Opmerking
De aanpak die door AzureSearch_DocumentKey wordt gebruikt om te zorgen voor de unieke identificatie van elke geëxtraheerde entiteit kan worden gewijzigd. Daarom moet u niet rekenen op de waarde ervan voor de behoeften van uw applicatie.
Geef het indexsleutelveld op in uw gegevens
Aangenomen dat dezelfde indexdefinitie wordt gebruikt als in het vorige voorbeeld en dat parsingMode is ingesteld op jsonLines zonder expliciete veldtoewijzingen te specificeren, zodat de toewijzingen overeenkomen met die in het eerste voorbeeld, stel dat uw container blobs heeft met de volgende structuur:
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 theidfield is mapped to the-sleutelveld.
Net als in het vorige voorbeeld resulteert deze koppeling niet in vier documenten die in de index verschijnen, omdat het id veld niet uniek is over blobs heen. Wanneer deze situatie zich voordoet, veroorzaakt elke JSON-vermelding die een id aangeeft een samenvoeging met het bestaande document in plaats van een nieuw document te uploaden. De index weerspiegelt vervolgens de meest recente status van de vermelding zoals opgegeven met id.
Beperkingen
Wanneer een documentvermelding in de index wordt gemaakt op basis van een regel in een bestand, zoals wordt uitgelegd in dit artikel, wordt deze regel uit het bestand niet automatisch verwijderd 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.