Indicizzazione di BLOB e file per produrre più documenti di ricerca
Si applica a: Indicizzatori BLOB, Indicizzatori file
Per impostazione predefinita, un indicizzatore considera il contenuto di un BLOB o di un file come singolo documento di ricerca. Se si desidera ottenere una rappresentazione più granulare in un indice di ricerca, è possibile impostare i valori parsingMode per creare più documenti di ricerca da un BLOB o da un file. I valori parsingMode che generano molti documenti di ricerca includono delimitedText (per CSV) e jsonArray o jsonLines (per JSON).
Quando si usa una di queste modalità di analisi, i nuovi documenti di ricerca che emergono devono avere chiavi di documento univoche e si verifica un problema nel determinare la provenienza di tale valore. Il BLOB padre ha almeno un valore univoco sotto forma di metadata_storage_path property, ma se contribuisce a tale valore per più documenti di ricerca, la chiave non è più univoca nell'indice.
Per risolvere questo problema, l'indicizzatore BLOB genera un oggetto AzureSearch_DocumentKey che identifica in modo univoco ogni documento di ricerca figlio creato dal singolo elemento padre BLOB. Questo articolo illustra il funzionamento di questa funzionalità.
Chiave documento uno-a-molti
Ogni documento in un indice viene identificato in modo univoco da una chiave del documento. Se non viene specificata alcuna modalità di analisi e se non è presente alcun mapping dei campi esplicito nella definizione dell'indicizzatore per la chiave del documento di ricerca, l'indicizzatore BLOB esegue automaticamente il mapping di metadata_storage_path property come chiave del documento. Questo mapping predefinito garantisce che ogni BLOB venga visualizzato come documento di ricerca separato e consente di risparmiare il passaggio di dover creare manualmente questo mapping dei campi (in genere il mapping automatico avviene solo i campi con nomi e tipi identici).
In uno scenario di documento di ricerca uno-a-molti, non è possibile usare una chiave di documento implicita basata su metadata_storage_path property. Come soluzione alternativa, Azure AI Search può generare una chiave di documento per ogni singola entità estratta da un BLOB. La chiave generata è denominata AzureSearch_DocumentKey e viene aggiunta a ogni documento di ricerca. L'indicizzatore tiene traccia dei "molti documenti" creati da ciascun BLOB e può destinare gli aggiornamenti all'indice di ricerca quando i dati di origine cambiano nel tempo.
Per impostazione predefinita, quando non vengono specificati mapping dei campi espliciti per il campo dell'indice della chiave, viene eseguito il mapping dell'oggetto AzureSearch_DocumentKey usando la funzione di mapping dei campi base64Encode.
Esempio
Si supponga una definizione di indice con i campi seguenti:
idtemperaturepressuretimestamp
Il contenitore BLOB include BLOB con la struttura seguente:
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" }
Quando si crea un indicizzatore e si imposta parsingMode per jsonLines, senza specificare un mapping dei campi esplicito per il campo chiave, viene applicato in modo implicito il mapping seguente.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Questa configurazione comporta la disambiguazione delle chiavi del documento, similmente alla figura seguente (ID base64-encoded abbreviato per brevità).
| ID | temperatura | pressione | 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 |
Mapping dei campi personalizzato per il campo chiave di indice
Presumendo la stessa definizione di indice dell'esempio precedente, si supponga che il contenitore BLOB abbia BLOB con la struttura seguente:
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"
Quando si crea un indicizzatore con delimitedTextparsingMode, potrebbe essere naturale configurare una funzione di mapping dei campi per il campo chiave come indicato di seguito:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Tuttavia, questo mapping non comporta la visualizzazione di quattro documenti nell'indice perché il recordid campo non è univoco tra i BLOB. Quindi per le modalità di analisi "uno-a-molti", è consigliabile usare il mapping dei campi implicito applicato dalla proprietà AzureSearch_DocumentKey per il campo dell'indice della chiave.
Se si vuole configurare un mapping dei campi esplicito, assicurarsi che sourceField sia distinto per ciascuna singola entità in tutti i BLOB.
Nota
L'approccio usato per AzureSearch_DocumentKey garantire l'univocità per ogni entità estratta è soggetto a modifiche e pertanto non è consigliabile basarsi sul relativo valore per le esigenze dell'applicazione.
Specificare il campo chiave di indice nei dati
Presumendo la stessa definizione di indice dell'esempio precedente con parsingMode impostato su jsonLines senza specificare un mapping dei campi esplicito così che i mapping siano come nel primo esempio, si supponga che il contenitore BLOB abbia i BLOB con la struttura seguente:
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"
Si noti che ogni documento contiene il campo id, definito nell’indice come campo key. In questo caso, anche se viene generato un documento univoco AzureSearch_DocumentKey , non viene usato come "chiave" per il documento. Il valore del id campo viene invece mappato al key campo
Analogamente all'esempio precedente, questo mapping non comporta la visualizzazione di quattro documenti nell'indice perché il id campo non è univoco tra i BLOB. In questo caso, qualsiasi voce JSON che specifica un id risultato in un merge nel documento esistente anziché un caricamento di un nuovo documento e lo stato dell'indice riflette la voce di lettura più recente con l'oggetto specificato id.
Passaggi successivi
Se non si ha familiarità con la struttura di base e il flusso di lavoro dell'indicizzazione BLOB, è necessario rivedere prima Indicizzazione di Archiviazione BLOB di Azure con Azure AI Search. Per altre informazioni sulle modalità di analisi per i diversi tipi di contenuto BLOB, vedere gli articoli seguenti.