Exporter (0) Imprimer
Développer tout

Versions d'évaluation Basic, Standard et Premium de la base de données SQL Azure

Mis à jour: mai 2014

Auteurs : Conor Cunningham, Kun Cheng, Jan Engelsberg

Réviseurs techniques : Morgan Oslake, Joanne Marone, Keith Elmore, José Batista-Neto, Rohit Nayak

En plus de la version Premium, la Base de données SQL Azure offre désormais deux nouveaux niveaux de service, Basic et Standard. En contrôlant rigoureusement la quantité de ressources de votre Base de données SQL Azure et ses réplicas secondaires, le niveau de service Premium permet de mieux prévoir les performances de vos applications de cloud computing. La Base de données SQL Azure étend ce concept au nouveau niveau de service Standard pour offrir une haute prévisibilité de performance aux bases de données dont les exigences en matière de performance sont inférieures à celles du niveau de service Premium. Le niveau de service Basic est conçu pour répondre aux exigences de performance des bases de données de moindre coût.

Ce document fournit des instructions pour vous aider à déterminer, parmi ces versions préliminaires, le niveau de service adéquat pour votre application, ainsi que des recommandations pour paramétrer votre application de façon à tirer le meilleur parti de votre Base de données SQL Azure. Il comprend les sections suivantes :

Contexte de la Base de données SQL Azure

En quoi les nouveaux niveaux de service se distinguent-ils ?

Raisons d'utiliser les nouveaux niveaux de service

Présentation de l'utilisation des ressources

Paramétrage de votre application

Conclusion

Afin de comprendre comment les niveaux de service Basic, Standard et Premium améliorent le service existant de la Base de données SQL Azure, vous devez avoir une bonne compréhension globale de cette dernière. Les clients optent pour Base de données SQL Azure pour diverses raisons. L'une de ces raisons est d'éviter un long cycle d'achat et d'installation de matériel. LA Base de données SQL Azure vous permet de créer et de supprimer des bases de données à la volée sans attendre l'approbation d'un bon de commande, la réception d'ordinateurs, la mise à niveau ou l'installation d'une l'alimentation électrique et de ventilateurs. Microsoft gère ces problèmes et réduit considérablement le temps nécessaire de l'idée à la solution en prédéployant le matériel en fonction d'une demande globale dans chacun de ses centres de données. Cela peut faire gagner des semaines ou des mois pour l'activité d'un client par rapport à l'achat et au déploiement du matériel manuellement.

Microsoft inclut également dans la Base de données SQL Azure de nombreuses fonctionnalités de gestion automatique, notamment la haute disponibilité automatique, l'équilibrage de charge et la gestion intégrée.

  • Haute disponibilité automatique

    La Base de données SQL Azure conserve au moins trois réplicas de chaque base de données utilisateur, et intègre une logique permettant de valider automatiquement et de façon synchrone chaque modification apportée à un quorum de réplicas. Cela garantit qu'une défaillance d'ordinateur n'entraîne pas de perte de données. En outre, chaque réplica est placé sur différents racks matériels afin que la perte de puissance ou de commutateurs réseau n'affecte pas votre base de données. Enfin, il existe une logique pour reconstruire automatiquement les réplicas en cas de perte d'un ordinateur, de façon à ce que le système conserve automatiquement les propriétés souhaitées d'intégrité et ce, même si un ordinateur est défectueux. Ces mécanismes évitent le processus long nécessaire pour installer et configurer des solutions haute disponibilité. Le fait de disposer d'une solution haute disponibilité préconfigurée pour vos données supprime un autre casse-tête lié à la création d'une solution de base de données critique à l'aide de techniques traditionnelles.

  • Équilibrage de charge

    Contrairement aux machines virtuelles traditionnelles, la Base de données SQL Azure contient également un mécanisme permettant d'équilibrer automatiquement la charge sur plusieurs ordinateurs. Le programme d'équilibrage de charge examine dynamiquement l'utilisation des ressources d'un cluster, puis déplace les réplicas de base de données vers des ordinateurs du cluster afin de partager dynamiquement la charge entre plusieurs utilisateurs. Cela étend la fonction de capacité de base de données à la demande et permet à un utilisateur de prendre en compte les spécifications de capacité pour chaque base de données indépendamment, car le programme d'équilibrage de charge peut migrer les bases de données occupées. Lorsque vous créez des solutions qui couvrent plusieurs bases de données, cette logique fournit une couche d'abstraction qui permet à un client de se concentrer sur les besoins en capacité de chaque base de données plutôt que sur les limitations de taille spécifiques d'une machine virtuelle.

  • Gestion intégrée

    La Base de données SQL Azure s'exécute en tant que service. Cela signifie qu'il existe des cibles de temps de fonctionnement définies pour chaque base de données, ce qui évite des fenêtres prolongées de temps mort de maintenance. Microsoft fournit une solution proposée par un seul fournisseur pour le service, ce qui signifie qu'il n'y a qu'une seule société à appeler si un problème se produit. En outre, Microsoft met à jour continuellement le service, en ajoutant des fonctionnalités et des capacités, et en recherchant des méthodes pour améliorer votre expérience dans chaque mise à jour que nous réalisons. Les mises à jour se produisent de façon transparente et sans fenêtres d'interruption, ce qui signifie qu'elles sont intégrées dans notre mécanisme normal de basculement haute disponibilité. Cela permet aux clients de tirer parti immédiatement de nouvelles fonctionnalités chaque fois que leur disponibilité est annoncée au lieu d'attendre la mise à niveau d'un serveur pendant une prochaine fenêtre de temps mort.

