Blobs en bestanden indexeren om meerdere zoekdocumenten te produceren
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
Elk document in een index wordt uniek geïdentificeerd door een documentsleutel. 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 en u wordt opgeslagen in de stap dat u deze veldtoewijzing zelf moet maken (normaal gesproken worden alleen velden met identieke namen en typen automatisch 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. De gegenereerde sleutel heet AzureSearch_DocumentKey en wordt toegevoegd 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 | timestamp |
|---|---|---|---|
| aHR0 ... YjEuanNvbjsx | 100 | 100 | 2024-02-13T00:00:00Z |
| 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 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, is daarom niet afhankelijk van de waarde 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"
U ziet dat elk document het id veld bevat dat is gedefinieerd als het key veld in de index. In dat geval wordt een document-uniek AzureSearch_DocumentKey gegenereerd, maar wordt het niet gebruikt als de 'sleutel' voor het document. In plaats daarvan wordt de waarde van het id veld toegewezen aan het key veld
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. Als dit het geval is, resulteert een json-vermelding die aangeeft een id samenvoeging op het bestaande document in plaats van een upload van een nieuw document. De status van de index geeft de meest recente leesvermelding weer met de opgegeven id.
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.