Partager via

Consommation de ressources Synapse SQL

Cet article décrit les modèles de consommation de ressources de Synapse SQL.

Pool SQL serverless

Le pool SQL serverless est un service de paiement par requête qui ne vous oblige pas à choisir la taille appropriée. Le système s’ajuste automatiquement en fonction de vos besoins, ce qui vous libère de la gestion de votre infrastructure et du choix à faire quant à la taille adaptée pour votre solution.

Pool SQL dédié - Unités d’entrepôt de données (DWU) et unités de calcul de l’entrepôt de données (cDWU)

Recommandations sur le choix du nombre idéal d’unités d’entrepôt de données (DWU) pour optimiser les prix et les performances, et comment modifier le nombre d’unités.

Unités d’entrepôt de données

Un pool SQL Synapse représente une collection de ressources analytiques en cours d’approvisionnement. Les ressources analytiques sont définies comme une combinaison de processeur, de mémoire et d’E/S. Ces trois ressources sont regroupées en unités de mise à l’échelle de calcul appelées unités DWU (Data Warehouse Units). Une DWU représente une mesure abstraite et normalisée des ressources de calcul et des performances. Une modification apportée à votre niveau de service modifie le nombre de DWU disponibles pour le système. À son tour, cette modification ajuste les performances et le coût de votre système.

Pour des performances plus élevées, vous pouvez augmenter le nombre d’unités d’entrepôt de données. Pour des performances moindres, réduisez les unités d’entrepôt de données. Les coûts de stockage et de calcul sont facturés séparément, de sorte que la modification des unités d’entrepôt de données n’affecte pas les coûts de stockage.

Les performances des unités d’entrepôt de données sont basées sur les métriques de charge de travail de l’entrepôt de données suivantes :

  • Comment une requête standard d'entreposage de données peut rapidement balayer un grand nombre de lignes, puis effectuer une agrégation complexe. Cette opération est exigeante en matière de E/S et de CPU.
  • La vitesse à laquelle l'entrepôt de données peut ingérer des données depuis Azure Blob Storage ou Azure Data Lake. Cette opération est intensive au niveau réseau et au niveau CPU.
  • Vitesse à laquelle la CREATE TABLE AS SELECT commande T-SQL peut copier une table. Cette opération implique de lire des données à partir du stockage, de les distribuer sur les nœuds de l’appliance et d’écrire à nouveau dans le stockage. Cette opération est gourmande en processeur, en E/S et en ressources réseau.

Augmentation du nombre de Data Warehouse Units (DWU) :

  • Modification linéaire des performances du système pour les analyses, les agrégations et les instructions CTAS
  • Augmentation du nombre de lecteurs et d’enregistreurs pour les opérations de chargement PolyBase
  • Augmente le nombre maximal de requêtes simultanées et d’emplacements d’accès concurrentiel.

Service Level Objective (objectif de niveau de service)

L’objectif de niveau de service (SLO) est le paramètre d’extensibilité qui détermine le coût et le niveau de performances de votre entrepôt de données. Les niveaux de service pour Gen2 sont mesurés dans les unités d’entrepôt de données de calcul (cDWU), par exemple DW2000c. Les niveaux de service Gen1 sont mesurés en DWU, par exemple DW2000.

L’objectif de niveau de service (SLO) est le paramètre d’extensibilité qui détermine le coût et le niveau de performances de votre entrepôt de données. Les niveaux de service du pool SQL dédié Gen2 sont mesurés dans les unités d’entrepôt de données (DWU), par exemple DW2000c.

Remarque

Azure Synapse Analytics Gen2 a récemment ajouté des fonctionnalités de mise à l’échelle supplémentaires pour prendre en charge les niveaux de calcul aussi bas que 100 cDWU. Les entrepôts de données existants actuellement sur Gen1 qui nécessitent les niveaux de calcul inférieurs peuvent désormais effectuer une mise à niveau vers Gen2 dans les régions actuellement disponibles pour aucun coût supplémentaire. Si votre région n’est pas encore prise en charge, vous pouvez toujours effectuer une mise à niveau vers une région prise en charge. Pour plus d’informations, consultez Mettre à niveau vers Gen2.

Dans T-SQL, le paramètre SERVICE_OBJECTIVE détermine le niveau de service et le niveau de performances de votre pool SQL dédié.

