Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SQL Azure : Une "suite" à ma session du jour avec quelques bonnes pratiques.

SQL Azure a le très gros avantage d'avoir un prix mensuel basé sur la taille de base de données maximale (Web ou Business) sans pour le moment avoir de différentiations de fonctionnalité entre elles.

La seconde composante de la facturation est le volume de données réseau IN (les requêtes) et OUT (les données).

En se basant la dessus, on peut en déduire que :

  • Quel que soit la performance de la requête, son "prix" n'en est pas affecté (pas de facturation par IO ou CPU :o)… Ce n'est pas pour autant qu'il ne faut pas optimiser les requêtes, le temps d'exécution en dépend fortement !
  • Les mises à jour de données, ne coutent que l'envoie d'un paquet en IN, leur coût peut être considéré comme négligeable, du coup ne pas hésiter à dé-normaliser les données après leur chargement sur la base de données Azure. D'une manière généralement on chargera des données les plus atomiques possibles (très normalisées) pour limiter les redondances et les coûts
  • On peut jouer sur la taille du paquet réseau, dans la chaîne de connexion (ou outils clients) pour diminuer le volume IN et OUT et donc le coût.
  • On passera de préférence par des procédures stockées… Cela limiter le volume entrant et se limiter au nom de la procédure et les valeurs de ses paramètres, et pour des questions de sécurité (voir plus loin).
  • On limite au strict minimum les aller / retour vers Azure en
    • Évitant les PRINT et surtout les RAISERROR WITH NOWAIT
    • En mettant SET NOCOUNT ON en début de code (évite les x records affecte après chaque requête)
    • En minimisant le nombre de lot lorsque c'est possible (GO dans Management Studio, et SqlCommand distant en .Net)
  • On limite systématiquement le jeu de données en retour via un SELECT TOP (x) FROM …
  • Utilisez Houston (https://www.sqlazurelabs.com/)... En fait le traffic intra Azure n'est pas facturé… Donc une requête exécutée depuis Houston est Gratuite (90% sûr j'attends quand même une confirmation, c'est au moins temporairement le cas)

Cela demande jongler un petit peu avec les règles « classiques » du SQL Server « normal ». C'est d'ailleurs ce que fait implicitement Management Studio (SSMS) il n'y a pas autant de richesse dans l'interface lorsque vous êtes connecté sur Azure et SSMS choisi de vous présenter le modèle de script au lieu des boîtes de dialogues classiques, qui requêtes énormément les vues systèmes et vues dynamiques ce qui gonflerait le coût.

En termes de sécurité si les applications ne sont pas hébergées dans le Cloud, il faut faire très attentions aux permissions et accès fait à cette instance.

On veillera à :

  • Limiter les plages d'IP au strict minimum, sauf grand besoin
  • La plateforme Azure se charge de protéger l'instance contre les attaques, toutes tentatives répétées et échoues d'accès risques de suspendre l'accès de votre IP à SQL Azure, attention au mauvais mot de passe !
  • Changer les mots de passe régulièrement si cela est possible et créer des Logins distant par utilisateurs application pour bien identifier les accès.
  • Passer par des procédures stockées et des vues pour les accès fait par l'application
    • Cela vous laisse la possibilité de limiter les données en retour (TOP)
    • Cela évite les requêtes longues en entrée
    • Et cela permet d'interdire l'exécution de code arbitraire sur le serveur, si on vole un des mots de passe.

Ce qui donne par exemple :

-- On master db

CREATE LOGIN x WITH PASSWORD = 'abc'

-- On your user database

CREATE USER x FROM LOGIN x

GRANT SELECT TO x ON maVue

GRANT EXEC TO x

DENY INSERT, DELETE, UPDATE, SELECT TO x ON maTable

Cela fonctionne parfaitement sur les propriétaires des tables, des vues et des procédures stockées sont identiques (très courant).

Pour migrer une base de données vers Azure, on pourra :

    • Non supporté officiellement par MS, vérifiez bien les scripts avant de les exécuter sur votre instance Azure
  • Utiliser DAC (Data Tier Application Component)
    • Fonctionne bien, mais sans les données, et sauf si vous utilisez des fonctionnalités arrivées dans Azure depuis sa sortie (type SQLCLR, comme le type geometry et geography)
  • Générer le schéma de base de données
    • Données possibles, mais très verbeuse (un int consommera jusqu'à 5 fois sa taille :o( Généralement non conseillé.
    • Pensez à nettoyer le script résultant
      • Référence aux groupes de fichiers
      • Clause WITH (CREATE INDEX entre autres)
  • Importer / Exporter les données
    • Via bcp.exe, non trivial mais le plu efficace avec son format natif sur des gros volume de données… Pensez à mettre un maximum de ligne par batch pour des questions performance.
  • SSIS (Integration Services)
    • Permet de combiner les 2 étapes précédentes, mais c'est à vous d'y mettre les scripts de création de schéma
    • Le chargement de données se révèlera plus simple !

On oublie sur SQL Azure la gestion du serveur et le concept de base de données sur la même instance… Même si elles sont présentées sur la même instance, ces dernières peuvent être physiquement séparées. C'est pourquoi il n'y a pas de requêtes inter base de données possibles et qu'il faut systématiquement se connecter sur la bonne base de données (USE non supporté).

Attention à quelques fonctions clefs actuellement manquantes sur SQL Azure

  • Pas d'alertes
    • C'est donc à vous de gérer la taille des bases de données et l'approche de la limite maximale, faute de quoi les requêtes en écritures échoueront
  • Pas de restauration dans le temps des bases de données
    • Ce qui peut se révéler très gênant en cas d'erreur humaine pour revenir en arrière… Pour pallier au manque de backup il est possible de créer des copies manuelles de bases de données (CREATE DATABASE x AS COPY OF y)… Attention à la facturation !
  • Certaines fonctionnalités absentes telles que
    • Service Broker
    • Full Text Search
  • SSMS / Houston
    • Moindre richesse de l'interface graphique, ce qui fait que certaines opérations ne peuvent se faire que par script
  • Pas de jobs / batch
    • On "tricher" en utilisant une machine tierce comme planificateur.
  • Absence de fonction évoluée de synchronisation tel que le CHANGE_TRACKING
    • On utilisera le timestamp ou des triggers mettant à jour une date comme solution de remplacement
  • Suivi de la facturation par base de données (sys.bandwidth_usage / sys.database_usage)
    • Si vous souhaitez suivre l'activité pour des clients hébergé sur Azure il faudra pour le moment les mettre dans des bases de données séparées faute de quoi le suivi (bande passante) n'est pas possible.
  • Pas de tailles de bases de données de plus de 50 Go
    • Obligation de multiplier les bases de données pour un plus grand volume
  • Pas de partitionnement, pas de compression des données natives, etc.

L'équipe produit travaille activement pour ajouter les fonctionnalités dans les mises à jour d'Azure. Je ne peux pas présumer de ce qu'il y aura à l'avenir, mais il est probable qu'une partie des fonctionnalités ci-dessus soient supportés à moyen terme.

Dernier point, pour essayer Azure, je vous conseille l'offre suivante (jusqu'à ce mois ci uniquement) :

Ou si vous êtes abonné MSDN, l'offre suivante :

Petit rappel des avantages de la solution SQL on the cloud :

  • Coût / Facturation à l'usage : à comparer au coût par CPU en mode Web
  • Haute disponibilité incluse : à mettre en rapport avec la taille de l'équipe à constituer et le matériel à utiliser
  • Plusieurs datacenter possibles, en multipliant les abonnements : latence faible
  • Accès avec un simple accès Internet : Pas de VPN ou accès Remote complexe

Cela en fait une solution optimale pour les petites et moyennes entreprises. Et de plus, pour des applications moyenne ou petite nécessitant d'être en ligne constamment, avec au besoin un faible temps de latence, la solution Azure se révèle aussi très avantageuse !

Voilà je pense avoir fait le tour de la question. Toute remarque, suggestion ou question est la bienvenue tant les questions sur cette édition de SQL Server sont nombreuses.

Bon azure...

EDIT : Pour les sync groups j'ai eu la réponse, si les bases de données à synchroniser sont dans le même DataCenter pas de coût additionnels facturés. Par contre si les bases de données sont sur des DataCenters distincts, des coûts de transfert de données sont facturés sur la bases classique du traffic SQL Azure.

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Publié jeudi 14 octobre 2010 21:43 par christian
Classé sous : ,

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01