Оптимизация запросов хранилища Azure для служб RIA

Question

Я работаю с таблицами хранилища Azure и службами RIA, чтобы создать довольно простой пользовательский интерфейс Silverlight для доступа к некоторым данным и управления ими.

Ничего особенного: модель данных с некоторыми аннотациями и DomainDataSource делают все это очень легким делом.

С одним незначительным исключением.

Когда у меня действительно очень большая таблица, то загрузка ее, по крайней мере, когда я делаю это в Development Fabric и даже при использовании параметра LoadSize в DomainDataSource, занимает много времени.

Я предполагаю, что происходит следующее:

• Клиент Silverlight запрашивает у службы RIA, скажем, 100 первых строк таблицы.
• Поскольку запросы хранилища данных Azure являются чрезвычайно простыми, служба извлекает все строки из хранилища данных, и THEN выполняет Take (100) для этого набора.
• Клиент получает первые 100 строк.

Это нормально для сохранения пропускной способности, но далеко не оптимально, если учесть, что нужно платить за вычислительную мощность, используемую приложением на основе Azure.

Есть ли способ оптимизировать запросы службы RIA? Можно ли вообще использовать методы Take() и Skip() в таблицах хранения Azure?

РЕДАКТИРОВАТЬ: я использую бета-версию WCF RIA Services с пакетом обновления 1 (SP1) и выполнил несколько учебных пособий по Silverlight со службами RIA (все они очень похожи). Объединяя их, мне просто интересно, можно ли улучшить загрузку большой таблицы в Silverlight, добавив параметр LoadSize. На данный момент кажется, что он сохраняет только пропускную способность (поскольку правильное количество строк отправляется клиенту Silverlight), но весь процесс по-прежнему использует столько же процессорного времени, сколько и для всей таблицы.

Answer 1

Вы пробовали RIA Services SP1 Beta? Он включает TableDomainService, который обрабатывает всю логику, управляя объектами в указанной учетной записи хранилища Azure. Кроме того, вы можете проверить трафик между вашим сервисом и хранилищем Azure, используя Fiddler , чтобы выяснить, в чем проблема.

Ссылки:

• WCF RIA Services SP1 Beta объявление
• Блог Кайла Макклеллана - он разработал TableDomainService. В его блоге много сообщений об этой функции.

EDIT: Как Кайл Макклеллан , упомянутый ниже в комментарии, эта проблема действительно существует в службах RIA WCF SP1 Beta .

Answer 2

Вы имеете в виду, что вы извлекаете все сущности в коде для выполнения запроса или что служба Table должна сканировать все сущности, чтобы вернуть результаты? В любом случае вы, вероятно, неправильно используете хранилище Talbe.

Хранилище таблиц Azure не является СУБД, и вам не следует относиться к этому таким образом. Он разработан для обеспечения сверхбыстрых и масштабируемых модификаций, простого разделения и индексированного доступа. Единственный индексированный доступ - по ключу раздела и строки. Это определенно не подходит для специальных запросов и отчетов. В этом отношении он ничем не отличается от большинства баз данных NoSQL.

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

Тем не менее, существуют способы оптимизации отчетов даже при хранении таблиц. Самым важным является понимание того, что данные отчетности (давайте рассмотрим таблицы данных как отчеты для этого обсуждения) должны быть отделены от данных транзакций - вот что такое Разделение ответственности команд-запросов (CQRS).

• Вы можете использовать несколько таблиц для хранения результатов для разных отчетов и асинхронного обновления их при обработке транзакций. Вы можете использовать ключи секций, которые объединяют несколько значений полей в каждой таблице, что упрощает извлечение строк отчета. Вы все еще должны определить свои отчеты на уровне сервера. В этом случае сценарий ближе к получению снимков отчета, чем к запросам.
• Вы можете извлекать данные отчетов в SQL Azure и использовать SQL для специальных отчетов. Обновление должно выполняться асинхронно, как и раньше, но вы получаете специальные запросы. SQL Azure намного дороже, хотя.
• Необычное решение, подходящее для довольно статичных отчетов (например, ежемесячных или еженедельных сводок), заключается в использовании хранилища больших двоичных объектов для хранения данных отчета в формате JSon (или как вам удобно). Вы все еще должны определить соответствующий раздел и ключи строки. Это похоже на создание снимков отчетов в службах отчетов SQL Server.

Наиболее подходящее решение зависит от вашего конкретного сценария:

• Если ваше приложение обрабатывает бизнес-операции (например, заказы, телефонные звонки и т. Д.), Ваша основная таблица должна использовать ключи, которые оптимизируют обработку TX, а таблицы отчетов должны использовать ключи, которые оптимизируют извлечение отчетов.
• Если вы создаете форум, веб-сайт или службу CMS, вы, вероятно, можете создать по одной таблице «Сообщения» на форум для сообщений, разделенных по threadid (просто идея) и отдельных таблиц «индекса» для тегов, пользователей и т. Д. эта ссылка на таблицу сообщений.

Тем не менее, Table Storage поддерживает операторы запросов OData / WCF Data Service (фильтр и т. Д.), Пропускают ($ skip) и принимают ( $ top ).