Ces fonctionnalités sont offertes par tous les niveaux de service, dont le moins cher ne coûte que quelques dollars par mois. Ce prix est bien inférieur à ce que coûteraient l'achat et l'exécution de votre propre serveur. Cela signifie que même le plus petit projet peut tirer parti de Azure sans dépenser énormément d'argent.

Microsoft a travaillé en étroite collaboration avec plusieurs clients pendant leur phase d'adoption de la Base de données SQL Azure pour découvrir comment ils utilisaient le service, et permettre à son équipe technique d'en tirer des enseignements pour la planification des fonctionnalités futures. Pendant ces engagements, nous avons observé que pour certains types de clients, les fonctionnalités étaient bien adaptées à leurs besoins. Par exemple, les jeunes pousses qui développent de nouveaux services de cloud computing ont souvent constaté que l'association de la capacité à la demande et de la charge administrative réduite simplifiaient leurs vies et leur permettaient de se concentrer sur leurs activités de base. D'autres clients ont rencontré des problèmes dans des domaines liés à des impératifs de performances dans des délais serrés, par exemple, pour la maintenance d'une API centrale dans une solution de base de données de grande taille à plusieurs niveaux, qui n'avaient pas été satisfaits par le service de Base de données SQL Azure. Les commentaires reçus étaient que certains clients étaient prêts à accepter des écarts de performance conséquents pour obtenir un prix d'entrée très bas, tandis que d'autres étaient plus intéressés par des garanties de performance spécifiques afin d'apporter une plus forte valeur ajoutée à ces bases de données.

Pour répondre aux besoins de tous les clients, Microsoft a introduit les niveaux de service Basic, Standard et Premium, actuellement disponible en version préliminaire publique. Chaque niveau de service offre un ou plusieurs niveaux de performance offrant la puissance nécessaire pour exécuter vos bases de données de façon prévisible. La puissance est exprimée en termes d'unités de débit de base de données (DTU). Le tableau suivant montre les niveaux de service, les niveaux de performance et les DTU :

 

Couche de service

Niveau de performance

DTU

Basique

5

Standard

S1

15

Standard

S2

50

Premium

P1

100

Premium

P2

200

Premium

P3

800

Le niveau de service Basic est conçu pour offrir une bonne prévisibilité de performance de chaque base de données d'heure en heure. La DTU d'une base de données de niveau Basic est conçue pour offrir des ressources suffisantes afin que des bases de données de petite taille ne recevant pas plusieurs requêtes simultanées offrent une performance correcte.

Pour améliorer la prévisibilité de performance et hausser la barre pour les bases de données traitant plusieurs requêtes simultanées, telles que des applications Web et de groupe de travail, Microsoft a introduit le niveau de service Standard. L'utilisation d'une base de données de niveau de service Standard permet aux clients d'adapter la taille de leur application de base de données en fonction d'une performance prévisible minute par minute. Le niveau de service Standard offre deux niveaux de performance, S1 et S2, entre lesquels vous pouvez basculer en fonction des besoins.

La capacité phare en relation avec la performance du niveau de service Premium est la performance prévisible, seconde après seconde, de chaque base de données Premium. Le niveau de service Premium permet aux clients d'adapter la taille de leur application de base de données aux pics de charge, en supprimant les cas où un écart de performance peut avoir pour effet que l'exécution de petites requêtes prenne plus de temps que prévu en raison d'opérations sensibles au temps de réponse. Ce modèle simplifie considérablement les cycles de développement et de validation de produit nécessaires pour les applications qui doivent effectuer des instructions fortes sur les besoins en ressources pendant les heures de pointe, l'écart de performances ou le temps de réponse des requêtes. Il permet également de migrer certaines applications locales sans apporter de modifications significatives, car il s'agit d'une expérience plus proche de celle de l'expérience traditionnelle isolée utilisée dans ces applications lorsqu'elles ont été initialement générées.

Comme le niveau de service Standard, le niveau de service Premium offre le choix entre différents niveaux de performance en fonction de l'isolement souhaité pour un client.

Les paramètres de niveau de performance des versions Standard et Premium permettent au client de payer uniquement la capacité nécessaire, et d'accroître ou de réduire la capacité en fonction de l'évolution de la charge de travail. Par exemple, si la charge de travail de votre base de données est occupée pendant la période de reprise des cours, vous pouvez augmenter le niveau de performance pour la base de données au cours de cette période, et la réduire à l'issue de cette fenêtre de pic. Cela permet aux clients de réduire leurs frais en optimisant leur environnement de cloud en fonction du caractère saisonnier de leur activité. Ce modèle fonctionne également bien pour les cycles de commercialisation des versions de logiciel. Une équipe de test peut affecter une capacité tout en faisant des séries de tests et libérer cette capacité une fois les tests terminés. Ces demandes de capacité sont adaptées au modèle que vous payeriez pour la capacité en fonction de vos besoins et évite les dépenses en ressources dédiées qui sont rarement utilisées. Cela vous procure une expérience de performances beaucoup plus proche de celle du modèle de matériel dédié traditionnel que plusieurs clients de Microsoft utilisaient avec SQL Server. Cela doit permettre à un plus grand nombre d'applications de s'exécuter plus facilement sur la Base de données SQL Azure.

Chaque charge de travail pouvant différer, le but des nouveaux niveaux de service est d'offrir une haute prévisibilité de performance à divers niveaux. Les niveaux de service permettent aux clients dont les bases de données ont d'importants besoins de ressources, de travailler dans un environnement de calcul davantage dédié.

