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 un singolo documento di ricerca. Se si vuole 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 per determinare da dove proviene tale valore. Il BLOB padre ha almeno un valore univoco sotto forma di metadata_storage_path property, ma se contribuisce a tale valore a 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 è identificato in modo univoco da una chiave del documento. Quando non viene specificata alcuna modalità di analisi e se non è presente alcun mapping esplicito dei campi nella definizione dell'indicizzatore per la chiave del documento di ricerca, l'indicizzatore BLOB esegue automaticamente il metadata_storage_path property mapping come chiave del documento. Questo mapping predefinito garantisce che ogni BLOB venga visualizzato come documento di ricerca distinto e consente di risparmiare il passaggio di dover creare manualmente questo mapping dei campi (in genere solo i campi con nomi e tipi identici vengono mappati automaticamente).
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, Ricerca intelligenza artificiale di Azure 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 ogni BLOB e può indirizzare gli aggiornamenti all'indice di ricerca quando i dati di origine cambiano nel tempo.
Per impostazione predefinita, quando non vengono specificati mapping di campi espliciti per il campo dell'indice della chiave, viene eseguito il mapping dell'oggetto AzureSearch_DocumentKey usando la funzione di mapping dei base64Encode campi.
Esempio
Si supponga che 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 su jsonLines , senza specificare mapping di campi espliciti per il campo chiave, il mapping seguente viene applicato in modo implicito.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Questa configurazione comporta la disambiguazione delle chiavi del documento, simile alla figura seguente (ID con codifica base64 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
Supponendo che 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 nel campo chiave come indicato di seguito:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Tuttavia, questo mapping non comporterà la visualizzazione di quattro documenti nell'indice perché il recordid campo non è univoco tra i BLOB. È quindi consigliabile usare il mapping implicito dei campi applicato dalla AzureSearch_DocumentKey proprietà al campo dell'indice della chiave per le modalità di analisi "uno-a-molti".
Se si vuole configurare un mapping di campo esplicito, assicurarsi che sourceField sia distinto per ogni 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 valore per le esigenze dell'applicazione.
Specificare il campo chiave di indice nei dati
Supponendo che la stessa definizione di indice dell'esempio precedente e parsingMode sia impostata su jsonLines senza specificare alcun mapping di campo esplicito in modo che i mapping siano simili al primo esempio, si supponga che il contenitore BLOB abbia 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 id campo , definito come key campo nell'indice. In questo caso, anche se verrà generato un documento univoco AzureSearch_DocumentKey , non verrà usato come "chiave" per il documento. Il valore del id campo verrà invece mappato al key campo
Analogamente all'esempio precedente, questo mapping non comporterà 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 oggetto genererà un'unione nel documento esistente anziché un caricamento di un nuovo documento e lo stato dell'indice rifletterà la voce di lettura più recente con l'oggetto specificato id.
Passaggi successivi
Se non si ha già familiarità con la struttura di base e il flusso di lavoro dell'indicizzazione BLOB, è necessario esaminare prima indicizzazione Archiviazione BLOB di Azure con Ricerca di intelligenza artificiale di Azure. Per altre informazioni sulle modalità di analisi per diversi tipi di contenuto BLOB, vedere gli articoli seguenti.