Administración de recursos computacionales para un clúster de SQL dedicado

Tip

Microsoft Fabric Data Warehouse es un almacenamiento relacional de escala empresarial en una base de lago de datos, con una arquitectura lista para el futuro, inteligencia artificial integrada y nuevas características. Si no está familiarizado con el almacenamiento de datos, comience con Fabric Data Warehouse. Las cargas de trabajo del grupo de SQL dedicadas pueden actualizarse a Fabric para acceder a nuevas funcionalidades en ciencia de datos, análisis en tiempo real e informes.

En este artículo, se explica cómo administrar los recursos de proceso para un grupo de SQL dedicado (anteriormente SQL DW) en Azure Synapse Analytics. Puede reducir los costos pausando el grupo de SQL dedicado o escalándolo para satisfacer las demandas de rendimiento.

¿Qué es la administración de computación?

La arquitectura del grupo de SQL dedicado separa el proceso y el almacenamiento, lo que permite a cada uno escalar de manera independiente. Como resultado, puede escalar el proceso para satisfacer las demandas de rendimiento con independencia del almacenamiento de datos. También puede pausar y reanudar los recursos de computación.

Una consecuencia natural de esta arquitectura es que los precios para proceso y almacenamiento son independientes. Si no es necesario usar el grupo de SQL dedicado durante un tiempo, puede detener el proceso para ahorrar costos de proceso.

Escalado de cómputo

Para escalar horizontalmente el proceso o reducir su escala, ajuste el valor de las unidades de almacenamiento de datos (DWU) del grupo de SQL dedicado. El rendimiento de la carga y las consultas pueden aumentar linealmente a medida que se agregan más DWU.

Para conocer los pasos de escalado horizontal, consulte las guías de inicio rápido de Azure Portal, PowerShell o T-SQL. También puede realizar operaciones de escalado horizontal mediante una REST API.

Para realizar una operación de escalado, el grupo de SQL dedicado termina primero todas las consultas entrantes y, luego, revierte las transacciones para garantizar un estado coherente. El escalado solo se produce una vez finalizada la reversión de la transacción. En una operación de escalado, el sistema desasocia la capa de almacenamiento de los nodos de proceso, agrega nodos de proceso y, luego, vuelve a asociar la capa de almacenamiento a la capa de proceso.

Cada grupo de SQL dedicado se almacena como 60 distribuciones, que se distribuyen de manera uniforme a los nodos de proceso. Al agregar más nodos de proceso, se agrega más capacidad de proceso. A medida que aumenta el número de nodos de proceso, se reduce el número de distribuciones por nodo de proceso, de forma que hay más capacidad de proceso para las consultas. De igual manera, al reducir las DWU se reduce el número de nodos de proceso,lo que reduce los recursos de proceso para las consultas.

En la tabla siguiente, se muestra cómo cambia el número de distribuciones por nodo de proceso a medida que cambian las DWU. DW30000c proporciona 60 nodos de proceso y consigue un rendimiento mucho mayor que DW100c.

Unidades de almacenamiento de datos Número de nodos de cómputo Número de distribuciones por nodo
DW100c 1 60
DW200c 1 60
DW300c 1 60
DW400c 1 60
DW500c 1 60
DW1000c 2 30
DW1500c 3 20
DW2000c 4 15
DW2500c 5 12
DW3000c 6 10
DW5000c 10 6
DW6000c 12 5
DW7500c 15 4
DW10000c 20 3
DW15000c 30 2
DW30000c 60 1

Búsqueda del tamaño adecuado de las unidades de almacenamiento de datos

Para observar las ventajas de rendimiento del escalamiento horizontal, especialmente para almacenes de datos más grandes, debería utilizar al menos un conjunto de datos de 1 TB. Para encontrar el mejor número de DWU para su grupo de SQL dedicado, intente escalar hacia arriba y hacia abajo. Ejecute algunas consultas con distintos números de DWU después de cargar los datos. Dado que el escalado se realiza rápidamente, puede probar varios niveles de rendimiento en una hora o menos.

Recomendaciones para encontrar el mejor número de DWU:

  • Para un grupo de SQL dedicado en fase de desarrollo, comience por seleccionar un número menor de unidades de almacenamiento de datos (DWU). Un buen punto de partida es DW400c o DW200c.
  • Supervise el rendimiento de su aplicación, observando el número de DWU seleccionados en comparación con el rendimiento que observe.
  • Suponga una escala lineal y determine cuánto debe aumentar o reducir las DWU.
  • Continúe realizando ajustes hasta llegar a un nivel de rendimiento adecuado para sus requerimientos empresariales.

Cuándo expandir horizontalmente

