Windows Azure Table Services - Propriétés étendues et schéma de table

Question

J'ai une entité qui, en plus de quelques propriétés communes, contient une liste de propriétés étendues stockées en tant que paires (Nom, Valeur) de chaînes dans une collection. Je devrais probablement mentionner que ces propriétés étendues varient largement d'une instance à l'autre, et qu'elles doivent seulement être listées pour chaque instance (il n'y aura pas de requêtes sur les propriétés étendues, par exemple trouver toutes les instances avec un nom particulier Valeur) paire). J'explore comment je pourrais persister cette entité en utilisant Windows Azure Table Services. Avec l'approche particulière que je suis en train de tester, je suis préoccupé par le fait qu'il peut y avoir une dégradation des performances au fil du temps, car des noms de propriété étendus plus distincts sont rencontrés par l'application. Si je stockais cette entité dans une base de données relationnelle typique, j'aurais probablement deux tables pour supporter ce schéma: la première contiendrait l'identificateur d'entité et ses propriétés communes, et la seconde référencerait l'identificateur d'entité et utiliserait Modélisation de lignes de style EAV pour stocker les paires étendues (Name, Value), une à chaque ligne.

Étant donné que les tables dans Windows Azure utilisent déjà un modèle EAV, j'envisage la sérialisation personnalisée de mon entité afin que les propriétés étendues soient stockées comme si elles avaient été déclarées au moment de la compilation de l'entité. Je peux utiliser les événements Entité de lecture et d'écriture fournis par DataServiceContext pour accomplir ceci.

private void OnReadingEntity(object sender, ReadingWritingEntityEventArgs e) 
{ 
    MyEntity Entry = e.Entity as MyEntity; 

    if (Entry != null) 
    { 
     XElement Properties = e.Data 
      .Element(Atom + "content") 
      .Element(Meta + "properties"); 

     //select metadata from the extended properties 
     Entry.ExtendedProperties = (from p in Properties.Elements() 
          where p.Name.Namespace == Data && !IsReservedPropertyName(p.Name.LocalName) && !string.IsNullOrEmpty(p.Value) 
          select new Property(p.Name.LocalName, p.Value)).ToArray(); 
    } 
} 

private void OnWritingEntity(object sender, ReadingWritingEntityEventArgs e) 
{ 
    MyEntity Entry = e.Entity as MyEntity; 

    if (Entry != null) 
    { 
     XElement Properties = e.Data 
      .Element(Atom + "content") 
      .Element(Meta + "properties"); 

     //add extended properties from the metadata 
     foreach (Property p in (from p in Entry.ExtendedProperties 
           where !IsReservedPropertyName(p.Name) && !string.IsNullOrEmpty(p.Value) 
           select p)) 
     { 
      Properties.Add(new XElement(Data + p.Name, p.Value)); 
     } 
    } 
} 

Cela fonctionne, et que je peux définir les exigences pour les noms de propriété étendue et les valeurs, je peux assurer qu'ils sont conformes à toutes les exigences standard pour les propriétés de l'entité dans un tableau Windows Azure.

Alors, que se passe-t-il au fil du temps lorsque l'application rencontre des milliers de noms de propriétés étendues différents?

Voici ce que j'ai observé dans l'environnement de stockage de développement :

• Le schéma de table de conteneurs augmente avec chaque nouveau nom. Je ne suis pas sûr exactement comment ce schéma est utilisé (probablement pour le prochain point), mais évidemment ce document XML pourrait devenir assez grand au fil du temps. Chaque fois qu'une instance est lue, le fichier XML transmis à OnReadingEntity contient des éléments pour chaque nom de propriété jamais stocké pour toute autre instance (pas seulement ceux stockés pour l'instance particulière en cours de lecture). Cela signifie que la récupération d'une entité deviendra plus lente avec le temps.

Dois-je attendre ces comportements dans l'environnement de stockage de la production ? Je peux voir comment ces comportements seraient acceptables pour la plupart des tables, car le schéma serait essentiellement statique au fil du temps. Peut-être que les tableaux Windows Azure n'ont pas été conçus pour être utilisés comme ça? Si oui, je vais certainement devoir changer d'approche. Je suis également ouvert aux suggestions sur d'autres approches.

Answer 1

Le stockage de développement utilise SQL Express pour simuler le stockage de table de cloud. Ignorez ce que vous voyez là-bas ... le système de stockage de production ne stocke aucun schéma, donc il n'y a pas de surcharge pour avoir beaucoup de propriétés uniques dans une table.