Хранилище таблиц Azure - вопрос о передовых методах проектирования сущностей

Я пишу приложение «доказательство концепции», чтобы исследовать возможность переноса специальной системы электронной коммерции ASP.NET на Windows Azure во время необходимой перезаписи всего приложения.

У меня возникает соблазн взглянуть на использование хранилища таблиц Azure в качестве альтернативы SQL Azure, поскольку сохраняемые сущности, вероятно, со временем изменят свою схему (свойства) по мере дальнейшего развития приложения, и мне не нужно будет вносить бесконечные изменения схемы базы данных. Кроме того, мы можем встроить ссылочную целостность в код приложения, так что аргумент в пользу использования хранилища таблиц Azure является веским.

Единственная потенциальная проблема, которую я вижу в настоящее время, заключается в том, что мы делаем небольшой объем простых отчетов, то есть стоимость продаж между двумя датами, количество товаров, проданных для конкретного продукта и т. Д. Я знаю, что Table Storage не поддерживает функции агрегированного типа, и я считаю, что мы можем достичь того, чего хотим, с умным использованием разделов, нескольких типов сущностей для хранения подмножеств одних и тех же данных и, возможно, предварительной агрегации, но я не уверен на 100%, как это сделать.

Кто-нибудь знает какие-либо подробные документы о принципах проектирования хранилища таблиц Azure, чтобы мы могли правильно и эффективно использовать таблицы, ключи PartitionKeys, дизайн сущностей и т. Д.

существует несколько упрощенных документов, и существующие книги, как правило, не раскрывают эту тему слишком глубоко.

К вашему сведению - у сайта электронной коммерции около 25000 клиентов и около 100000 заказов в год.


person Dean Chalk    schedule 14.04.2011    source источник


Ответы (4)


Вы видели этот пост? http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx

Довольно тщательный охват таблиц

person yacine    schedule 10.05.2011

Я думаю, что при переносе вашего приложения в Table Storage есть три потенциальных проблемы.

  1. Отсутствие отчетности, в том числе агрегатных функций, которое вы уже определили.
  2. Ограниченная доступность поддержки транзакций - при 100 000 заказов в год, я думаю, вам в конечном итоге не хватит этой поддержки.
  3. Некоторые проблемы с затратами - 1 доллар за миллион операций - это небольшая сумма, но вам может потребоваться учесть это, если вы получаете много просмотров страниц.

Честно говоря, я думаю, что это гибридный подход - возможно, EF или NH для SQL Azure для критических данных с большими объектами, хранящимися в Table / Blob?

Довольно моего мнения! Для «вглубь»:

person Stuart    schedule 14.04.2011
comment
отличный совет - спасибо, но мне действительно нужен был совет о том, где получить более подробную информацию о разработке стратегии PartitionKey / Entity, чтобы смягчить обратную сторону перехода на нереляционную СУБД - person Dean Chalk; 15.04.2011
comment
Спасибо, Дин, я добавил еще кое-что об AzureScope, но это все равно не поможет вам с лучшими практическими рекомендациями по использованию в бизнесе. Почти все советы, которые я видел по передовой практике, действительно касались уровня производительности - например, как оформить свои ключи так, чтобы избежать горячих точек. На практическом уровне я обнаружил, что создавать приложения, использующие только хранилище Azure, довольно сложно - отсутствие какой-либо вторичной индексации (например, map-reduce из RavenDB) затрудняет эффективное использование хранилища ключевых сущностей - конечно вы можете дублировать данные, но тогда у вас возникнут проблемы с транзакциями. - person Stuart; 15.04.2011

Если вы начали рассматривать хранилище Azure, такое как таблица, не повредит поискать другие предложения NOSQL на рынке (особенно в отношении баз данных документов). Это даст вам представление о пространстве NOSQL и о том, как разрабатываются решения для таких хранилищ. Вы также можете подумать о гибридном подходе решения SQL DB + NOSQL. Части системы могут очень хорошо подойти для модели хранения таблиц Azure. У решений NOSQL, таких как таблица Azure, есть свои проблемы, такие как

  • Изменения схемы для данных. Проверьте здесь и здесь
  • Транзакционная поддержка
  • Ограничения ACID. Проверьте здесь
person Chandermani    schedule 15.04.2011

Все статьи о дизайне таблиц, которые я видел, почти полностью посвящены темам масштабируемости и производительности поиска. Я не видел ничего, связанного с конструктивными особенностями отчетности или бизнес-аналитики.

Теперь таблицы Azure доступны через API-интерфейсы rest и через пакет Azure SDK. В зависимости от того, какие отчеты вам нужны, вы можете получить необходимую информацию с минимальными усилиями. Если ваши требования к отчетности очень сложные, то, возможно, лучше рассмотреть SQL azure вместе со службами отчетов Windows Azure SQL?

person Luis Delgado    schedule 15.09.2013