Предлагаемое решение, Таблица агрегатов, Таблица лога изменений - Программа расчета агрегатов по накапливающимся данным для построения отчетов

База данные кеширование денормализация

Предлагаемое решение -- скомбинировать некоторые идеи кеширования и денормализации в специальной библиотеке StatMetric.

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

Библиотека предоставит набор методов для приложения, чтобы оно могло уведомлять об изменениях данных, связанных с агрегатами. Например, после каждого успешного платежа приложение будет уведомлять библиотеку о создании нового Order и всех связанных с ним сущностей, и необходимости зачесть суммы заказа в агрегат "продажи". Библиотека запишет это событие в своем хранилище.

Приложение сможет делать запросы к библиотеке по любому из описанных агрегатов.

Библиотека хранит данные в двух дополнительных таблицах: таблице вычисленных агрегатов и логе изменений.

Таблица агрегатов

Как было показано выше, вычисление агрегатов может иметь недопустимо высокую алгоритмическую сложность. Поэтому, вместо того чтобы пересчитывать и кешировать значение агрегата при чтении, будет храниться и обновляться вычисленное значение агрегата. Храня немного дополнительных данных, можно вычислить новое значение агрегата за не зависящее от количества данных, им покрываемых, время, то есть не пересчитывая его заново.

В этой таблице id и значение агрегата хранится для каждого возможного среза. Для базы данных из рисунка 1 можно определить простой агрегат "продажи" со срезами по событию, партнеру и организации. "Срезать по Event" -- значит сохранить продажи для каждого события отдельной записью. В данном случае Event -- "срезающая таблица". С каждым новым оплаченным заказом, библиотека будет обновлять все затронутые срезы прибавляя сумму заказа к сохраненному значению.

В таблице 1 изображен пример содержимого таблицы агрегатов для описанного агрегата продаж.

Таблица 1. Пример содержимого таблицы агрегатов

Stat

Slice

Slice_data

Value

Sales

100

Sales

Event

1

20

Sales

Event

2

30

Sales

Event

3

50

Sales

Partner

1

20

Sales

Partner

2

10

Sales

Org

1

20

Sales

Org

2

80

В первой записи хранится полное, не срезанное значение агрегата -- сумма всех продаж. Следующие три записи хранят продажи с событий 1, 2 и 3. В столбце slice хранится тип среза, а в slice_data -- id первичного ключа элемента из срезающей таблицы, по которому идет срез. Предполагается, что в базе данных используются числовые первичные ключи с авто-инкрементом (стандарт де-факто в веб-разработке).

Идею можно расширять. Например, если хранить количество элементво и сумму в записи, то можно хранить агрегат AVG (среднее) и обновлять значение без пересчета. При обновлении данных фреймворк обновит количество и сумму, после чего, разделив сумму на количество получит новое среднее.

Кроме того, можно определять срезы по нескольким таблицам, например "Event, Partner", чтобы выполнять запросы типа "доход с события X партнеру Y". Однако, потребление дискового пространства такими срезами хуже масштабируются. Эта проблема рассмотрена более подробно в разделе "Ожидаемые результаты".

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

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

Таблица лога изменений

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

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

Похожие статьи




Предлагаемое решение, Таблица агрегатов, Таблица лога изменений - Программа расчета агрегатов по накапливающимся данным для построения отчетов

Предыдущая | Следующая