El escalado horizontal de DWU afecta a los siguientes aspectos de rendimiento:

  • Mejora linealmente el rendimiento del sistema en lo referente a exámenes, agregaciones e instrucciones CTAS.
  • Aumenta el número de lectores y escritores para cargar los datos.
  • Número máximo de consultas simultáneas y espacios de concurrencia

Recomendaciones sobre cuándo realizar el escalado horizontal de DWU:

  • Antes de realizar una operación de transformación o carga de datos masiva, amplíe la capacidad para que los datos estén disponibles con mayor rapidez.
  • Durante las horas punta de negocio, amplíe para dar cabida a un mayor número de consultas simultáneas.

¿Qué ocurre si el escalado horizontal no mejora el rendimiento?

Agregar DWU aumenta el paralelismo. Si el trabajo se divide uniformemente entre los nodos de proceso, el paralelismo adicional mejora el rendimiento de las consultas. Si el escalado horizontal no cambia el rendimiento como se espera, hay algunos motivos por los que esto puede ocurrir. Puede que los datos estén sesgados en las distribuciones o que las consultas introduzcan un gran movimiento de datos. Para investigar los problemas de rendimiento de consultas, consulte las soluciones a los problemas de rendimiento.

Pausa y reanudación de proceso

Al pausar el proceso, la capa de almacenamiento se desasocia de los nodos de proceso. Se liberan los recursos de computación de su cuenta. No se le cobra por el cómputo mientras está en pausa. Al reanudar el cálculo, se vuelve a conectar el almacenamiento a los nodos de cálculo y se reanudan los costes de cálculo.

Al pausar un grupo de SQL dedicado:

  • Los recursos de cómputo y memoria se devuelven al grupo de recursos disponibles en el centro de datos.
  • Los costos de unidad de almacenamiento de datos son cero durante la pausa.
  • El almacenamiento de datos no se ve afectado y sus datos permanecen intactos.
  • Todas las operaciones en ejecución o en cola se cancelan.
  • Se restablecen los contadores de DMV.

Al reanudar un grupo de SQL dedicado:

  • El grupo de SQL dedicado adquiere recursos de proceso y memoria para la configuración de DWU.
  • Calcule los cargos correspondientes al reanudamiento de los DWUs.
  • Sus datos están disponibles.
  • Una vez que el grupo de SQL dedicado esté en línea, tendrá que reiniciar las consultas de carga de trabajo.

Si desea que el grupo de SQL dedicado esté siempre accesible, considere reducirlo al tamaño más pequeño en lugar de pausarlo.

Para conocer los pasos de pausa y reanudación, consulte las guías de inicio rápido de Azure Portal o PowerShell. También puede usar la REST API de pausa o la REST API de reanudación.

Vacie transacciones antes de pausar o escalar

Se recomienda permitir que finalicen las transacciones existentes antes de iniciar una operación de pausa o escalado.

Al pausar o escalar el grupo de SQL dedicado, las consultas se cancelan en segundo plano al iniciar la solicitud de pausa o escalado. Cancelar una consulta SELECT simple es una operación rápida y casi no tiene ningún efecto en el tiempo necesario para pausar o escalar la instancia. Sin embargo, las consultas transaccionales, que modifican los datos o la estructura de estos, podrían no detenerse rápidamente. Por definición, las transacciones deben completarse en su totalidad o revertirse los cambios.

Deshacer el trabajo realizado por una consulta transaccional puede tardar tanto o incluso más que el cambio original que aplicaba la consulta. Por ejemplo, si se cancela una consulta que elimina filas y ya lleva en ejecución una hora, el sistema puede tardar una hora en volver a insertar las filas eliminadas. Si ejecutas la pausa o el escalado mientras las transacciones están en curso, puede parecer que tarda mucho tiempo porque pausar y escalar debe esperar a que se complete la reversión antes de poder continuar.

Para obtener más información, consulte Uso de transacciones y Optimización de transacciones.

Automatización de la gestión de los recursos computacionales

Para automatizar las operaciones de administración de los recursos de proceso, consulte Uso de Azure Functions para administrar los recursos de proceso del grupo de SQL dedicado.

Cada una de las operaciones de escalado horizontal, pausa y reanudación puede tardar varios minutos en completarse. Si va a escalar, pausar o reanudar automáticamente, se recomienda implementar una lógica para garantizar que se hayan completado determinadas operaciones antes de continuar con otra acción. La comprobación del estado del grupo de SQL dedicado mediante varios puntos de conexión le permite implementar correctamente la automatización de estas operaciones.

Para comprobar el estado del grupo de SQL dedicado, consulte el inicio rápido de PowerShell o T-SQL. También puede comprobar el estado del grupo de SQL dedicado con una API REST.

Permisos

Para escalar el grupo de SQL dedicado, se requieren los permisos descritos en ALTER DATABASE. Para pausar y reanudar, se requiere el rol Colaborador de base de datos SQL, específicamente Microsoft.Sql/servers/databases/action.