Cas dans lesquels la fonctionnalité Niveau de service Basic s'applique généralement :

  • Prise en main de la Base de données SQL Azure : les applications en développement n'ont généralement pas besoin de hauts niveaux de performance. Les bases de données de niveau Basic offrent un environnement idéal pour le développement de base de données à moindre coût.

  • Base de données avec un seul utilisateur : les applications qui associent un utilisateur unique à une base de données sont généralement peu exigeantes en matière de simultanéité d'utilisation et de performance. Pour les applications de ce type, le niveau de service Basic est généralement adéquat.

Cas dans lesquels la fonctionnalité Niveau de service Standard s'applique généralement :

Base de données avec plusieurs requêtes simultanées : le niveau de service Standard est adéquat pour les applications qui gèrent plusieurs utilisateurs à la fois, telles que des sites Web au trafic modéré ou des applications départementales qui requièrent davantage de ressources.

Cas dans lesquels la fonctionnalité Niveau de service Premium s'applique généralement :

  • Charge maximale élevée : une application qui nécessite d'importantes ressources de processeur, de mémoire, ou d'E/S pour exécuter ses opérations. Par exemple, si une opération de base de données est connue pour utiliser plusieurs cœurs d'UC pendant une période prolongée, c'est une candidate pour l'utilisation de bases de données Premium.

  • Nombreuses demandes simultanées : certaines applications de base de données servent de nombreuses demandes simultanées, par exemple un site Web au volume de trafic important. Les niveaux de service Basic et Standard imposent des limites au nombre de requêtes simultanées. Les applications nécessitant plus de connexions doivent choisir une taille de réservation appropriée pour traiter le nombre maximal de demandes nécessaires.

  • Latence faible : certaines applications doivent garantir un temps de réponse minimal de la base de données. Si une procédure stockée donnée est appelée dans le cadre d'une plus grande opération du client, il peut être nécessaire que cet appel retourne dans un délai maximal de 20 millisecondes à 99 %. Ce type d'application tirera parti des bases de données Premium pour garantir que la puissance de calcul est disponible.

Pour plus d'informations sur les scénarios courants qui peuvent entraîner des problèmes de performances lorsque vous utilisez Base de données SQL Azure, consultez Base de données SQL Azure et SQL Server -- Performances et évolutivité : comparaison et différences.

Le niveau exact dont vous aurez besoin dépend des conditions de charge maximale de chaque dimension de ressource. Certaines applications peuvent utiliser les limites insignifiantes d'une ressource mais avoir des spécifications significatives dans une autre.

Les nouveaux niveaux de service sont structurés comme suit :

 

Couche de service/Niveau de performance DTU Taille MAX de la BD Threads de travail max Sessions max Prévisibilité

Basique

5

2 GB

20

100

Bon

Standard/S1

15

250 GB

50

200

Meilleur

Standard/S2

50

250 GB

100

500

Meilleur

Premium/P1

100

500 GB

200

2,000

Le meilleur

Premium/P2

200

500 GB

400

4,000

Le meilleur

Premium/P3

800

500 GB

1,600

16,000

Le meilleur

Le graphique suivant illustre l'utilisation des ressources processeur pour une base de données Premium avec un niveau de performance P2 à chaque heure de la semaine. Ce graphique commence un lundi, affiche 5 journées de travail, puis un week-end où la charge de l'application est moindre.

Selon les données, cette base de données a une charge maximale d'UC juste supérieure à 50 % par rapport au niveau de performance P2 (à midi le mardi). Si l'UC était le facteur dominant dans le profil de ressource de l'application, le client peut décider que le niveau de performance P2 est adéquat pour garantir le traitement de la charge de travail. Si une croissance de l'application est attendue au fil du temps, il est logique de tenir compte d'une certaine mémoire tampon de ressources supplémentaire afin que l'application n'atteigne jamais les limites. Cela permettra d'éviter les erreurs visibles par le client générées par la base de données qui n'a pas suffisamment de puissance pour traiter les demandes efficacement, en particulier dans les environnements sensibles au temps de réponse (comme une base de données prenant en charge une application qui peint les pages Web selon les résultats des appels de base de données).

Il faut noter que d'autres types d'applications peuvent interpréter le même graphique différemment. Par exemple, si une application a tenté de traiter des données de feuille de paie tous les jours et a obtenu le même graphique, ce type de modèle de « programme de traitement par lot » peut fonctionner correctement à un niveau de performance P1. Le niveau de performance P1 a 100 DTU par rapport aux 200 DTU du niveau de performance P2. Cela signifie que le niveau de performance P1 est inférieur de moitié au niveau de performance P2. Ainsi, 50 % d'utilisation de l'UC au niveau de performance P2 équivalent à 100 % d'utilisation de l'UC au niveau de performance P1. Tant que l'application n'a pas de délais d'attente, elle ne peut pas déterminer si l'exécution d'un travail prend 2 heures ou 2,5 heures tant qu'elle se termine dans la journée. Une application dans cette catégorie peut probablement simplement utiliser un niveau de performance P1. Ce client peut tirer parti du fait qu'il y a des périodes au cours de la journée pendant lesquelles l'utilisation des ressources est moindre, ce qui signifie que toute « période de pointe » peut déborder sur une autre plus tard dans la journée. Le niveau de performance P1 peut convenir pour une telle application (et permettre de faire des économies) tant que les travaux s'effectuent à temps chaque jour.

