SQL Data Services ou le stockage de vos données dans le cloud

Par Pascal Belaud, Relation Technique Développeurs chez Microsoft France.

Présentation

SQL Services est une brique d'Azure Services Platform, qui s'appuie sur Windows Azure.

Au sein de SQL Services, SQL Data Services représente la partie données, le reste étant le reporting et l'analyse dimensionnelle. Il s'agit de SQL Server, d'ailleurs à l'origine le nom était SQL Server Data Services ou SSDS.

Comme pour le reste d'Azure, l'intérêt est de pouvoir utiliser des ressources à la demande sans se soucier de l'investissement et de la gestion.

Dans Windows Azure il y a déjà Windows Azure Storage qui permet de stocker basiquement des informations (un peu comme un file system) dans des tables. SQL Data Services ajoute les services orientés base de données, notamment le relationel et le reporting.

Principe

Trois pilliers:

• on peut stocker tout type de données
• services de traitement de données évolués
• excellence opérationnelle: sécurisé, sauvegardé, redondance

Du coup SDS offre: montée en charge, réplication géographique, prix compétitif, confidentialité des données.

Il y a deux parties:

• front-end, avec 2 interfaces: REST et SOAP.
• back-end (stockage): cluster de données (nos données) et master cluster, pour être sûrs de ne pas perdre les données.

Modèle de données: ACE

• Authority: vous, elle est associée à un nom DNS et possède une collection de Containers.
• Container: unité de consistance pour les données, par exemple "factures". On pourrait dire Container=Table. Un container est le scope pour les requêtes. Un container contient des Entités.
• Entity: paire name/value. Pas de schéma obligatoire. Cette approche simple permet notamment de simplifier le versionning (exemple: ajout de champ).

Démonstration avec REST

Le fichier de configuration contient dans appSettings 4 paramètres d'identification de l'autorité.

On invoque en REST le SDS pour créer une autorité, des containers puis une entité.

Pour requêter les données, on peut ajouter une requête ayant une sytaxe proche de LINQ directement dans l'URL.

Pour aller plus loin

Malgré l'absence de relations, on peut très bien faire des jointures, en utilisant la syntaxe JOIN des requêtes LINQ lors du requêtage.

Démonstration avec SOAP

SOAP permet d'avoir une approche souvent plus adaptée pour les développeurs, pour l'accès à SDS, alors que REST est plutôt pour les développeurs Web.

On appelle simplement une méthode Create sur le proxy, en lui passant un scope indiquant si c'est une autorité, un container ou une entité que l'on veut créer.

Pour ajouter une propriété sur une entité, on utilise un dictionnaire (clé/valeur oblige!) que l'on passe via le proxy SOAP.

Pour mettre à jour des données, on fait strictement comme pour l'ajout, mais on appelle la méthode Update du proxy et on passe l'entité d'origine comme contexte.

Limites

• Il peut y avoir jusqu'à 10 secondes entre la création d'une entité et son apparition dans les résultats d'une requête.
• Container: 2 Go maxi.
• Entité: 2 Mo maxi.

Accès concurrentiel

Si deux clients SDS font une mise à jour simultanée, la propriété version sur chaque entité permet de s'assurer que l'on travaille bien sur la version qu'on avait avant. Il suffit donc dans le code de faire un try ... catch.