Indexando blobs e arquivos para produzir vários documentos de pesquisa

Aplica-se a: indexadores de blob, indexadores de arquivos (versão prévia)

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 parsingMode para criar vários documentos de pesquisa de um blob ou arquivo. Os valores de parsingMode que resultam em vários documentos de pesquisa incluem delimitedText (para CSV) jsonArray ou jsonLines (para JSON) ou markdown com o submodo oneToMany para markdown.

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 na determinação de de onde esse valor vem. O blob principal tem pelo menos um valor único na forma de metadata_storage_path property, mas se ele contribuir com esse valor para mais de um documento de busca, a chave deixará de ser única 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

Uma chave de documento identifica exclusivamente cada documento em um índice. Quando nenhum modo de análise é 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 mapeia automaticamente como metadata_storage_path property a chave do documento. Esse mapeamento padrão garante que cada blob apareça como um documento de pesquisa distinto. Ele também elimina a necessidade de você criar manualmente esse mapeamento de campo. Normalmente, campos com nomes e tipos idênticos são os únicos 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, o Pesquisa de IA do Azure  pode gerar uma chave de documento para cada entidade individual extraída de um blob. O sistema gera uma chave chamada AzureSearch_DocumentKey e a adiciona 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 é especificado, o AzureSearch_DocumentKey é mapeado para ele usando a função de mapeamento de campo base64Encode.

Example

Suponha uma definição de índice com os seguintes campos:

• id
• temperature
• pressure
• timestamp

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" }
}

Essa configuração resulta em chaves de documento desambiguadas, semelhantes à ilustração a seguir (ID codificada em base64 abreviada para brevidade).

Mapeamento de campo personalizado para o campo de chave de índice

Supondo a mesma definição de índice do exemplo anterior, suponha que o 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 de chave da seguinte maneira:

{
    "sourceFieldName" : "recordid",
    "targetFieldName": "id"
}

No entanto, esse mapeamento não faz com que quatro documentos apareçam no índice porque o campo não é exclusivo em todos os 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 é distinto para cada entidade individual em todos os blobs.

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" 

Cada documento contém o id campo, que é definido como o key campo no índice. Nessa situação, o sistema gera um campo de chave de for the document, but it isn't used as the "key." Instead, the value of theIDfield is mapped to the AzureSearch_DocumentKey exclusivo.

Semelhante ao exemplo anterior, esse mapeamento não faz com que quatro documentos apareçam no índice porque o id campo não é exclusivo entre os blobs. Quando essa situação ocorre, qualquer entrada JSON que especifica uma id causa uma mesclagem com o documento existente em vez de carregar uma nova. Então, o índice reflete o estado atual da entrada com o especificado id.

Limitações

Quando uma entrada de documento no índice é criada a partir de uma linha em um arquivo, conforme explicado neste artigo, excluir essa linha do arquivo não remove automaticamente a entrada correspondente do índice. Para excluir a entrada do documento, você deve enviar manualmente uma solicitação de exclusão para o índice usando a operação de exclusão da API REST.

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 Pesquisa de IA do Azure  . Para obter mais informações sobre modos de análise para diferentes tipos de conteúdo de blob, examine os artigos a seguir.