Indexera blobar och filer för att skapa flera sökdokument
Gäller för: Blob-indexerare, filindexerare
Som standard behandlar en indexerare innehållet i en blob eller fil som ett enda sökdokument. Om du vill ha en mer detaljerad representation i ett sökindex kan du ange parsingMode-värden för att skapa flera sökdokument från en blob eller fil. De parsingMode-värden som resulterar i många sökdokument inkluderar delimitedText (för CSV) och jsonArray eller jsonLines (för JSON).
När du använder något av dessa parsningslägen måste de nya sökdokumenten som dyker upp ha unika dokumentnycklar, och ett problem uppstår när det gäller att avgöra var värdet kommer ifrån. Den överordnade bloben har minst ett unikt värde i form av metadata_storage_path property, men om den bidrar med det värdet till mer än ett sökdokument är nyckeln inte längre unik i indexet.
För att lösa det här problemet genererar blobindexeraren ett AzureSearch_DocumentKey som unikt identifierar varje underordnat sökdokument som skapats från den överordnade bloben. Den här artikeln förklarar hur den här funktionen fungerar.
En-till-många-dokumentnyckel
Varje dokument i ett index identifieras unikt av en dokumentnyckel. När inget parsningsläge har angetts och det inte finns någon explicit fältmappning i indexerarens definition för sökdokumentnyckeln mappar metadata_storage_path property blobindexeraren automatiskt som dokumentnyckel. Den här standardmappningen säkerställer att varje blob visas som ett distinkt sökdokument och sparar steget att behöva skapa det här fältet själv (normalt mappas endast fält med identiska namn och typer).
I ett en-till-många-sökdokumentscenario är en implicit dokumentnyckel baserad på metadata_storage_path property inte möjlig. Som en lösning kan Azure AI Search generera en dokumentnyckel för varje enskild entitet som extraheras från en blob. Den genererade nyckeln namnges AzureSearch_DocumentKey och läggs till i varje sökdokument. Indexeraren håller reda på "många dokument" som skapats från varje blob och kan rikta uppdateringar till sökindexet när källdata ändras över tid.
När inga explicita fältmappningar för nyckelindexfältet har angetts AzureSearch_DocumentKey mappas som standard till det med hjälp av base64Encode funktionen fältmappning.
Exempel
Anta en indexdefinition med följande fält:
idtemperaturepressuretimestamp
Och blobcontainern har blobar med följande struktur:
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" }
När du skapar en indexerare och anger parsingMode till jsonLines – utan att ange några explicita fältmappningar för nyckelfältet tillämpas följande mappning implicit.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Den här konfigurationen resulterar i tvetydiga dokumentnycklar som liknar följande bild (base64-kodat ID förkortat för korthet).
| ID | temperatur | tryck | 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 |
Anpassad fältmappning för indexnyckelfält
Anta att blobcontainern har blobbar med följande struktur om du antar samma indexdefinition som i föregående exempel:
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"
När du skapar en indexerare med delimitedTextparsingMode kan det kännas naturligt att konfigurera en fältmappningsfunktion till nyckelfältet på följande sätt:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Den här mappningen resulterar dock inte i att fyra dokument visas i indexet eftersom fältet recordid inte är unikt för blobar. Därför rekommenderar vi att du använder den implicita fältmappning som tillämpas från AzureSearch_DocumentKey egenskapen till nyckelindexfältet för "en-till-många"-parsningslägen.
Om du vill konfigurera en explicit fältmappning kontrollerar du att sourceField är distinkt för varje enskild entitet i alla blobar.
Kommentar
Metoden som används för AzureSearch_DocumentKey att säkerställa unikhet per extraherad entitet kan komma att ändras och därför bör du inte förlita dig på dess värde för programmets behov.
Ange indexnyckelfältet i dina data
Anta att samma indexdefinition som föregående exempel och parsingMode är inställt på utan att jsonLines ange några explicita fältmappningar så att mappningarna ser ut som i det första exemplet, anta att blobcontainern har blobar med följande struktur:
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"
Observera att varje dokument innehåller fältet id , som definieras som fältet key i indexet. I sådana fall används det inte som "nyckel" för dokumentet, även om ett dokument som är unikt AzureSearch_DocumentKey genereras. I stället mappas värdet för id fältet till fältet key
På samma sätt som i föregående exempel resulterar den här mappningen inte i fyra dokument som visas i indexet eftersom fältet id inte är unikt för blobar. I så fall visar alla json-post som anger ett id resultat i en sammanslagning av det befintliga dokumentet i stället för en uppladdning av ett nytt dokument, och indexets tillstånd den senaste läsposten med angiven id.
Nästa steg
Om du inte redan är bekant med den grundläggande strukturen och arbetsflödet för blobindexering bör du först granska Indexering av Azure Blob Storage med Azure AI Search . Mer information om parsningslägen för olika typer av blobinnehåll finns i följande artiklar.