Compartir a través de

Optimización del rendimiento de las operaciones masivas

Cuando necesite crear o actualizar miles o millones de registros en Dataverse, las opciones que realice pueden ahorrar horas de tiempo para que se complete el proyecto de operación masiva. En este artículo se describen los factores que afectan al rendimiento y las opciones que tiene que crear aplicaciones cliente que optimicen el rendimiento para las operaciones masivas. También se debe tener en cuenta otros factores, como el número de registros, el tamaño del registro, la latencia de red y la complejidad de los datos.

Tipo de tabla

El tipo de tabla que elige para almacenar sus datos tiene el mayor impacto en el rendimiento que puede esperar de las operaciones masivas. Dataverse ofrece dos tipos de tablas: estándar y elástica.

  • Una tabla estándar almacena datos mediante Azure SQL. Las tablas estándar proporcionan compatibilidad con transacciones y mayores funcionalidades para modelar relaciones.
  • Una tabla elástica almacena datos mediante Azure Cosmos DB. Las tablas elásticas se escalan horizontalmente para controlar grandes cantidades de datos y altos niveles de rendimiento con baja latencia. Las tablas elásticas son adecuadas para aplicaciones con cargas de trabajo impredecibles, puntiagudas o de rápido crecimiento.

Si los tiempos de carga de datos son su principal preocupación, las tablas elásticas proporcionan el mejor rendimiento. Más información sobre cuándo usar tablas elásticas

Lógica de negocios

Dataverse proporciona la capacidad de agregar lógica de negocios adicional cuando se crean o actualizan registros mediante complementos. Los complementos se pueden registrar para que se ejecuten de forma sincrónica antes o dentro de la transacción de una operación de tabla estándar. Las tablas elásticas admiten complementos que se pueden ejecutar antes de que se inicie una operación porque no hay ninguna transacción. Cualquier error que se produzca en el código del complemento durante un paso sincrónico para una tabla estándar, o antes de la operación en una tabla elástica, cancela la operación. Un desarrollador de complementos puede iniciar deliberadamente una excepción para cancelar la operación para asegurarse de que se aplica la lógica de validación de datos.

Cualquier complemento registrado para ejecutarse sincrónicamente aumenta el tiempo para que se complete la operación. Para conservar el rendimiento:

  • Limite el número de complementos sincrónicos registrados para las operaciones. Agregue lógica para ejecutarse de forma asincrónica mediante un complemento asincrónico o un flujo de Power Automate, a menos que sea esencial que la lógica se aplique de forma sincrónica.
  • Asegúrese de que los complementos que tiene están limitados en la lógica que intentan realizar. Aunque los complementos deben completarse dentro de un generoso límite de tiempo de 2 minutos, los complementos síncronos que tarden más de dos segundos en ejecutarse afectan seriamente al rendimiento.
  • Asegúrese de que los complementos solo se ejecutan cuando sea necesario. Los complementos para las operaciones de actualización se pueden filtrar para ejecutarse solo cuando se actualizan columnas específicas.
  • Asegúrese de que los complementos están optimizados para realizar la lógica lo más eficaz posible. En el caso de las tablas estándar, debe tener en cuenta el impacto que pueden tener las transacciones y los bloqueos de registro en el rendimiento. Más información sobre el diseño de personalización escalable y otros procedimientos recomendados para escribir complementos
  • Elija en qué API registrar su complemento. Puede aplicar lógica síncrona para ejecutarse en las API de operaciones masivas más eficientes CreateMultiple y UpdateMultiple. Más información acerca de cómo escribir complementos para CreateMultiple y UpdateMultiple.

Omitir la lógica de negocios

Para acelerar el proyecto de operación masiva, puede deshabilitar los complementos registrados para las operaciones de creación o actualización para mejorar el rendimiento. Si la lógica de negocios no es esencial, o si planea otros pasos para garantizar la coherencia final de los datos, puede deshabilitar manualmente los pasos del complemento y volver a habilitarlos cuando se complete el proyecto de operación masiva. Sin embargo, deshabilitar los complementos impide que se aplique la lógica desde cualquier cliente. Cualquier usuario u otro proceso que agregue datos a Dataverse durante este período no tendrá ninguna de las lógicas de negocios aplicadas.