La Base de données SQL Azure affiche des informations sur les ressources consommées pour chaque base de données active dans la vue sys.resource_stats de la base de données master sur chaque serveur. Les données de la table sont agrégées par intervalles de cinq minutes. Pendant la durée des versions préliminaires Basic, Standard et Premium, l'affichage des données dans la table peut prendre plus de cinq minutes. Cela signifie que ces données sont plus adaptées à des fins d'historique que d'analyse en temps quasi-réel. L'interrogation de la vue sys.resource_stats montre l'historique récent d'une base de données pour valider le fait que la réservation sélectionnée a fourni ou non la performance souhaitée au moment approprié. L'exemple suivant illustre l'affichage des données dans cette vue :

SELECT TOP 10 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

Remarque : certaines colonnes de la table ont été tronquées, faute d'espace. Pour une description complète de la sortie, consultez la rubrique sys.resource_stats.

Cette section décrit les méthodes pour analyser l'utilisation des ressources de votre Base de données SQL Azure afin de comparer l'utilisation actuelle des ressources aux différents niveaux de performance.

  1. Dans la version préliminaire actuelle, l'affichage catalogue sys.resource_stats a été enrichie avec davantage d'informations d'utilisation des ressources historiques au niveau de la base de données. Par exemple, pour examiner l'utilisation des ressources de la semaine passée pour la base de données « userdb1 », exécutez la requête suivante :

    SELECT * 
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND 
          start_time > DATEADD(day, -7, GETDATE())
    ORDER BY start_time DESC;
    
    
  2. Afin d'évaluer à quel point votre charge de travail est adaptée au niveau de performance, vous devez étudier chaque aspect des métriques de ressources : UC, lectures, écritures, nombre d'utilisateurs et nombre de sessions. Voici une requête modifiée utilisant sys.resource_stats pour indiquer la moyenne, ainsi que les valeurs maximales de ces métriques de ressources.

    SELECT 
        avg(avg_cpu_percent) AS 'Average CPU Utilization In Percent',
        max(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent',
        avg(avg_physical_data_read_percent) AS 'Average Physical Data Read Utilization In Percent',
        max(avg_physical_data_read_percent) AS 'Maximum Physical Data Read Utilization In Percent',
        avg(avg_log_write_percent) AS 'Average Log Write Utilization In Percent',
        max(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent',
        avg(active_session_count) AS 'Average # of Sessions',
        max(active_session_count) AS 'Maximum # of Sessions',
        avg(active_worker_count) AS 'Average # of Workers',
        max(active_worker_count) AS 'Maximum # of Workers'
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
  3. Avec les informations ci-dessus concernant les valeurs moyennes et maximales de chaque métrique de ressource, vous pouvez évaluer l'adéquation de votre charge de travail avec le niveau de performance choisi. Dans la plupart des cas, les valeurs moyennes de sys.resource_stats fournissent une bonne ligne de base à utiliser par rapport à la taille cible. Il doit s'agit de votre mesure de base. Par exemple, si vous utilisez le niveau de service Standard avec le niveau de performance S2, si les pourcentages d'utilisation moyenne pour l'UC, les lectures et les écritures sont inférieurs à 20 %, et si nombre moyen d'utilisateurs est inférieur à 50 et le nombre moyen de sessions inférieur à 200, il se peut que votre charge de travail corresponde au niveau de performance S1. Vous pouvez voir aisément si votre base de données est compatible avec les limites d'utilisateurs et de sessions. Pour voir si une base de données est compatible avec un niveau de performance inférieur en relation avec l'UC, les lectures et les écritures, vous devez diviser la valeur DTU du niveau de performance inférieur par la valeur DTU du niveau de performance actuel, puis multiplier le résultat par 100 :



    S1 DTU / S2 DTU * 100 = 5 / 25 * 100 = 20



    Le résultat indique, sous forme de pourcentage, la différence de performance relative entre les deux niveaux de performance. Si votre utilisation ne dépasse pas ce pourcentage, il se peut que le niveau de performance inférieur soit adéquat pour votre charge de travail. Toutefois, vous devez examiner toutes les plages de valeurs d'utilisation des ressources et déterminer, en pourcentage, la fréquence à laquelle la charge de travail de votre base de données serait adéquate pour le niveau de performance inférieur. La requête suivante permet d'obtenir le pourcentage adéquat par dimension de ressource, sur la base du seuil de 20 % calculé ci-dessus :

    SELECT 
        (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
    Compte tenu de l'objectif de niveau de service (SLO) de votre base de données, vous pouvez décider si votre charge de travail correspond au niveau de performance inférieur. Si le SLO de charge de travail de votre base de données est de 99,9 % et si la requête ci-dessus retourne des valeurs supérieures à 99,9 pour les trois dimensions de ressources, il est très probable que votre charge de travail soit adéquate pour le niveau de performance inférieur.

    L'examen du pourcentage d'adéquation vous permet également de déterminer si vous devez passer au niveau de performance supérieur pour atteindre votre SLO. Par exemple, « userdb1 » indique l'utilisation suivante pour la semaine dernière :

     

    Pourcentage moyen d'utilisation de l'UC

    Pourcentage maximal d'utilisation de l'UC

    24.5

    100.00

    L'utilisation moyenne de l'UC correspond à environ un quart de la limite du niveau de performance, ce qui est adapté au niveau de performance de la base de données. Toutefois, la valeur maximale indique que la base de données atteint la limite du niveau de performance. Devez-vous passer au niveau de performance supérieur ? Une fois encore, vous devez examiner le nombre de fois que votre charge de travail atteint 100 % et comparer cette valeur au SLO de charge de travail de votre base de données :

    SELECT 
    (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
    ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent’
    ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    Si la requête ci-dessus retourne une valeur inférieure à 99,9 pour l'une des trois dimensions de ressources, vous devez envisager de passer au niveau de performance supérieur ou d'utiliser les techniques de paramétrage d'application afin de réduire la charge sur la Base de données SQL Azure.

  4. L'exercice ci-dessus doit également prendre en considération votre augmentation prévue de charge de travail.

Dans une configuration SQL Server locale traditionnelle, le processus de planification de capacité initiale est souvent distinct du processus d'exécution d'une application en production. Autrement dit, l'achat de matériel et des licences associées pour exécuter SQL Server s'effectue à l'avance, alors que le réglage des performances est effectué après. Lorsque vous utilisez une Base de données SQL Azure, il est généralement recommandé (et, étant donné que les clients sont facturés chaque mois, souhaitable) d'entrelacer le processus d'exécution et de paramétrage d'une application. Le modèle de paiement pour la capacité à la demande permet au client de paramétrer son application de façon à utiliser les ressources minimales nécessaires au lieu de surdéployer massivement des ressources matérielles en fonction de conjectures de plans de croissance future pour une application (qui sont souvent incorrects, car la prédication est à un horizon trop lointain). Notez que certains clients peuvent décider de ne pas paramétrer une application et choisir à la place de surdéployer des ressources matérielles. Cette approche peut être judicieuse lorsqu'un client ne souhaite pas modifier une application principale au cours d'une période d'activité de l'application. Le paramétrage d'une application peut réduire les ressources nécessaires ainsi que les factures mensuelles lors de l'utilisation des nouveaux niveaux de service dans la Base de données SQL Azure.

Les nouveaux niveaux de service sont conçus pour améliorer la stabilité et la prévisibilité des performances d'une application. Cependant, certaines meilleures pratiques de paramétrage de votre application permettent de tirer un meilleur parti de la fonctionnalité. Alors que de nombreuses applications verront des gains de performances significatifs simplement en passant à un niveau de service ou de performance supérieur, certaines applications n'en tireront pas parti sans paramétrage supplémentaire. Vous devez également envisager un paramétrage supplémentaire pour les applications qui présentent les caractéristiques suivantes afin d'optimiser les performances lorsque vous utilisez la Base de données SQL Azure.

  • Applications dont les performances sont altérées en raison d'un comportement « bavard »

    Cela inclut les applications qui exécutent des opérations d'accès aux données excessives et qui sont sensibles au temps de réponse du réseau. Ces applications peuvent nécessiter une modification pour réduire le nombre d'opérations d'accès aux données dans la Base de données SQL Azure. Par exemple, l'application peut être améliorée en utilisant des techniques, telles que le traitement par lot des requêtes ad hoc ou le déplacement des requêtes dans des procédures stockées. Pour plus d'informations, consultez la section Traitement par lot des requêtes qui suit.

  • Les bases de données avec une charge de travail intensive qui ne peut pas être prise en charge par un seul ordinateur

    Les bases de données qui dépassent les ressources du niveau de performance Premium le plus élevé ne sont pas conseillées. Ces bases de données peuvent tirer parti de la montée en puissance parallèle de la charge de travail. Pour plus d'informations, consultez les sections Partitionnement de bases de données croisées et Partitionnement fonctionnel qui suivent.

  • Applications qui contiennent des requêtes non optimales

    Les applications, en particulier dans la couche d'accès aux données, qui ont des requêtes mal paramétrées risquent de ne pas tirer parti d'un niveau de performance supérieur comme prévu. Cela inclut les requêtes dans lesquelles la clause WHERE est manquante, qui ont des index manquants ou des statistiques obsolètes. Ces applications bénéficieront de techniques standard de paramétrage des performances des requêtes. Pour plus d'informations, consultez les sections Index manquants et Analyse/Compréhension de requête qui suivent.

  • Applications dont la conception de l'accès aux données n'est pas optimale

    Les applications qui rencontrent des problèmes intrinsèques de concurrence d'accès aux données, par exemple un interblocage, ne peuvent pas tirer parti d'un niveau de performance supérieur. Les développeurs d'applications doivent envisager de réduire les boucles sur la Base de données SQL Azure en mettant en cache les données côté client à l'aide du service Caching d'Azure ou d'autres technologies de mise en cache. Consultez la section Caching de la couche Application qui suit.

Cette section explique quelques techniques que vous pouvez utiliser pour paramétrer une Base de données SQL Azure afin d'obtenir des performances optimales de votre application et de pouvoir l'exécuter au niveau de performance le plus bas possible. Plusieurs techniques correspondent aux meilleures pratiques de paramétrage traditionnelles de SQL Server, mais certaines sont spécifiques de la Base de données SQL Azure. Dans certains cas, les techniques SQL Server traditionnelles peuvent être étendues à la Base de données SQL Azure en examinant les ressources utilisées pour qu'une base de données trouve des zones à paramétrer plus finement.

Un problème commun lié aux performances de base de données OLTP concerne la conception de la base de données physique. Les schémas de base de données sont souvent conçus et fournis sans réaliser de test à l'échelle (de charge ou de volume des données). Malheureusement, les performances d'un plan de requête peuvent être acceptables à petite échelle, mais se dégrader considérablement avec des volumes de données au niveau production. La cause la plus courante de ce problème est le manque d'index appropriés pour satisfaire des filtres ou d'autres restrictions dans une requête. Souvent, cela se manifeste en tant qu'analyse de table lorsqu'une recherche d'index suffit.

L'exemple suivant crée un cas où le plan de requête sélectionné contient une analyse lorsqu'une recherche suffit :

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO dbo.missingindex(col2) VALUES (@a);
    SET @a += 1;
END
COMMIT TRANSACTION;
GO
SELECT m1.col1 
FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1) 
WHERE m1.col2 = 4;


LA Base de données SQL Azure contient des fonctionnalités qui aident les administrateurs de base de données à rechercher et résoudre les conditions courantes d'index manquant. Les vues de gestion dynamique (DMV) intégrées dans la Base de données SQL Azure examinent la compilation de requête où un index réduit de manière significative le coût estimé pour l'exécution d'une requête. Pendant l'exécution de requête, il suit la fréquence à laquelle chaque plan de requête est exécuté, ainsi que l'intervalle estimé entre l'exécution du plan de requête et du plan imaginé dans lequel cet index existait. Cela permet à un administrateur de base de données de déterminer rapidement les modifications de conception de base de données physique qui peuvent améliorer le coût global de la charge de travail d'une base de données donnée et sa charge de travail réelle.

La requête suivante peut être utilisée pour évaluer les index manquants potentiels.

SELECT CONVERT (varchar, getdate(), 126) AS runtime, 
    mig.index_group_handle, mid.index_handle, 
    CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * 
            (migs.user_seeks + migs.user_scans)) AS improvement_measure, 
    'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + 
              CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + ' 
              (' + ISNULL (mid.equality_columns,'') 
              + CASE WHEN mid.equality_columns IS NOT NULL 
                          AND mid.inequality_columns IS NOT NULL 
                     THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '')
              + ')' 
              + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
    migs.*, 
    mid.database_id, 
    mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
INNER JOIN sys.dm_db_missing_index_group_stats AS migs 
    ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid 
    ON mig.index_handle = mid.index_handle
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

Dans cet exemple, l'index suivant est suggéré :

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])

