Compartir a través de

Indexar conjuntos de datos de gran tamaño en Azure AI Search

  • Artículo

Si necesita indexar conjuntos de datos grandes o complejos en la solución de búsqueda, en este artículo se exploran las estrategias para dar cabida a procesos de larga duración en Búsqueda de Azure AI.

Estas estrategias asumen que está familiarizado con los dos enfoques básicos para la importación de datos: insertar datos en un índice o extraer datos de un origen de datos admitido mediante un indexador de búsqueda. Si el escenario implica un enriquecimiento con IA de cálculo intensivo, se requieren indizadores, dada la dependencia del conjunto de aptitudes de los indexadores.

Este artículo complementa a Sugerencias para mejorar el rendimiento en Azure Cognitive Search, que ofrece procedimientos recomendados para el diseño de índices y consultas. Un índice bien diseñado que incluye solo los campos y atributos que necesita es un requisito previo importante para la indexación a gran escala.

Se recomienda usar un servicio de búsqueda más reciente, creado después del 3 de abril de 2024, para almacenamiento superior por partición.

Nota:

Las estrategias descritas en este artículo dan por supuesto un único origen de datos de gran tamaño. Si la solución requiere la indexación de varios orígenes de datos, consulta Indexar varios orígenes de datos en Azure AI Search para conocer el enfoque recomendado.

Indexación de datos mediante las API de inserción

Las API de inserción, como la API de REST para indexar documentos o el método IndexDocuments (SDK de Azure para .NET), son la forma más frecuente de indexación en Búsqueda de Azure AI. En el caso de las soluciones que usan una API de inserción, la estrategia para la indexación de larga duración tiene uno o ambos de los siguientes componentes:

  • Procesamiento por lotes de documentos
  • Administración de subprocesos

Procesamiento por lotes de varios documentos por solicitud

Un mecanismo sencillo para indexar una gran cantidad de datos es enviar varios documentos o registros en una sola solicitud. Siempre y cuando la carga completa sea menor a 16 MB, una solicitud puede administrar hasta 1000 documentos en una operación de carga masiva. Estos límites se aplican tanto si usa la API REST para documentos Index como el método IndexDocuments del SDK de .NET. Con cualquier API, puede empaquetar 1000 documentos en el cuerpo de cada solicitud.

El procesamiento por lotes de documentos reduce significativamente la cantidad de tiempo que se tarda en trabajar con un gran volumen de datos. Determinar el tamaño de lote óptimo para los datos es un aspecto fundamental de la optimización de las velocidades de indexación. Los dos principales aspectos que influyen en el tamaño de lote óptimo son:

  • El esquema del índice
  • El tamaño de los datos

Dado que el tamaño de lote óptimo depende del índice y los datos, la mejor estrategia es probar distintos tamaños de lote para determinar cuál ofrece mayores velocidades de indexación en su caso. Para obtener código de ejemplo para probar los tamaños de lote mediante el SDK de .NET, consulte Tutorial: Optimización de la indexación con la API de inserción.

Administrar subprocesos y una estrategia de reintento

Los indexadores tienen administración de subprocesos integrada, pero cuando se usan las API de inserción, el código de la aplicación tiene que administrar los subprocesos. Asegúrese de que haya suficientes subprocesos para hacer un uso completo de la capacidad disponible, especialmente si ha aumentado recientemente las particiones o ha actualizado a un servicio de búsqueda de nivel superior.

  1. Aumente el número de subprocesos simultáneos en el código de cliente.

  2. A medida que aumenta las solicitudes que alcanzan el servicio de búsqueda, puede encontrarse con códigos de estado HTTP que indican que la solicitud no se completó correctamente. Durante la indexación, dos de los códigos de estado HTTP comunes son:

    • Servicio 503 No disponible: este error significa que el sistema está bajo carga pesada y la solicitud no se puede procesar en este momento.

    • Estado múltiple 207: este error significa que algunos documentos se realizaron correctamente, pero al menos un error.

  3. Para controlar los errores, las solicitudes deberán reintentarse mediante una estrategia de reintento de retroceso exponencial.

El SDK de .NET de Azure reintenta automáticamente las solicitudes 503 y otras solicitudes con errores, pero debe implementar su propia lógica para reintentar las solicitudes 207. También se pueden usar herramientas de código abierto como Polly para implementar una estrategia de reintento.

Uso de indizadores y de las API de extracción

Los indexadores tienen varias funcionalidades que son útiles para los procesos de larga duración:

  • Procesamiento por lotes de documentos
  • Indexación en paralelo sobre datos con particiones
  • Programación y detección de cambios para la indexación de documentos nuevos y modificados a lo largo del tiempo

La programaciones de los indexadores pueden reanudar el procesamiento en el último punto de detención conocido. Si los datos no se indexan completamente en la ventana de procesamiento, el indexador los recoge donde quedaron en la siguiente ejecución, suponiendo que use un origen de datos que proporcione detección de cambios.

Particionar los datos en orígenes de datos individuales más pequeños permite realizar procesamientos en paralelo. Puede dividir los datos de origen, por ejemplo, en varios contenedores en Azure Blob Storage, crear un origen de datos para cada partición y, a continuación, ejecutar los indexadores en paralelo, sujeto al número de unidades de búsqueda del servicio de búsqueda.

Comprobación del tamaño del lote del indexador

Al igual que con la API de inserciones, los indizadores permiten configurar el número de elementos por lote. Para los indizadores basados en la API REST para crear indizadores, puede establecer el argumento batchSize para personalizar esta configuración de modo que se adapte mejor a las características de los datos.