Como desarrollador de una aplicación cliente que realiza la operación masiva, puede aplicar un parámetro opcional a las solicitudes que envíe para omitir la lógica. Solo un administrador del sistema o los usuarios a los que se les ha concedido un privilegio específico pueden usar este encabezado. Obtenga más información sobre cómo omitir la lógica personalizada de Dataverse.

API de operaciones en bloque

Dataverse proporciona API de operación masiva que permiten el mayor rendimiento posible para crear y actualizar operaciones. Estas API incluyen CreateMultiple, UpdateMultipley UpsertMultiple. Para las tablas elásticas solo, puede usar el mensaje DeleteMultiple.

Aunque estas API proporcionan el mayor rendimiento, tienen las siguientes limitaciones para las tablas estándar:

  • Actualmente no está disponible para todas las tablas. Cualquier tabla personalizada debe admitirlas, pero no todas las tablas principales de Dataverse las admiten, como Cuenta o Contacto. Puede ejecutar una consulta proporcionada en la documentación para determinar si una tabla puede usar estas API.
  • No perdona los errores de datos. Debe asegurarse de que los datos que está cambiando se depuran y validan cuidadosamente. Cualquier error que se produzca dentro de una operación en estas API hace que se produzca un error en toda la operación.
  • No se admite para usar complementos. Actualmente, las aplicaciones cliente externas solo deben usar estas API.

Las operaciones masivas están disponibles para todas las tablas elásticas y las tablas elásticas pueden devolver información sobre operaciones individuales que fallan. Obtenga más información sobre las operaciones masivas con tablas elásticas.

APIs por lotes

Si no puede usar api de operación masiva, con el SDK para .NET puede usar ExecuteMultiple y con la API web puede usar OData $batch.

Use estas API para agrupar un conjunto de operaciones en una sola solicitud y lograr una mayor eficacia principalmente debido a menos solicitudes más grandes, lo que reduce la carga total enviada y recibida a través de la conexión para cada operación. Una aplicación cliente no necesita esperar a que finalice una operación antes de enviar la siguiente solicitud.

Cada operación dentro de la solicitud se aplica secuencialmente en el servidor, por lo que no hay ninguna eficacia mejorada por operación. Sin embargo, dado que las operaciones se realizan individualmente, puede obtener información sobre qué operaciones han fallado o detener el lote cuando se produce un error. Puede enviar hasta 1000 operaciones por solicitud, pero para obtener los mejores resultados, se recomienda empezar con un número menor y experimentar para determinar qué tamaño funciona mejor por lotes para su caso.

Nota:

Tanto la operación masiva como las API por lotes ven importantes mejoras de rendimiento cuando se usan en paralelo. Consulte Solicitudes paralelas.

Arquitectura de cliente

Dataverse está diseñado como origen de datos para admitir varias aplicaciones con un gran número de usuarios simultáneos. Para optimizar el rendimiento, diseñe el cliente para usar los puntos fuertes de Dataverse.

Los cuellos de botella en el código del lado del cliente son la causa principal de los problemas de rendimiento. Con frecuencia, los desarrolladores no pueden usar completamente las funcionalidades del código, lo que puede afectar al rendimiento. Es fundamental optimizar la forma en que la aplicación cliente utiliza los núcleos o el proceso de la infraestructura, ya que un error al optimizar puede afectar significativamente al rendimiento. Por ejemplo, al usar Azure Functions, hay varios pasos que se pueden realizar para optimizar el rendimiento, como implementar el escalado automático, usar instancias de preparación, ajustar el uso de CPU, usar varios núcleos y permitir la simultaneidad.

Límites de protección de servicio

Para garantizar una disponibilidad y un rendimiento coherentes para todos los usuarios, Dataverse aplica algunos límites a cómo se usan las API. Estos límites están diseñados para detectar cuándo las aplicaciones cliente realizan demandas extraordinarias en los recursos del servidor. Los proyectos de operaciones a gran escala siempre exigen demandas extraordinarias, por lo que debe estar preparado para gestionar los errores debidos a los límites de protección del servicio. Si no recibe algunos errores de límite de protección del servicio, no ha maximizado la capacidad de su aplicación.