CREATE DATABASE mySQLDW
(Edition = 'Datawarehouse'
 ,SERVICE_OBJECTIVE = 'DW1000c'
)
;

Niveaux de performances et unités d’entrepôt de données

Chaque niveau de performance utilise une unité de mesure légèrement différente pour leurs unités d’entrepôt de données. Cette différence est reflétée sur la facture, car l’unité d’échelle se traduit directement par la facturation.

  • Les entrepôts de données Gen1 sont mesurés dans les unités d’entrepôt de données (DWU).
  • Les entrepôts de données Gen2 sont mesurés dans les unités d’entrepôt de données de calcul (cDWU).

Les DWUs et cDWUs prennent en charge la montée en charge et la réduction de charge du calcul, ainsi que la suspension du calcul lorsque l'entrepôt de données n'est pas nécessaire. Ces opérations sont toutes à la demande. Gen2 utilise un cache sur disque local sur les nœuds de calcul pour améliorer les performances. Lorsque vous mettez à l’échelle ou suspendez le système, le cache est invalidé et une période de préchauffage du cache est nécessaire pour pouvoir bénéficier de performances optimales.

À mesure que vous augmentez les unités d’entrepôt de données, vous augmentez linéairement les ressources informatiques. Gen2 offre les meilleures performances de requête et la plus grande échelle. Les systèmes Gen2 utilisent également le plus le cache.

Limites de capacité

Chaque serveur SQL (par exemple, myserver.database.windows.net) a un quota DTU (Database Transaction Unit) qui permet un nombre spécifique d’unités d’entrepôt de données. Pour plus d’informations, consultez les limites de capacité de gestion des charges de travail.

Évaluer le nombre d’unités d’entrepôt de données dont vous avez besoin

Le nombre idéal d’unités d’entrepôt de données dépend beaucoup de votre charge de travail et de la quantité de données que vous avez chargées dans le système.

Étapes pour trouver le meilleur DWU pour votre charge de travail :

  1. Commencez par sélectionner un DWU plus petit.
  2. Surveillez les performances de votre application au fur et à mesure que vous testez les données dans le système, en observant le nombre de DWU sélectionnés par rapport aux performances que vous observez.
  3. Identifiez les exigences supplémentaires pour les périodes périodiques de pic d’activité. Les charges de travail qui montrent des pics et des creux significatifs dans l’activité peuvent avoir besoin d’être mises à l’échelle fréquemment.

Le pool SQL est un système extensible qui peut provisionner de grandes quantités de ressources informatiques et interroger de grandes quantités de données. Pour voir ses véritables fonctionnalités de mise à l’échelle, en particulier à des unités DWU plus grandes, nous vous recommandons de mettre à l’échelle le jeu de données à mesure que vous effectuez une mise à l’échelle pour vous assurer que vous disposez de suffisamment de données pour alimenter les processeurs. Pour les tests de mise à l’échelle, nous vous recommandons d’utiliser au moins 1 To.

Remarque

Les performances des requêtes augmentent uniquement avec plus de parallélisation si le travail peut être fractionné entre les nœuds de calcul. Si vous constatez que la mise à l’échelle ne modifie pas vos performances, vous devrez peut-être ajuster votre conception de table et/ou vos requêtes. Pour obtenir des conseils sur le réglage des requêtes, consultez Gérer les requêtes utilisateur.

Autorisations

La modification des unités d’entrepôt de données nécessite les autorisations décrites dans ALTER DATABASE.

Les rôles intégrés Azure tels que Contributeur SQL DB et Contributeur SQL Server peuvent modifier les paramètres DWU.

Afficher les paramètres DWU actuels

Pour afficher le paramètre DWU actuel :

  1. Ouvrez l’Explorateur d’objets SQL Server dans Visual Studio.
  2. Connectez-vous à la base de données master associée au serveur SQL logique.
  3. Sélectionnez-le dans la vue de gestion dynamique sys.database_service_objectives. Voici un exemple :
SELECT  db.name [Database]
,        ds.edition [Edition]
,        ds.service_objective [Service Objective]
FROM    sys.database_service_objectives   AS ds
JOIN    sys.databases                     AS db ON ds.database_id = db.database_id
;

Modifier les unités d’entrepôt de données

Portail Azure

