Indexar conjuntos de datos de gran tamaño en Búsqueda de Azure AI

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, 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.

Use un servicio de búsqueda creado después del 3 de abril de 2024 para un almacenamiento mayor por partición. También puede actualizar los servicios más antiguos para beneficiarse de un almacenamiento de particiones mayor.

Indexa datos mediante las API de envío

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 hilos

Agrupar varios documentos en cada 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 tus 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 hay suficientes subprocesos para hacer uso completo de la capacidad disponible, especialmente si ha actualizado recientemente el servicio, ha cambiado a un plan de tarifa superior o a particiones mayores.

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

2. A medida que aumente las solicitudes que impactan al servicio de búsqueda, puede encontrarse con códigos de estado HTTP que indican que la solicitud no tuvo éxito completo. 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 ofrecen varias funcionalidades útiles para procesos de ejecución prolongada:

• 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 dentro de la ventana de procesamiento, el indexador recoge donde se quede en la siguiente ejecución, suponiendo que usa un origen de datos que proporciona 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. En el caso de los indexadores basados en la API REST Create Indexer, establezca el batchSize argumento para personalizar esta configuración para que coincida mejor con 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. En cambio, la indización de Azure Blob y SharePoint (versión preliminar) establece el tamaño del lote en 10 documentos, dado el mayor tamaño medio de los documentos.

Programar indexadores para procesos de larga duración

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 procesamiento del indexador 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 recorrer la acumulación de documentos a lo largo de varios días hasta procesar todos los documentos pendientes. Este patrón es especialmente importante durante la ejecución inicial o al indexar contenedores de blobs grandes, donde la fase de enumeración de blobs solo puede tardar varias horas o días. Durante este tiempo, el indexador no muestra ningún blob en proceso, pero, a menos que se notifique un error, es probable que siga iterando por la lista de blobs. El procesamiento de documentos y el enriquecimiento comienzan solo una vez completada esta fase y se espera este comportamiento.

{
    "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.

Si tu indexador utiliza un conjunto de habilidades con almacenamiento en caché de enriquecimiento, revisa la siguiente información antes de habilitar la caché para cargas de trabajo a gran escala.

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. Dado que cada indexador es distinto, puede ejecutarlos al mismo tiempo, por lo que rellenará un índice de búsqueda más rápidamente que si los ejecutó secuencialmente.

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 de documentos correctos de su indexador no parece aumentar durante ese tiempo y puede parecer que no está avanzando, aunque sí lo está haciendo. Si desea que el procesamiento de documentos sea más rápido para un gran número de blobs, considere la posibilidad de crear particiones de los datos en varios contenedores y crear indexadores paralelos que apunte a un único índice.

1. Vaya al servicio de búsqueda en Azure Portal.

2. Compruebe el número de unidades de búsqueda usadas por 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.

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

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

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

6. Programe los indexadores.

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

Hay algunos riesgos asociados a la indexación en paralelo. Primero, tenga en cuenta que la indexación no se ejecuta en segundo plano, lo que aumenta la probabilidad de que las consultas se limiten o se descarten.

En segundo lugar, Búsqueda de Azure AI no bloquea las actualizaciones del índice. Las escrituras simultáneas se administran invocando un reintento si una escritura determinada no se realiza correctamente en el primer intento, pero puede observar 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, use SynapseML para cargar e indexar datos. En el tutorial se incluyen los pasos para llamar a Foundry Tools para el enriquecimiento con IA, pero también puede usar AzureSearchWriter API para la indexación de texto.

Contenido relacionado

• Tutorial: Optimización de la indexación mediante la API de inserción
• Tutorial: Indexación de datos de gran tamaño de Apache Spark mediante SynapseML y Búsqueda de Azure AI
• Sugerencias para mejorar el rendimiento en la Búsqueda de Azure AI
• Análisis del rendimiento en Búsqueda de Azure AI
• Indexadores en Búsqueda de Azure AI
• Supervisar el estado y los resultados del indexador en la Búsqueda de Azure AI