Indexação de blobs e arquivos para produzir vários documentos de pesquisa
Aplica-se a: Indexadores de Blob, Indexadores de arquivo
Por padrão, um indexador trata o conteúdo de um blob ou arquivo como um único documento de pesquisa. Se desejar uma representação mais granular em um índice de pesquisa, você pode definir valores parsingMode para criar vários documentos de pesquisa a partir de um blob ou arquivo. Os valores parsingMode que resultam em muitos documentos de pesquisa incluem delimitedText (para CSV) e jsonArray ou jsonLines (para JSON).
Quando você usa qualquer um desses modos de análise, os novos documentos de pesquisa que surgem devem ter chaves de documento exclusivas, e surge um problema para determinar de onde vem esse valor. O blob pai tem pelo menos um valor exclusivo na forma de , mas se ele contribuir com esse valor para mais de um documento de metadata_storage_path propertypesquisa, a chave não será mais exclusiva no índice.
Para resolver esse problema, o indexador de blob gera um AzureSearch_DocumentKey que identifica exclusivamente cada documento de pesquisa filho criado a partir do pai de blob único. Este artigo explica como esse recurso funciona.
Chave de documento um-para-muitos
Cada documento em um índice é identificado exclusivamente por uma chave de documento. Quando nenhum modo de análise é especificado e se não houver um mapeamento de campo explícito na definição do indexador para a chave do documento de pesquisa, o indexador de blob mapeia automaticamente a metadata_storage_path property chave como o documento. Esse mapeamento padrão garante que cada blob apareça como um documento de pesquisa distinto e economiza a etapa de ter que criar esse mapeamento de campo por conta própria (normalmente, apenas campos com nomes e tipos idênticos são mapeados automaticamente).
Em um cenário de documento de pesquisa um-para-muitos, uma chave de documento implícita com base em metadata_storage_path property não é possível. Como solução alternativa, o Azure AI Search pode gerar uma chave de documento para cada entidade individual extraída de um blob. A chave gerada é nomeada AzureSearch_DocumentKey e adicionada a cada documento de pesquisa. O indexador controla os "muitos documentos" criados a partir de cada blob e pode direcionar atualizações para o índice de pesquisa quando os dados de origem mudam ao longo do tempo.
Por padrão, quando nenhum mapeamento de campo explícito para o campo de índice de chave é especificado, o AzureSearch_DocumentKey é mapeado para ele, usando a base64Encode função de mapeamento de campo.
Exemplo
Suponha uma definição de índice com os seguintes campos:
idtemperaturepressuretimestamp
E seu contêiner de blob tem blobs com a seguinte estrutura:
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 você cria um indexador e define o parsingMode como jsonLines - sem especificar nenhum mapeamento de campo explícito para o campo chave, o mapeamento a seguir é aplicado implicitamente.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Essa configuração resulta em chaves de documento desambiguadas, semelhante à ilustração a seguir (ID codificado em base64 abreviado para brevidade).
| ID | temperatura | pressão | carimbo de data/hora |
|---|---|---|---|
| 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 |
Mapeamento de campo personalizado para campo de chave de índice
Supondo a mesma definição de índice do exemplo anterior, suponha que seu contêiner de blob tenha blobs com a seguinte estrutura:
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 você cria um indexador com delimitedTextparsingMode, pode parecer natural configurar uma função de mapeamento de campo para o campo chave da seguinte maneira:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
No entanto, esse mapeamento não resultará em quatro documentos aparecendo no índice porque o recordid campo não é exclusivo entre blobs. Portanto, recomendamos que você use o mapeamento de campo implícito aplicado da AzureSearch_DocumentKey propriedade ao campo de índice de chave para modos de análise "um-para-muitos".
Se você quiser configurar um mapeamento de campo explícito, certifique-se de que sourceField seja distinto para cada entidade individual em todos os blobs.
Nota
A abordagem usada para garantir a exclusividade por entidade extraída está sujeita a alterações e, portanto, você não deve confiar em seu valor para AzureSearch_DocumentKey as necessidades do seu aplicativo.
Especifique o campo de chave de índice em seus dados
Supondo que a mesma definição de índice do exemplo anterior e parsingMode esteja definida como jsonLines sem especificar nenhum mapeamento de campo explícito para que os mapeamentos pareçam com o primeiro exemplo, suponha que seu contêiner de blob tenha blobs com a seguinte estrutura:
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"
Observe que cada documento contém o campo, que é definido como o idkey campo no índice. Nesse caso, mesmo que um documento exclusivo AzureSearch_DocumentKey seja gerado, ele não será usado como a "chave" para o documento. Em vez disso, o id valor do campo será mapeado para o key campo
Semelhante ao exemplo anterior, esse mapeamento não resultará em quatro documentos aparecendo no índice porque o id campo não é exclusivo entre blobs. Quando esse for o caso, qualquer entrada json que especifique um resultará em uma mesclagem no documento existente em vez de um upload de um id novo documento, e o estado do índice refletirá a última entrada de leitura com o especificado id.
Próximos passos
Se você ainda não estiver familiarizado com a estrutura básica e o fluxo de trabalho da indexação de blobs, consulte Indexando o Armazenamento de Blobs do Azure com o Azure AI Search primeiro. Para obter mais informações sobre modos de análise para diferentes tipos de conteúdo de blob, revise os seguintes artigos.