Como indexar blobs e arquivos para produzir vários documentos de pesquisa
Aplica-se a: Indexadores de blobs, Indexares de arquivos
Por padrão, um indexador trata o conteúdo de um blob ou arquivo como um único documento de pesquisa. Se você quiser uma representação mais granular em um índice de pesquisa, poderá definir valores de parsingMode para criar vários documentos de pesquisa por meio de um blob ou arquivo. Os valores de 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 precisam ter chaves de documento exclusivas e um problema surge na determinação do local de origem desse valor. O blob pai tem pelo menos um valor exclusivo na forma de metadata_storage_path property, mas se ele contribuir com esse valor em mais de um documento de pesquisa, 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 por um blob pai. Este artigo explica como esse recurso funciona.
Chave de documento de um para muitos
Cada documento em um índice é identificado exclusivamente por uma chave de documento. Quando nenhum modo de análise for especificado e se não houver nenhum mapeamento de campo explícito na definição do indexador para a chave do documento de pesquisa, o indexador de blob mapeará automaticamente o metadata_storage_path property como a chave do documento. Este mapeamento padrão garante que cada blob apareça como um documento de pesquisa distinto e poupa de você 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 baseada em metadata_storage_path property não é possível. Como alternativa, a Pesquisa de IA do Azure pode gerar uma chave de documento para cada entidade individual extraída de um blob. A chave gerada é denominada 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 são alterados ao longo do tempo.
Por padrão, quando nenhum mapeamento de campo explícito para o campo de índice de chave for especificado, o AzureSearch_DocumentKey será mapeado para ele, usando a função de mapeamento de campo base64Encode.
Exemplo
Suponha uma definição de índice com os seguintes campos:
idtemperaturepressuretimestamp
E o seu contêiner de blobs 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 de chave, o mapeamento a seguir é aplicado implicitamente.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Esta configuração resulta em chaves de documento desambiguadas, semelhantes à ilustração a seguir (ID codificada em base64 abreviada para brevidade).
| ID | temperatura | pressão | 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 |
Mapeamento de campo personalizado do campo de chave de índice
Considerando que o índice tenha a mesma definição do exemplo anterior, suponha que o seu contêiner de blobs 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 de chave da seguinte forma:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
No entanto, esse mapeamento não resultará em quatro documentos aparecendo no índice porque o campo recordid não é exclusivo entre blobs. Portanto, é recomendável que você use o mapeamento de campo implícito aplicado da propriedade AzureSearch_DocumentKey para o campo de índice de chave nos modos de análise "um para muitos".
Se você quiser configurar um mapeamento de campo explícito, verifique se o sourceField é diferente para cada entidade individual em todos os blobs.
Observação
A abordagem usada pelo AzureSearch_DocumentKey de assegurar a exclusividade por entidade extraída está sujeita a alterações e, portanto, você não deve depender do valor dela para as necessidades do seu aplicativo.
Especificar o campo de chave de índice em seus dados
Supondo que a mesma definição de índice do exemplo anterior e parsingMode seja definido jsonLines sem especificar nenhum mapeamento de campo explícito para que os mapeamentos se 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 id, que é definido como o campo key 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 valor do campo id será mapeado para o campo key
Semelhante ao exemplo anterior, esse mapeamento não resultará em quatro documentos aparecendo no índice porque o campo id não é exclusivo entre blobs. Quando esse for o caso, qualquer entrada json que especificar um id resultará em uma mesclagem no documento existente em vez de um upload de um novo documento, e o estado do índice refletirá a entrada de leitura mais recente com o id especificado.
Próximas etapas
Se você ainda não estiver familiarizado com a estrutura básica e o fluxo de trabalho da indexação de blobs, examine primeiro a Indexação do Armazenamento de Blobs do Azure com o Azure AI Search. Para obter mais informações sobre os modos de análise de diferentes tipos de conteúdo de blob, examine os artigos a seguir.