Azure Table Storage et SQL Data Services

L’offre “cloud” de Microsoft en ce qui concerne les données est composée de deux services :  Azure Storage et SQL Data Services (SDS). Je me suis interrogé sur leurs possibilités perspectives, voici le résultat de mes recherches.

Azure Storage

Je ne parle ici que de la partie “Table Storage”,  Azure comprenant aussi un stockage par Blob et “Message Queue”.

• Accès par api REST et requête authentifiée (shared key)
• C’est en fait une version modifiée d’ADO.NET Data Services (Astoria)
• Clé primaire d’une entité est composée d’une Row Key et d’une Partition Key : row key étant l’id  de l’entité tandis que la partition key  permet un regroupement d’entité pour une répartition de la charge.
• Les associations ne sont pas supportées
• les propriétés sont de type simple avec GUID, DateTime en plus
• On peut aussi utiliser la librairie cliente de ADO .NET Data Services pour accéder aux entités mais avec des restrictions : pas d’opérations sur les associations (addLink, Expand), pas d’opération en batch, les updates sont effectués un par un. Seul les opérateurs Where, Select, Take, First sont supportés.
• Merge = mise à jour des propriétés non nulles / Update = remplacement complet de l’entité
• Gestion de l’accès concurrent optimiste : comparaison de l’ETag
• En développement, Outil de VS qui permet de créer les tables par introspection dans SQL Server,la fabrique faisant façade avec notre code

SDS – SQL Data Services

C’est la solution plus orientée “Entreprise”.

• Accès REST ou SOAP
• Le modèle se divise en 3 niveaux : 1 Autorité (= dns, géolocalisation du datacenter) > x container > y entités
• Le container peut référencer des entités de même type (orientation 1 container = 1 table) ou des entités de types différents (1 container = x tables, une base de données)
• Le choix entre les deux est “vite fait’ , les requêtes (recherche et update notamment) ne sont pas transverses aux containers, donc si on veut gérer des associations on doit choisir la deuxième orientation
• une entité a des metadata : Id, Version (gestion de l’accès concurrent) et Kind (son type)
• Opérateur de jointure supporté (mais pas de contrainte de clé étrangère), exemple ici entre customer et order

from c in entities where c.Kind==“Customer” where c[“Name”] == “Customer 1” from o in entities where o.Kind==“Order” where o[“CustomerId”] == c.Id select o

• Opérateur Take() et OrderBy sont aussi présents