Windows Azure的表服务 - 扩展属性和表模式 [英] Windows Azure Table Services - Extended Properties and Table Schema
问题描述
我有，除了一些常见的属性，包含存储为（名称，值）对的集合中的字符串的扩展属性列表的实体。我也许应该指出，这些扩展性能广从实例各不相同的实例，他们只需要列出每个实例（不会有任何疑问，在扩展性能，例如寻找与特定的所有实例（名称，值）对）。我探索我可能会如何使用Windows Azure的表服务坚持这个实体。随着特定的方法，现在我测试，我担心可能有性能下降随着时间的推移更加明显扩展属性名称由应用中遇到的。
I have an entity that, in addition to a few common properties, contains a list of extended properties stored as (Name, Value) pairs of strings within a collection. I should probably mention that these extended properties widely vary from instance to instance, and that they only need to be listed for each instance (there won't be any queries over the extended properties, for example finding all instances with a particular (Name, Value) pair). I'm exploring how I might persist this entity using Windows Azure Table Services. With the particular approach I'm testing now, I'm concerned that there may be a degradation of performance over time as more distinct extended property names are encountered by the application.
如果我是在一个典型的关系型数据库中存储这个实体，我可能有两个表来支持这种模式：第一次将包含实体标识符和它的公共属性，第二个将引用实体标识符，并使用EAV风格行建模一个存储扩展（名称，值）对，每一行。
If I were storing this entity in a typical relational database, I'd probably have two tables to support this schema: the first would contain the entity identifier and its common properties, and the second would reference the entity identifier and use EAV style row-modeling to store the extended (Name, Value) pairs, one to each row.
由于Windows Azure的表已经使用EAV模型，我在考虑我的实体的自定义序列化，这样的扩展属性存储，就像它们在编译时为实体声明。我可以使用的 DataServiceContext 做到这一点。
Since tables in Windows Azure already use an EAV model, I'm considering custom serialization of my entity so that the extended properties are stored as though they were declared at compile time for the entity. I can use the Reading- and Writing-Entity events provided by DataServiceContext to accomplish this.
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));
}
}
}
这工作，因为我可以定义扩展属性的名称和值的要求，我可以保证它们符合一个Windows Azure的表内实体属性的所有标准要求。
This works, and since I can define requirements for extended property names and values, I can ensure that they conform to all the standard requirements for entity properties within a Windows Azure Table.
所以，随着时间的推移会发生什么情况的应用程序遇到数千种不同的扩展属性的名称？
So what happens over time as the application encounters thousands of different extended property names?
下面是我内观察到什么的发展的存储环境：
Here's what I've observed within the development storage environment:
-
表容器架构的增长，每个新的名称。我不知道这个模式究竟是如何使用的（可能是下一个点），但显然这个XML文档可以随着时间的推移变得非常大。
The table container schema grows with each new name. I'm not sure exactly how this schema is used (probably for the next point), but obviously this xml document could grow quite large over time.
每当一个实例被读取，传递给OnReadingEntity XML包含永远保存为其他实例每个属性名称的元素（不只是存储特定实例的那些被读取）。这意味着一个实体的检索会随着时间的推移慢。
Whenever an instance is read, the xml passed to OnReadingEntity contains elements for every property name ever stored for any other instance (not just the ones stored for the particular instance being read). This means that retrieval of an entity will become slower over time.
我应该期待在生产的存储环境，这些行为？我能看到这些行为将如何为大多数表可以接受的，因为该模式将主要是随着时间的推移静态的。也许，Windows Azure的表的目的不是像这样被使用？如果是的话，我肯定会需要改变我的做法。我也开放给其他方法的建议。
Should I expect these behaviors in the production storage environment? I can see how these behaviors would be acceptable for most tables, as the schema would be mostly static over time. Perhaps Windows Azure Tables were not designed to be used like this? If so, I will certainly need to change my approach. I'm also open to suggestions on alternate approaches.
推荐答案
开发存储使用SQL防爆preSS模拟云表存储。不理你看看那里...生产存储系统不存储任何模式，所以没有开销有一个表中许多独特的性能。
Development storage uses SQL Express to simulate cloud table storage. Ignore what you see there... the production storage system doesn't store any schema, so there's no overhead to having lots of unique properties in a table.
这篇关于Windows Azure的表服务 - 扩展属性和表模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