Une fois créée, cette même instruction SELECT sélectionne un autre plan qui utilise une recherche au lieu d'une analyse, exécutée plus efficacement comme l'indique le plan de requête suivant.

L'analyse principale est que la capacité d'E/S d'un système partagé est généralement plus limitée que celle d'un ordinateur serveur dédié. Ainsi, il est particulièrement important de réduire les E/S inutiles afin de tirer le meilleur parti du système à l'intérieur de la DTU de chaque niveau de performance des nouveaux niveaux de service dans la Base de données SQL Azure. Des choix appropriés de conception de base de données physique peuvent améliorer de manière significative la latence des requêtes individuelles, le débit des demandes simultanées que vous pouvez traiter par unité d'échelle, et réduire les coûts nécessaires pour satisfaire la requête. Pour plus d'informations sur les vues de gestion dynamique des index manquants, consultez sys.dm_db_missing_index_details.

L'optimiseur de requête dans la Base de données SQL Azure est très similaire à l'optimiseur de requête traditionnel SQL Server. Nombre des meilleures pratiques de paramétrage des requêtes et de compréhension des limitations du modèle de raisonnement pour l'optimiseur de requête s'appliquent également à la Base de données SQL Azure. Le paramétrage des requêtes dans la Base de données SQL Azure peut comporter l'avantage supplémentaire de réduire les besoins de ressources globales et de permettre l'exécution d'une application à un coût inférieur à celui d'une application équivalente non paramétrée, car elle s'exécute à un niveau de performance inférieur.

