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:

• id
• temperature
• pressure
• timestamp

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 delimitedText parsingMode 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

Den metod 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, även om ett dokument som är unikt AzureSearch_DocumentKey genereras, kommer det inte att användas som "nyckel" för dokumentet. 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. När så är fallet resulterar json-post som anger en id i ett sammanslagning av det befintliga dokumentet i stället för en uppladdning av ett nytt dokument, och indexets tillstånd återspeglar 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.

Indexera CSV-blobarIndexera JSON-blobar