Gérer les ressources de calcul pour un pool SQL dédié
Cet article explique comment gérer les ressources de calcul pour un pool SQL dédié (anciennement SQL DW) dans Azure Synapse Analytics. Vous pouvez réduire les coûts en suspendant le pool SQL dédié, ou mettez à l’échelle le pool SQL dédié afin de répondre aux exigences en matière de performances.
En quoi consiste la gestion des ressources de calcul ?
L’architecture du pool SQL dédié sépare le stockage du calcul, ce qui permet de les mettre à l’échelle indépendamment l’un de l’autre. En conséquence, vous pouvez procéder à la mise à l’échelle du calcul afin de répondre aux exigences en matière de niveau de performance, sans modifier le stockage des données. Vous avez également la possibilité de suspendre ou reprendre des ressources de calcul.
Dans le cadre de cette architecture, la tarification du calcul est donc effectuée séparément de celle du stockage. Si vous n’avez pas besoin d’utiliser pool SQL dédié pendant un certain temps, vous pouvez alléger les coûts de calcul en interrompant les ressources de calcul.
Mise à l’échelle du calcul
Vous pouvez effectuer un scale-out ou un scale-back du calcul en ajustant le paramétrage relatif aux unités DWU (Data Warehouse Units) de pool SQL dédié. Les performances de chargement et de requête peuvent s’accroître de manière linéaire à mesure que vous augmentez les unités DWU.
Pour plus d’informations sur la procédure de scale-out, consultez les guides de démarrage rapide pour le portail Azure, PowerShell ou T-SQL. Vous pouvez également effectuer des opérations de scale-out à l’aide d’une API REST.
Pour procéder à une mise à l’échelle, le pool SQL dédié commence par supprimer toutes les requêtes entrantes, puis il restaure les transactions afin de garantir un état cohérent. La mise à l’échelle ne se produit qu’une fois la restauration des transactions effectuée. Dans le cadre d’une opération de mise à l’échelle, le système détache la couche de stockage des nœuds de calcul, ajoute des nœuds de calcul, puis rattache la couche de stockage à la couche de calcul.
Chaque pool SQL dédié est stocké sous la forme de 60 distributions, qui sont réparties uniformément entre les nœuds de calcul. L’ajout de nœuds de calcul supplémentaires augmente la puissance de calcul. À mesure que le nombre de nœuds de calcul augmente, le nombre de distributions par nœud de calcul diminue, ce qui fournit davantage de puissance de calcul pour vos requêtes. De même, la diminution du nombre d’unités DWU réduit le nombre de nœuds de calcul, ce qui réduit les ressources de calcul pour les requêtes.
Le tableau ci-après illustre l’évolution du nombre de distributions par nœud de calcul à mesure que les unités DWU changent. La valeur DW30000c fournit 60 nœuds de calcul et offre un niveau de performances de requête bien supérieur à celui de la valeur DW100c.
| Data Warehouse Units | # de nœuds de calcul | # de distributions par nœud |
|---|---|---|
| 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 |
Détermination du nombre d’unités DWU optimal
Pour découvrir les avantages d’une montée en puissance en termes de niveau de performance, en particulier dans le cas des valeurs DWU les plus élevées, vous devez utiliser un jeu de données d’au moins 1 To. Pour déterminer le nombre d’unités DWU optimal pour votre pool SQL dédié, essayez d’effectuer un sale-up et un scale-down. Exécutez quelques requêtes avec différents nombres d’unités DWU après avoir chargé vos données. La mise à l’échelle étant rapide, vous pouvez essayer plusieurs niveaux de performances en une heure ou moins.
Recommandations pour trouver le nombre d’unités DWU optimal :
- Pour un pool SQL dédié en développement, commencez par sélectionner un nombre plus réduit d’unités DWU. DW400c ou DW200c est un bon point de départ.
- Surveillez les performances de votre application, en observant notamment le nombre d’unités DWU sélectionné.
- Avec une échelle linéaire, déterminez la quantité dont vous avez besoin pour augmenter ou diminuer le nombre d’unités DWU.
- Continuez à effectuer des ajustements jusqu’à ce que vous atteigniez le niveau de performances requis par vos activités.
Quand procéder à un scale-out
Effectuer un scale-out des unités DWU a un impact sur ces aspects des performances :
- Amélioration linéaire des performances du système pour les analyses, les agrégations et les instructions CTAS (Create Table As Select)
- Augmentation du nombre de processus de lecture et d’écriture pour le chargement de données
- Nombre maximal de requêtes simultanées et d’emplacements concurrentiels
Recommandations sur le moment approprié pour effectuer un scale-out d’unités DWU :
- Avant d’exécuter une opération de chargement ou de transformation de données importante, effectuez un scale-out afin que vos données soient disponibles plus rapidement.
- Pendant les heures de pointe, effectuez un scale-out pour prendre en charge un nombre plus important de requêtes simultanées.
Que faire si la procédure de scale-out n’améliore pas les performances ?
L’ajout d’unités DWU augmente le parallélisme. Si le travail est réparti uniformément entre les nœuds de calcul, ce surcroît de parallélisme accroît le niveau de performance des requêtes. Si le scale-out ne modifie pas votre niveau de performance, certaines raisons peuvent l’expliquer. Il peut exister une asymétrie des données entre les distributions, ou il est possible que des requêtes introduisent un déplacement important des données. Pour examiner les problèmes liés aux performances des requêtes, consultez l’article relatif à la résolution des problèmes de performances.
Suspension et reprise du calcul
La suspension du calcul consiste à détacher la couche de stockage des nœuds de calcul. Les ressources de calcul sont libérées de votre compte. Pendant la suspension du calcul, vous n’êtes pas facturé pour ce dernier. La reprise du calcul rattache le stockage aux nœuds de calcul et réenclenche la facturation du calcul.
Lorsque vous suspendez un pool SQL dédié :
- Les ressources de calcul et de mémoire sont renvoyées dans le pool des ressources disponibles du centre de données.
- Les coûts d’unités DWU sont nuls pendant la durée de la suspension.
- Le stockage de données n’est pas affecté et vos données restent intactes.
- Toutes les opérations en cours d’exécution ou en file d’attente sont annulées.
- Les compteurs DMV sont réinitialisés.
Lorsque vous reprenez un pool SQL dédié :
- Le pool SQL dédié acquiert les ressources de calcul et de mémoire correspondant à votre paramètre d’unités DWU.
- Les frais de calcul liés à votre unité DWU sont de nouveau applicables.
- Vos données deviennent disponibles.
- Une fois que le pool SQL dédié est en ligne, vous devez redémarrer vos requêtes de charge de travail.
Si vous voulez que votre pool SQL dédié soit toujours accessible, envisagez d’effectuer un scale-down à sa taille minimale au lieu de le suspendre.
Pour plus d’informations sur les procédures de suspension et de reprise, consultez les guides de démarrage rapide pour le portail Azure ou pour PowerShell. Vous pouvez également utiliser l’API REST de suspension ou l’API REST de reprise.
Vider les transactions avant la suspension ou la mise à l’échelle
Nous vous recommandons d’autoriser l’achèvement des transactions existantes avant d’initialiser une opération de suspension ou de mise à l’échelle.
Lorsque vous suspendez ou mettez à l’échelle votre pool SQL dédié, vos requêtes sont annulées en arrière-plan au moment où vous lancez la demande de suspension ou de mise à l’échelle. L’annulation d’une simple requête SELECT est une opération rapide et n’a quasiment aucun effet sur le temps nécessaire à la suspension ou à la mise à l’échelle de votre instance. Toutefois, les requêtes transactionnelles, qui modifient vos données ou la structure des données, ne pourront peut-être pas s’arrêter rapidement. Par définition, les requêtes transactionnelles doivent être terminées dans leur intégralité ou annuler leurs modifications.
L’annulation du travail effectué par une requête transactionnelle peut être aussi longue, voire plus, que la modification originale appliquée par la requête. Par exemple, si vous annulez une requête qui supprimait des lignes et était en cours d’exécution depuis une heure, le système mettra peut-être une heure à insérer à nouveau les lignes supprimées. Si vous exécutez une suspension ou une mise à l’échelle pendant que les transactions sont en cours, votre suspension ou mise à l’échelle peut sembler très longue, car la suspension et la mise à l’échelle doivent attendre la fin de la restauration avant de se lancer.
Pour plus d’informations, consultez la section Utiliser des transactions et Optimiser les transactions.
Automatiser la gestion du calcul
Pour automatiser les opérations de gestion du calcul, consultez Utiliser Azure Functions pour gérer les ressources de calcul pour votre pool SQL dédié.
L’exécution de chacune des opérations de montée en puissance, de suspension et de reprise peut nécessiter plusieurs minutes. Si vous procédez à une mise à l’échelle, une mise en suspens ou une reprise automatiques, nous vous recommandons d’implémenter une logique pour vérifier que certaines opérations sont terminées avant d’effectuer une autre action. La vérification de l’état du pool SQL dédié au niveau de différents points de terminaison vous permet d’automatiser correctement de telles opérations.
Pour vérifier l’état du pool SQL dédié, consultez le guide de démarrage rapide pour PowerShell ou T-SQL. Vous pouvez également vérifier l’état du pool SQL dédié à l’aide d’une API REST.
Autorisations
La mise à l’échelle du pool SQL dédié exige les autorisations décrites dans ALTER DATABASE. La suspension et la reprise requièrent le rôle Collaborateur de base de données SQL, notamment Microsoft.Sql/servers/databases/action.