Un exemple classique vu dans SQL Server qui s'applique également à la Base de données SQL Azure concerne la façon dont les paramètres sont surveillés pendant la compilation pour essayer de créer un plan plus optimal. La détection de paramètres est un processus au moyen duquel l'optimiseur de requête tient compte de la valeur actuelle d'un paramètre lors de la compilation d'une requête dans l'espoir de générer un plan de requête plus optimal. Bien que cette stratégie mène souvent à un plan de requête beaucoup plus rapide qu'un plan compilé sans connaissance des valeurs de paramètre, le comportement actuel de SQL Server/Base de données SQL Azure est imparfait. Il existe des cas où le paramètre est surveillé, mais où le plan généré n'est pas optimal pour l'ensemble des valeurs de paramètre dans une charge de travail. Microsoft inclut des indicateurs de requête (directives) pour permettre au client de spécifier l'intention plus délibérément et remplacer le comportement par défaut de détection de paramètres. Souvent, l'utilisation d'indicateurs résout les cas où le comportement par défaut de SQL Server/Base de données SQL Azure est imparfait pour la charge de travail d'un client donné.

L'exemple suivant montre comment le processeur de requêtes peut générer un plan non optimal pour les besoins en performances et ressources, et comment l'utilisation d'un indicateur de requête peut réduire le temps d'exécution des requêtes et les besoins en ressources sur une Base de données SQL Azure.

Exemple de configuration :

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));

DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO psptest1(col2) values (1);
    INSERT INTO psptest1(col2) values (@a);
    SET @a += 1;
END
COMMIT TRANSACTION
CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 
    WHERE col2 = @param1
    ORDER BY col2;
END
GO

