Журналы журналов Windows azure, вопрос запроса

Question

Мы используем таблицу azure для Windows для регистрации ошибок в наших приложениях, размещенных внутри роли или роли пользователя. Мы регистрируем достаточную информацию в таблице, чтобы было легко определить, какую роль выполняет компонент компонента, зарегистрированный в журнале.

Идентификатор компонента (полное имя класса) используется ключ раздела и случайный уникальный Guid является ключом строки.

отображается журналирования информация на веб-сайте ASP.NET MVC, где администратор может искать этот журнал на основе критериев фильтрации, как идентификатор компонента, диапазон дат, идентификатор роли, важностей и т.д.

Это прекрасно работает до стола небольшой , Как только лазурная таблица содержит огромное количество записей (200000 и более), фильтр на лазурной таблице занимает слишком много времени, и время истекает. Мы используем API хранения azure .NET для запросов к таблицам.

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

Мы попытались использовать API-интерфейс Azure Storage для применения фильтра и получения данных на основе текущего номера страницы, но не работаем. Я понимаю, что нам, возможно, придется перепроектировать нашу структуру таблицы, особенно keykey и rowkey, но не уверен, как это сделать.

Answer 1

Если вам нужно много пользовательских фильтров, хранение таблицы не может предложить лучшую производительность. По возможности используйте SQL Azure. Чтобы повысить производительность хранения таблиц, вы можете попробовать:

1. Не используйте специальные фитинги. Фильтровать результат только с помощью ключа раздела/строки. Это даст вам лучшую производительность.

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

Что касается пейджинга, если у вас нет запроса на перегородку, пейджинг должен работать должным образом. Если вы попросите 20 объектов, будет возвращено ровно 20 объектов (если их так много). Но если встречается граница раздела, требуется новая страница. Например, если граница раздела встречается при обнаружении 15-го совпадающего объекта, в этом запросе будет возвращено только 15 объектов. Вы должны создать новый запрос для запроса следующего раздела. Если вы сохраняете небольшие разделы, вы можете столкнуться с этой проблемой чаще. Поэтому вам необходимо разработать систему для автоматического запроса следующего раздела, если это необходимо.

Также помните, что подкачка табличного хранилища не основана на номере страницы. Он основан на токене продолжения. Обратитесь к http://msdn.microsoft.com/en-us/library/dd135718.aspx за дополнительной информацией.

Answer 2

У вас есть только 2 «проиндексированные» свойства при использовании хранилища таблиц, являющихся вашим ключом раздела и вашим ключом строки. Поиск других полей будет очень медленным, если у вас есть множество данных.

При реализации пейджинговой системы или при заказе данных вы должны играть с ключом строки. Ключ строки определяет порядок ваших данных (порядок сортировки лексикографический).

Я предлагаю вам взглянуть на блоге Стива для получения дополнительной информации о сортировке и заказа данных: Using Numbers as Keys in Windows Azure

Answer 3

В таком случае я бы предложил регистратор, который я написал для хранения журналов в таблице Azure - QLog. Вы можете получить его через NuGet.Он поставляется с QLogBrowser, который позволит вам запрашивать журналы таким образом, который вы хотите. Сайт проекта GitHub - here.