Cloud Computing @ Microsoft France

Le système d'informationset les nuages

SQL Server Data Services : le stockage dans les nuages

SQL Server Data Services : le stockage dans les nuages

  • Comments 4

Après les BizTalk Services, SilverLight Streaming, Virtual Earth, et l'Authentification Windows Live ID, Ray Ozzie vient de dévoiler un nouveau service structurel (Building Block) de l'offre de Cloud Computing de Microsoft : les SQL Server Data Services.

Les SQL Server Data Services (SSDS) permettent de stocker et interroger des données - sous un format REST et SOAP (puisque les 2 approches font du sens, merci Guillaume).

Les Data Services s'adressent aux développeurs qui veulent se concentrer sur la réalisation de leurs applications sans se soucier du déploiement, de l'administration et de la sauvegarde d'un gestionnaire de données.

You worry about writing your application and we at Microsoft worry about buying and installing the machines, running the machines, installing the software and keeping your data available for you and your customers.

Fruit de 18 mois de développement, les Data Services s'apparentent à un immense cluster de données à l'échelle de l'internet, reposant sur des milliers de serveurs Microsoft SQL Server inter-connectés (dixit Istvan).

image

Pourquoi utiliser les SQL Server Data Services ?

SSDS évite la mise en oeuvre d'une infrastructure de stockage de données tout en supportant la montée en puissance nécessaire à la bonne gestion du succès de vos applications Web. Voici quelques uns des atouts des SQL Server Data Services :

  • Robustesse garantie par le moteur SQL Server
  • Conservation des données garantie par recopie sur des clusters à géographie distincte
  • Interface d'accès via Services Web de type REST et SOAP
  • Possibilité de sécuriser les accès via SSL
  • Future politique de paiement à l'utilisation (à l'image des services Amazon)

Attention, les applications doivent supporter le fait que les temps de réponse sont très aléatoires sur Internet. De plus, si la lecture de données est optimale, les temps de latence ne font pas des Data Services un bon candidat pour des écritures intensives. Pour gérer ces aspects latences du réseau, je vous invite à suivre les travaux autour des ADO .Net Data Services (projet Astoria, actuellement en beta, version finale pour l'été) qui prévoient dans une version future de déporter ses données en local ("Take it offline") de façon automatisée (via un export vers SQL Compact et une synchronisation .Net Sync Framework).

Dans le cadre de la première version de SSDS, les applications candidates sont plutôt du type :

  • Archivage de données : typiquement de vielles données que l'on conserve uniquement pour des raisons légales (que l'on requête peu souvent, et surtout en lecture)
  • Référentiel: données de références (par exemple des catalogues produits)

Cependant, les perspectives sont intéressantes à plus long terme pour les applications liées aux Ressources Humaines, à la gestion de données confidentielles et personnelles (par exemple de type Santé), pour de l'archivage, mais encore pour des réseaux sociaux ou du stockage d'images.

Vous êtes intéressés : inscrivez-vous rapidement au programme beta, et suivez le blog SSDS de l'équipe.

Programmer les Data Services

La structure des Data Services est décrite dans cette overview, et peut se résumer dans le format

Customer { SSDS account (1..N) { Authority (1..N) { Container (0..N) { Entity (0..N) }}}}

Utilisateur { Compte SSDS (1..N) { Autorité (1..N) { Conteneur (0..N) { Entités (0..N) }}}}

En bref, un utilisateur du services possèdent des comptes (liés à la facturation et associés à un identifiant Windows Live Id) qui contiennent des lieux de stockage (autorités géo-localisés) qui abritent des conteneurs (bases qui constituent le niveau d'intégrité) qui contiennent des entités (des données)

Chaque entité a sa propre structure qui répond à un modèle Propriété - Valeur. Les valeurs sont de type simple (Nombre, Chaîne, Date, Booléen, binaire). On ne peut pas typer les entités, si bien qu'il est de la responsabilité du développeur de gérer la cohérence des données. Des meta-données sont associées et interrogeables (Identifiant, Catégorisation, Structure). Les types BLOB et XML seront supportés dans une prochaine version. L'atomicité des modifications (CRUD) est gérée au niveau de l'entité (pas au niveau des valeurs) pour le niveau le plus fin. Le niveau le plus fin de sécurité se situe au niveau du conteneur

Ce modèle, différent de celui des bases de données "à demeure", permet de monter en charge à l'échelle de l'internet.

Le requêtage s'effectue soit au travers d'un langage ("à la" Linq)

from e in entities where e[“City”] == “Seattle” && e[“State”] == “WA” select e

ou bien en mode ressource "REST like" (voilà qui devrait faire plaisir à Aurélien).

http://mydomain.ssds.Microsoft.Com/ChildrensBooksContainer1/SomeBook

Point de vue sécurité, la version courante de SQL Server Data Services se limite à proposer l'accès à un seul compte en mode Lecture/Ecriture. Il est possible de passer l'ensemble d'un conteneur en mode Read / Only.

  • Après les BizTalk Services , SilverLight Streaming , Virtual Earth , et l'Authentification Windows

  • Petit détail en passant, les modes de requêtage dits "à la LINQ" et REST ne sont pas mutuellement exclusifs et peuvent être combinés de la façon suivante, par exemple :

    https://books-docsamples.data.beta.mssds.com/v1/ChildrensBooks_REST?q='from e in entities where e["publisher"]=="Wrox" select e'

    Cheers --

  • Vous aurez certainement noté une actualité Microsoft riche autour du Cloud Computing ces dernières semaines

  • La stratégie Software+Services Microsoft s'étoffe avec le lancement de SQL Server Data Services (SSDS).

Page 1 of 1 (4 items)