Los tamaños de lote predeterminados son específicos para cada origen de datos. Azure SQL Database y Azure Cosmos DB tienen un tamaño de lote predeterminado de 1000. Por el contrario, la indexación de Azure Blob establece el tamaño de lote en 10 documentos en atención al tamaño máximo medio de los documentos.

Programación de indexadores para procesos de ejecución prolongada

La programación de indexadores es un mecanismo importante para procesar conjuntos de datos de gran tamaño para acomodar procesos de ejecución lenta, como el análisis de imágenes en una canalización de enriquecimiento.

Normalmente, el indexador que realiza el procesamiento se ejecuta en un período de dos horas. Si la carga de trabajo de indexación tarda días, en lugar de horas, en completarse, el indexador se puede colocar en una programación periódica consecutiva que se inicia cada dos horas. Suponiendo que el origen de datos tenga habilitado el seguimiento de cambios, el indexador reanuda el procesamiento en el lugar en que lo dejó. Con esta cadencia, un indexador puede abrirse camino a través del trabajo pendiente de un documento a lo largo de varios días hasta procesar todos los documentos no procesados.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Cuando deje de haber documentos nuevos o actualizados en el origen de datos, el historial de ejecución del indexador notificará que hay 0/0 documentos procesados y no se producirá ningún procesamiento.

Para obtener más información sobre cómo configurar las programaciones, consulte Crear indexadores para la API de REST o Programar indexadores para la Búsqueda de Azure AI.

Nota:

Algunos indexadores que se ejecutan en una arquitectura en tiempo de ejecución anterior tienen un periodo de procesamiento máximo de 24 horas, en lugar de 2 horas. El límite de dos horas es para procesadores de contenido más recientes que se ejecutan en un entorno multiinquilino administrado internamente. Siempre que sea posible, Azure AI Search va a intentar descargar el indexador y el procesamiento del conjunto de aptitudes en el entorno multiinquilino. Si el indexador no se puede migrar, se ejecuta en el entorno privado y durante un máximo de 24 horas. Si programará un indexador que tiene estas características, de por hecho que el periodo de procesamiento será de 24 horas.

Ejecución de indexadores en paralelo

Si realiza particiones en los datos, puede crear varias combinaciones de orígenes de datos de indexadores que extraigan de cada origen de datos y escriban en el mismo índice de búsqueda. Como cada indexador es distinto, puede ejecutarlos al mismo tiempo y, de esta forma, rellenar un índice de búsqueda más rápidamente que si los ejecutara de forma secuencial.

Asegúrese de tener capacidad suficiente. Una unidad de búsqueda del servicio puede ejecutar un indexador en cualquier momento dado. La creación de varios indexadores solo es útil si se pueden ejecutar en paralelo.

El número de trabajos de indexación que se pueden ejecutar simultáneamente varía para la indexación basada en texto y basada en aptitudes. Para más información, consulte Ejecución de indizadores.

Si el origen de datos es un contenedor de Azure Blob Storage o Azure Data Lake Storage Gen 2, la enumeración de un número elevado de blobs puede tardar mucho tiempo (incluso horas) hasta que la operación se complete, Como resultado, el recuento correcto de documentos del indexador no parece aumentar durante ese tiempo y puede parecer que no está progresando, cuando sí lo hace. Si desea que el procesamiento de documentos sea más rápido para un número elevado de blobs, considere la posibilidad de crear particiones de datos en varios contenedores y crear indexadores paralelos que apunten a un único índice.

  1. Inicia sesión en Azure Portal y comprueba el número de unidades de búsqueda que usa el servicio de búsqueda. Seleccione Configuración>Escala para ver el número en la parte superior de la página. El número de indexadores que se ejecuta en paralelo es aproximadamente igual al número de unidades de búsqueda.

  2. Cree particiones de los datos de origen en varios contenedores o varias carpetas virtuales dentro del mismo contenedor.

  3. Cree varios orígenes de datos, uno para cada partición, emparejados con su propio indexador.

  4. Especifique el mismo índice de búsqueda de destino en cada indexador.

  5. Programe los indexadores.

  6. Revise el estado del indexador y el historial de ejecución para confirmar.

Hay algunos riesgos asociados a la indexación en paralelo. En primer lugar, recuerde que la indexación no se ejecuta en segundo plano, lo que aumenta la probabilidad de limitación o anulación de las consultas.

En segundo lugar, Azure AI Search no bloquea las actualizaciones del índice. Se administran las escrituras simultáneas y se invoca un reintento si alguna escritura concreta no se realiza correctamente en el primer intento; no obstante, es posible que observe un aumento en los errores de indexación.

Aunque varios conjuntos de orígenes de datos de indexador pueden tener como destino el mismo índice, tenga cuidado con las ejecuciones del indexador que puedan sobrescribir los valores existentes en el índice. Si un segundo origen de datos de indexador tiene como destino los mismos documentos y campos, se sobrescriben los valores de la primera ejecución. Los valores de campo se reemplazan por completo; un indexador no puede combinar valores de varias ejecuciones en el mismo campo.

Indexación de macrodatos en Spark

Si tiene una arquitectura de macrodatos y los datos están en un clúster de Spark, se recomienda consultar Tutorial: Indexación de datos de gran tamaño de Apache Spark mediante SynapseML y Cognitive Search. El tutorial incluye pasos para llamar a los servicios de Azure AI para el enriquecimiento con IA, pero también puedes usar la API AzureSearchWriter para la indexar texto.

Contenido relacionado