Хранилище таблиц Azure - вычисление или сохранение итогов

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

У меня есть несколько вариантов:

  • Используйте структуру ключей раздела / строки и динамически выполняйте сумму
    , например. 20101101_ITEMID_XXXXXXXX (x = guid или время, чтобы сделать уникальным), тогда я бы запросил данные за месяц, используя часть ключа строки (ITEMID_201011), и к сумме в свойстве «Стоимость» в типе.

    Но как с этим можно справиться с ограничением запросов в 1000 записей? (т.е. если в день совершается более 1000 транзакций, подсчитать будет сложно)

  • Используйте другую запись, чтобы сохранить общую сумму за день, и обновляйте ее по мере добавления новых записей
    например. ключ строки "20101101_ITEMID_TOTAL", затем запросите итоговые значения дней, месяцев или лет.

Как лучше всего это сделать? Есть ли «лучшая практика» для этого типа требований с использованием хранилища таблиц?


azure-storage azure-table-storage
person Rosstified    schedule 25.11.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

Некоторые другие мысли для рассмотрения:

Изменится ли когда-нибудь ваши общие итоги? Если нет, то это еще один толчок к предварительной агрегации.

Придется ли вам сохранять агрегированные значения после того, как необработанные данные исчезнут, или вам когда-нибудь понадобится очистить необработанные данные? Если да, то это еще один толчок к предварительной агрегации.

person Igorek    schedule 25.11.2010