Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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
Una chiave del documento identifica in modo univoco ogni documento in un indice. 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 distinto. Elimina inoltre la necessità di creare manualmente questo mapping dei campi. In genere, i campi con nomi e tipi identici sono gli unici 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, Azure AI Search può generare una chiave di documento per ogni singola entità estratta da un BLOB. Il sistema genera una chiave denominata AzureSearch_DocumentKey e la aggiunge 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à).
| Documento d'identità | temperatura | pressione | Marca temporale |
|---|---|---|---|
| aHR0 ... YjEuanNvbjsx | 100 | 100 | 13 febbraio 2024, 00: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"
Ogni documento contiene il id campo, definito come key campo nell'indice. In questa situazione, il sistema genera un campo univoco AzureSearch_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theidfield is mapped to thekey.
Analogamente all'esempio precedente, questo mapping non comporta la visualizzazione di quattro documenti nell'indice perché il id campo non è univoco tra i BLOB. Quando si verifica questa situazione, qualsiasi voce JSON che specifica un oggetto id causa un merge con il documento esistente anziché caricarne uno nuovo. L'indice riflette quindi lo stato più recente della voce con l'oggetto specificato id.
Limitazioni
Quando viene creata una voce di documento nell'indice da una riga in un file, come illustrato in questo articolo, l'eliminazione di tale riga dal file non comporta la rimozione automatica della voce corrispondente dall'indice. Per eliminare la voce del documento, è necessario inviare manualmente una richiesta di eliminazione all'indice usando l'operazione di eliminazione dell'API REST.
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.