У меня есть объект, который, помимо нескольких общих свойств, содержит список расширенных свойств, хранящихся в виде пар строк (Имя, Значение) в коллекции. Я должен, вероятно, упомянуть, что эти расширенные свойства широко варьируются от экземпляра к экземпляру, и что они должны быть указаны только для каждого экземпляра (не будет никаких запросов по расширенным свойствам, например, поиск всех экземпляров с определенным (Name, Value) пара). Я изучаю, как можно сохранить эту сущность с помощью служб таблиц Windows Azure. С конкретным подходом, который я сейчас тестирую, я обеспокоен тем, что со временем может произойти снижение производительности, поскольку приложение обнаруживает более отчетливые расширенные имена свойств.
Если бы я хранил этот объект в типичной реляционной базе данных, у меня, вероятно, было бы две таблицы для поддержки этой схемы: первая содержала бы идентификатор объекта и его общие свойства, а вторая содержала бы ссылку на идентификатор объекта и использовала бы строку в стиле EAV. моделирование для хранения расширенных пар (Имя, Значение), по одной в каждой строке.
Поскольку в таблицах в Windows Azure уже используется модель EAV, я рассматриваю возможность настраиваемой сериализации моей сущности, чтобы расширенные свойства сохранялись так, как если бы они были объявлены во время компиляции сущности. Я могу использовать события Reading- и Writing-Entity, предоставляемые DataServiceContext для этого.
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.
Так что же происходит со временем, когда приложение встречает тысячи различных расширенных имен свойств?
Вот что я наблюдал в среде хранения development:
Схема контейнера таблицы растет с каждым новым именем. Я не уверен, как именно эта схема используется (вероятно, для следующего пункта), но очевидно, что этот xml-документ со временем может стать довольно большим.
При чтении экземпляра xml, передаваемый в OnReadingEntity, содержит элементы для каждого имени свойства, когда-либо сохраненного для любого другого экземпляра (а не только тех, которые были сохранены для конкретного читаемого экземпляра). Это означает, что получение объекта со временем станет медленнее.
Стоит ли ожидать такого поведения в производственной среде хранения? Я вижу, насколько такое поведение приемлемо для большинства таблиц, поскольку схема со временем будет в основном статической. Возможно, таблицы Windows Azure не предназначены для такого использования? Если так, мне непременно нужно будет изменить свой подход. Я также открыт для предложений по альтернативным подходам.