Pour modifier les DWU :

  1. Ouvrez le portail Azure, ouvrez votre base de données, puis sélectionnez Redimensionner.

  2. Sous Mettre à l’échelle, déplacez le curseur vers la gauche ou vers la droite pour modifier le paramètre de DWU.

  3. Cliquez sur Enregistrer. Un message de confirmation s’affiche. Sélectionnez Oui pour confirmer ou non pour annuler.

PowerShell

Remarque

Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.

Pour modifier les DWU, utilisez l’applet de commande PowerShell Set-AzSqlDatabase . L’exemple suivant définit l’objectif de niveau de service sur DW1000 pour la base de données MySQLDW hébergée sur le serveur MyServer.

Set-AzSqlDatabase -DatabaseName "MySQLDW" -ServerName "MyServer" -RequestedServiceObjectiveName "DW1000c"

Pour plus d’informations, consultez les applets de commande PowerShell pour Azure Synapse Analytics

T-SQL

Avec T-SQL, vous pouvez afficher les DWUsettings actuels, modifier les paramètres et vérifier la progression.

Pour modifier les DWU :

  1. Connectez-vous à la base de données master associée à votre serveur.
  2. Utilisez l’instruction TSQL ALTER DATABASE . L’exemple suivant définit l’objectif de niveau de service sur DW1000c pour la base de données MySQLDW.
ALTER DATABASE MySQLDW
MODIFY (SERVICE_OBJECTIVE = 'DW1000c')
;

API REST

Pour modifier les DWU, utilisez l’API REST Créer ou mettre à jour la base de données . L’exemple suivant définit l’objectif de niveau de service sur DW1000c pour la base de données MySQLDW, qui est hébergée sur le serveur MyServer. Le serveur se trouve dans un groupe de ressources Azure nommé ResourceGroup1.

PUT https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Sql/servers/{server-name}/databases/{database-name}?api-version=2014-04-01-preview HTTP/1.1
Content-Type: application/json; charset=UTF-8

{
    "properties": {
        "requestedServiceObjectiveName": DW1000
    }
}

Pour plus d’exemples d’API REST, consultez les API REST pour Azure Synapse Analytics.

Vérifier l’état des modifications de DWU

Les modifications de DWU peuvent prendre plusieurs minutes pour être complètes. Si vous effectuez une mise à l’échelle automatiquement, envisagez d’implémenter la logique pour vous assurer que certaines opérations ont été effectuées avant de poursuivre avec une autre action.

La vérification de l’état de la base de données via différents points de terminaison vous permet d’implémenter correctement l’automatisation. Le portail fournit une notification lors de l’achèvement d’une opération et de l’état actuel des bases de données, mais n’autorise pas la vérification programmatique de l’état.

Vous ne pouvez pas vérifier l’état de la base de données pour les opérations de scale-out avec le portail Azure.

Pour vérifier l’état des modifications de DWU :

  1. Connectez-vous à la base de données master associée à votre serveur.
  2. Envoyez la requête suivante pour vérifier l’état de la base de données.
SELECT    *
FROM      sys.databases
;
  1. Envoyer la requête suivante pour vérifier l’état de l’opération
SELECT    *
FROM      sys.dm_operation_status
WHERE     resource_type_desc = 'Database'
AND       major_resource_id = 'MySQLDW'
;

Cette vue dynamique de gestion (DMV) fournit des informations sur différentes opérations de gestion dans votre pool SQL dédié, comme l’opération et l’état de l’opération, qui est soit EN_COURS, soit TERMINÉ.

Flux de travail de mise à l’échelle

Lorsque vous démarrez une opération de mise à l’échelle, le système tue d’abord toutes les sessions ouvertes, en annulant toutes les transactions ouvertes pour garantir un état cohérent. Pour les opérations de mise à l’échelle, la mise à l’échelle se produit uniquement une fois cette restauration transactionnelle terminée.

  • Pour une opération de montée en puissance, le système détache tous les nœuds de calcul, provisionne les nœuds de calcul supplémentaires, puis se réattache à la couche de stockage.
  • Pour une opération de scale-down, le système détache tous les nœuds de calcul, puis reattache uniquement les nœuds nécessaires à la couche de stockage.

Étapes suivantes

Pour en savoir plus sur la gestion des performances, consultez Les classes de ressources pour la gestion des charges de travail et les limites de mémoire et de concurrence.

  • Last updated on