CREATE PROCEDURE psp2 (@param2 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
    ORDER BY col2
    OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
END
GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

Le code de configuration crée une table qui contient une distribution des données décalée. Le plan de requête optimal diffère selon le paramètre sélectionné. Hélas, le comportement de caching du plan ne recompile pas toujours la requête en fonction de la valeur de paramètre la plus courante. Cela signifie qu'il est possible qu'un plan non optimal soit mis en cache et utilisé pour plusieurs valeurs, même lorsqu'un autre plan constitue un meilleur choix de plan moyen. Il crée ensuite deux procédures stockées qui sont identiques, excepté que l'une d'elles contient un indicateur de requête spécial (raisonnement expliqué ci-dessous).

Exemple (première partie) :

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp1 @param1=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END

Exemple (deuxième partie - patientez 10 minutes avant de tester cette partie de façon à ce qu'elle soit manifestement différente dans les données de télémétrie obtenues) :

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp2 @param2=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END


Chaque partie de cet exemple tente d'exécuter une instruction paramétrable d'insertion 1 000 fois (pour générer une charge suffisante pour être intéressante sur un jeu de données de test). Lors de l'exécution des procédures stockées, le processeur de requêtes examine la valeur de paramètre passée à la procédure lors de sa première compilation (détection de paramètres). Le plan obtenu est mis en cache et utilisé pour les appels ultérieurs, même si la valeur de paramètre est différente. Par conséquent, le plan optimal ne peut pas être utilisé dans tous les cas. Parfois les clients doivent guider l'optimiseur pour choisir un plan plus adapté pour le cas moyen plutôt que le cas spécifique lorsque la première requête a été compilée. Dans cet exemple, le plan initial va générer un plan d'« analyse » qui lit toutes les lignes afin de rechercher toutes les valeurs qui correspondent au paramètre :

Étant donné que nous avons exécuté la procédure avec la valeur 1, le plan obtenu était optimal pour cette valeur, mais non optimal pour toutes les autres valeurs de la table. Le comportement obtenu n'est probablement pas le comportement souhaité si le client choisit chaque plan de façon aléatoire, car le plan sera plus lent et utilisera plus de ressources pour l'exécution.

L'exécution du test avec l'option « SET STATISTICS IO ON » expose le travail d'analyse logique effectué dans cet exemple en arrière-plan. Vous pouvez constater qu'il y a 1 148 lectures effectuées par le plan (ce qui est inefficace si le cas moyen consiste à retourner une seule ligne) :

La deuxième partie de l'exemple utilise un indicateur de requête pour indiquer à l'optimiseur d'utiliser une valeur spécifique lors du processus de compilation. Dans ce cas, il force le processeur de requêtes à ignorer la valeur passée comme paramètre et suppose à la place une valeur « UNKNOWN », ce qui signifie une valeur qui a la fréquence moyenne dans la table (en ignorant le décalage). Le plan obtenu est un plan basé sur la recherche qui est plus rapide et utilise moins ressources, en moyenne, que le plan de la première partie de l'exemple :

L'impact de ce comportement peut être observé en examinant la table sys.resource_stats (remarque : il y aura un délai entre l'exécution du test et le moment où les données seront renseignées dans la table). Pour cet exemple, la première partie est exécutée pendant la fenêtre de temps 22:25:00 et la deuxième partie est exécutée à 22:35:00. Notez que la fenêtre temporelle précédente a utilisé plus de ressources que la dernière (en raison de l'amélioration de l'efficacité du plan).

SELECT TOP 1000 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

ImportantImportant
Alors que la taille de l'exemple est petite, l'impact des paramètres non optimaux peut être substantiel, notamment sur les bases de données de grande taille. La différence, dans les cas extrêmes, peut se traduire en secondes et en heures pour les cas rapides et lents.

Les clients peuvent consulter sys.resource_stats pour déterminer si les ressources utilisées pour un test donné sont plus ou moins importantes que pour un autre test. Lorsque vous comparez les données, faites des tests suffisamment espacés dans le temps de façon à ce qu'ils ne soient pas regroupés dans la même fenêtre temporelle de cinq minutes dans la vue sys.resource_stats. En outre, notez que l'objectif de l'exercice est de réduire les ressources totales utilisées, pas de réduire les ressources maximales. En général, l'optimisation d'une partie du code pour la latence permet également de réduire la consommation de ressources. Veillez à ce que les modifications prises en compte dans une application soient réellement nécessaires et n'aient pas un impact négatif sur l'expérience utilisateur lors de l'utilisation d'une application avec des indicateurs de requête.

Si une charge de travail contient un ensemble de requêtes répétitives, il est souvent judicieux de capturer et valider l'optimalité de ces choix de plan, car elle entraînera probablement l'unité de taille minimale de ressource requise pour héberger la base de données. Une fois validés, le réexamen occasionnel de ces plans peut vous assurer qu'ils ne se sont pas dégradés. Pour plus d'informations sur les indicateurs de requête, consultez Indicateurs de requête (Transact-SQL).

Étant donné que la Base de données SQL Azure s'exécute sur du matériel de base, il existe des limites de capacité inférieures pour une seule base de données par rapport à une installation traditionnelle locale de SQL Server. Ainsi, plusieurs clients utilisent des techniques de partitionnement pour répartir les opérations de base de données sur plusieurs bases de données lorsqu'elles ne s'inscrivent pas dans les limites d'une seule base de données dans Base de données SQL Azure. La plupart des clients qui utilisent les techniques de partitionnement sur la Base de données SQL Azure fractionnent leurs données dans une seule dimension sur plusieurs bases de données. L'approche implique de comprendre que souvent les applications OLTP exécutent des transactions qui s'appliquent à une seule ligne ou à un petit groupe de lignes dans le schéma. Par exemple, si une base de données contient le client, la commande et les détails de la commande (tel que l'illustre l'exemple de base de données Northwind fournie avec SQL Server), ces données peuvent être fractionnées dans plusieurs bases de données en regroupant un client avec la commande associée et les informations sur la commande et en garantissant qu'elles restent dans une seule base de données. L'application fractionne différents clients entre les bases de données, en répartissant efficacement la charge sur plusieurs bases de données. Cela permet aux clients d'éviter la limite de taille maximale de base de données, mais permet également à la Base de données SQL Azure de traiter les charges de travail qui sont beaucoup plus volumineuses que les limites des différents niveaux de performance aussi longtemps que chaque base de données correspond à sa DTU.

Alors que le partitionnement de base de données ne permet pas de réduire la capacité des ressources globales pour une solution, cette technique est très efficace pour prendre en charge des solutions de très grande taille réparties sur plusieurs bases de données, et permet à chaque base de données de s'exécuter à un niveau de performance distinct pour prendre en charge des bases de données « efficaces » de très grande taille qui exigent des ressources importantes.

Les utilisateurs de SQL Server associent souvent plusieurs fonctions dans une seule base de données. Par exemple, si une application contient la logique pour gérer l'inventaire d'un magasin, cette base de données peut contenir la logique associée à l'inventaire, au suivi des bons de commande, aux procédures stockées et vues indexées/matérialisées qui gèrent la création de rapports en fin de mois et d'autres fonctions. Cette technique offre l'avantage de pouvoir gérer facilement la base de données pour des opérations telles que BACKUP, mais elle nécessite également que le client dimensionne le matériel pour gérer la charge maximale de toutes les fonctions d'une application.

Dans une architecture de montée en puissance parallèle utilisée à l'intérieur d'une Base de données SQL Azure, il est souvent bénéfique de fractionner différentes fonctions d'une application en différentes bases de données. Cela permet la mise à l'échelle de chacune d'elles indépendamment. À mesure qu'une application devient plus occupée (et reçoit plus de charge sur la base de données), cela permet à l'administrateur de choisir des niveaux de performance indépendants pour chaque fonction d'une application. Dans la limite, cette architecture permet à une application de prendre plus d'envergure que celle qu'un seul ordinateur peut gérer en répartissant la charge sur plusieurs ordinateurs.

Pour les applications qui accèdent aux données sous la forme de requêtes ad hoc fréquentes et élevées, une grande partie du temps de réponse est consacrée à la communication réseau entre le niveau de l'application et le niveau de Base de données SQL Azure. Même si l'application et la Base de données SQL Azure résident dans le même centre de données, le temps de réponse du réseau entre les deux peut être accru par un nombre élevé d'opérations d'accès aux données. Pour réduire les boucles réseau de ces opérations d'accès aux données, le développeur d'applications doit tenir compte des options de mise en lots des requêtes ad hoc ou de compilation dans des procédures stockées. Une mise en lots des requêtes ad hoc peut envoyer plusieurs requêtes sous la forme d'un grand lot en un seul envoi à la Base de données SQL Azure. La compilation des requêtes ad hoc dans une procédure stockée permet d'obtenir le même résultat que le traitement par lot. Une procédure stockée vous permet également d'augmenter les possibilités de mise en cache des plans de requête dans la Base de données SQL Azure pour les exécutions suivantes de la même procédure stockée.

Certaines applications sont gourmandes en écriture. Parfois, il est possible de réduire la charge d'E/S totale sur une base de données en envisageant de traiter les écritures par lot. Cela revient à utiliser des transactions explicites plutôt que des transactions de validation automatique dans les procédures stockées ou les lots ad hoc. Une évaluation des différentes techniques pouvant être utilisées est disponible dans Techniques de traitement par lot pour les applications de Base de données SQL dans Azure. Mettez cela en pratique avec votre propre charge de travail pour découvrir le modèle approprié pour le traitement par lot, en prenant soin de comprendre qu'un modèle donné peut offrir des garanties de cohérence transactionnelle légèrement différentes. Pour finir, déterminer la charge de travail qui réduit l'utilisation des ressources exige de trouver la bonne combinaison entre cohérence et performances.

Certaines applications de base de données ont des charges de travail qui comportent beaucoup de lectures. Il est possible d'utiliser les couches de mise en cache pour réduire la charge sur la base de données et réduire éventuellement le niveau de performance nécessaire pour prendre en charge une base de données à l'aide de la Base de données SQL Azure. Caching de Azure (Caching) permet à un client, avec une charge de travail comportant beaucoup de lectures, de lire les données une fois (ou peut-être une fois par ordinateur de niveau Application, selon la façon dont il est configuré) et de stocker ces données en dehors de la Base de données SQL Azure. Cela permet de réduire la charge de la base de données (UC et E/S de lecture), mais il y a un impact sur la cohérence transactionnelle, car les données lues dans le cache peuvent être obsolètes par rapport aux données de la base de données. Bien qu'il existe de nombreuses applications dans lesquelles des incohérences sont acceptables, ce n'est pas le cas pour toutes les charges de travail. Assurez-vous de comprendre la configuration requise pour une application avant d'utiliser une stratégie de mise en cache de la couche Application.

L'Introduction des nouveaux niveaux de service dans la Base de données SQL Azure permet aux clients de placer la barre plus haut sur les types d'applications qu'ils génèrent dans le cloud. Lorsqu'il est associé au paramétrage d'application, les clients peuvent obtenir des performances puissantes et prédictibles pour leur application. Ce document décrit les techniques recommandées pour optimiser la consommation de ressources d'une base de données pour l'adapter correctement à l'un des nouveaux niveaux de performance. Le paramétrage est un exercice continu dans le modèle de cloud, et les nouveaux niveaux de service ainsi que leurs niveaux de performance permettent aux administrateurs d'optimiser les performances tout en réduisant les coûts sur la plateforme Microsoft Azure.

Voir aussi

Afficher:
© 2014 Microsoft