Indexación de blobs y archivos para producir varios documentos de búsqueda
Se aplica a: Indexadores de blobs Indexadores de archivos
De forma predeterminada, un indexador trata el contenido de un blob o archivo como un único documento de búsqueda. Si quiere una representación más granular en un índice de búsqueda, puede establecer valores de parsingMode para crear varios documentos de búsqueda desde un blob o un archivo. Los valores de parsingMode que dan como resultado varios documentos de búsqueda incluyen delimitedText (para CSV) y jsonArray o jsonLines (para JSON).
Cuando se usa cualquiera de estos modos de análisis, los nuevos documentos de búsqueda que surgen deben tener claves de documento únicas, y se produce un problema al determinar de dónde procede ese valor. El blob primario tiene al menos un valor único en forma de metadata_storage_path property, pero si aporta ese valor a más de un documento de búsqueda, la clave ya no es única en el índice.
Para solucionar este problema, el indexador de blobs genera AzureSearch_DocumentKey, que identifica de forma única cada documento de búsqueda secundario que se crea a partir del único elemento primario del blob. En este artículo se explica cómo funciona esta característica.
Clave de documento de uno a varios
Cada documento de un índice se identifica de forma única mediante una clave de documento. Si no se especifica ningún modo de análisis y no hay ninguna asignación de campos explícita en la definición del indexador para la clave del documento de búsqueda, el indexador de blobs asigna automáticamente metadata_storage_path property como clave del documento. Esta asignación predeterminada garantiza que cada blob aparezca como un documento de búsqueda distinto y le ahorrará el paso de tener que crear esta asignación de campos (normalmente, solo se asignan automáticamente los campos que tienen nombres y tipos idénticos).
En un escenario de documento de búsqueda uno a varios, no es posible una clave de documento implícita basada en metadata_storage_path property. Como solución alternativa, Búsqueda de Azure AI puede generar una clave de documento para cada entidad individual extraída de un blob. La clave generada se denomina AzureSearch_DocumentKey y se agrega a cada documento de búsqueda. El indexador realiza un seguimiento de los "muchos documentos" creados a partir de cada blob y puede dirigir las actualizaciones al índice de búsqueda cuando los datos de origen cambian con el tiempo.
De manera predeterminada, cuando no se especifica ninguna asignación de campo explícita para el campo de índice de la clave, se le asigna AzureSearch_DocumentKey mediante la función base64Encode de asignación de campos.
Ejemplo
Supongamos que hay una definición de índice con los siguientes campos:
idtemperaturepressuretimestamp
Y que el contenedor de blobs tiene blobs con la estructura siguiente:
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" }
Al crear un indexador y establecer el parsingMode en jsonLines, sin especificar asignaciones de campos explícitas para el campo de clave, la siguiente asignación se aplica implícitamente.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
Esta configuración da lugar a claves de documento sin ambigüedades, de forma similar a la siguiente ilustración (el identificador codificado en Base64 se ha abreviado para mayor brevedad).
| ID | temperatura | presión | 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 |
Asignación de campos personalizados para el campo de clave de índice
Adoptando la misma definición de índice que en el ejemplo anterior, supongamos que el contenedor de blobs tiene blobs con la estructura siguiente:
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"
Cuando se crea un indexador con parsingMode delimitedText, puede resultar natural configurar una función de asignación de campos para el campo de clave como se indica a continuación:
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
Sin embargo, esta asignación no tendrá como resultado cuatro documentos que se muestran en el índice, ya que el campo recordid no es único en los blobs. Por lo tanto, se recomienda hacer uso de la asignación de campos implícita que se aplica desde la propiedad AzureSearch_DocumentKey en el campo de índice de la clave para los modos de análisis de "uno a varios".
Si quiere configurar la asignación de campos explícita, asegúrese de que sourceField sea diferente para cada entidad individual entre todos los blobs.
Nota:
El enfoque usado por AzureSearch_DocumentKey para garantizar la unicidad por entidad extraída está sujeto a cambios y, por tanto, no debe confiar en su valor para las necesidades de la aplicación.
Especificación del campo de clave de índice en los datos
Asumiendo la misma definición de índice que el ejemplo anterior y parsingMode se establece en jsonLines sin especificar ninguna asignación de campos explícita, por lo que las asignaciones tienen un aspecto similar al del primer ejemplo, supongamos que el contenedor de blobs tiene blobs con la siguiente estructura:
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 contiene el campo id, que se define como el campo key en el índice. En tal caso, aunque se genere una AzureSearch_DocumentKey única para el documento, no se usará como "clave" para el documento. En su lugar, el valor del campo id se asignará al campo key
Al igual que en el ejemplo anterior, esta asignación no provocará que se muestren cuatro documentos en el índice, ya que el campo id no es único en los blobs. Cuando este es el caso, cualquier entrada JSON que especifique un id dará como resultado una combinación en el documento existente en lugar de una carga de un documento nuevo y el estado del índice reflejará la entrada de lectura más reciente con el id especificado.
Pasos siguientes
Si aún no está familiarizado con la estructura y el flujo de trabajo básicos de la indexación de blobs, lo primero que debería hacer sería consultar el artículo Indexación de Azure Blob Storage con Azure Search. Para más información sobre los modos de análisis de los distintos tipos de contenido de blobs, revise los artículos siguientes.