Los errores de límite de protección de servicio son solo otro tipo de error transitorio que el cliente debe estar preparado para controlar, como una pérdida temporal de conectividad de red. Una aplicación cliente resistente debe responder al error esperando y reintentando. La única diferencia es que los límites de protección del servicio indican cuánto tiempo debe esperar antes de volver a intentarlo.

Lea estos artículos para obtener más información:

Solicitudes paralelas

Puede ver una mejora significativa del rendimiento mediante el envío de solicitudes en paralelo, pero debe comprender cómo enviarlos correctamente.

No todos los entornos son los mismos

No todos los entornos de Dataverse tienen el mismo número de recursos de servidor web asignados. Dataverse escala a las necesidades del entorno al agregar más recursos de servidores web para admitirlo. Un entorno de producción que admita miles de usuarios activos requiere más servidores web que un entorno de prueba. Cuando el entorno tiene una gran cantidad de servidores web, el envío de solicitudes en paralelo puede marcar una diferencia dramática en el rendimiento total que puede lograr la aplicación cliente.

Dataverse devuelve datos en un encabezado de respuesta que indica un grado recomendado de paralelización (DOP) para su entorno. El rendimiento empeora si envía más solicitudes paralelas que el encabezado de respuesta recomienda. Es posible que el hardware cliente que use para ejecutar la aplicación necesite más núcleos de CPU para enviar estas muchas solicitudes en paralelo. Es posible que tenga que usar más clientes para obtener el rendimiento máximo. Por ejemplo, puede usar un App Service escalado horizontalmente o una función de Azure.

En función de la arquitectura del lado cliente, es posible que tenga que dividir el grado recomendado de paralelismo. Por ejemplo, cuando tiene dos clientes y el DOP recomendado es 50; configure cada cliente para que use 25.

Deshabilitar la afinidad de Azure

Cuando corresponda, puede ver los mejores resultados al configurar el cliente para que use todos los servidores web disponibles quitando la cookie de afinidad de Azure que intenta asociar la aplicación a un único servidor web. Deshabilitar la afinidad de Azure no es adecuada para las aplicaciones interactivas que usan datos almacenados en caché desde el servidor para optimizar la experiencia del usuario.

Optimización de la conexión

Al usar .NET, debe aplicar cambios de configuración como los siguientes para optimizar la conexión, por lo que las solicitudes no están limitadas por la configuración predeterminada.

// Bump up the min threads reserved for this app to ramp connections faster - minWorkerThreads defaults to 4, minIOCP defaults to 4 
ThreadPool.SetMinThreads(100, 100);
// Change max connections from .NET to a remote service default: 2
System.Net.ServicePointManager.DefaultConnectionLimit = 65000;
// Turn off the Expect 100 to continue message - 'true' will cause the caller to wait until it round-trip confirms a connection to the server 
System.Net.ServicePointManager.Expect100Continue = false;
// Can decrease overall transmission overhead but can cause delay in data packet arrival
System.Net.ServicePointManager.UseNagleAlgorithm = false;

Resumen de recomendaciones

En función de los factores descritos anteriormente, siga estas recomendaciones para optimizar el rendimiento de los proyectos de operación masiva:

  • Elija un tipo de tabla que se ajuste a sus requisitos. Las tablas elásticas tienen una capacidad mucho mayor para las operaciones masivas.
  • Minimice, deshabilite o omita la lógica de negocios personalizada en las tablas que usa. Configure la aplicación cliente para omitir la lógica personalizada cuando corresponda.
  • Use las API de operación masiva de Dataverse cuando pueda; de lo contrario, use api por lotes.
  • Diseñe la aplicación cliente para administrar errores transitorios, incluidos los errores devueltos por los límites de protección del servicio.
  • Enviar solicitudes en paralelo. Use el encabezado de respuesta para guiarle al grado recomendado de paralelismo (DOP). Deshabilite la cookie de afinidad cuando corresponda.
  • Valide los datos para asegurarse de que cumple el esquema de columna de tabla. Esto puede ayudar a evitar errores y a reducir el número de operaciones con errores.

Consulte también

Tablas elásticas
Usar complementos para ampliar los procesos de negocio
Pasar por alto la lógica personalizada de Dataverse
Mensajes de operación en masa
Escribir complementos para CreateMultiple y UpdateMultiple
Enviar solicitudes paralelas

  • Last updated on