Агрегировать или не агрегировать, это вопрос разработки схемы базы данных

Question

Если вы выполняете запросы min / max / avg, предпочитаете ли вы использовать таблицы агрегации или просто выполнять запросы в диапазоне строк в необработанной таблице?

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

Я сделал и то, и другое. С одной стороны, таблицы агрегации дали мне значительно более быстрые запросы, но за счет увеличения числа дополнительных таблиц. Для отображения текущих значений агрегированного диапазона необходимо либо полностью вернуться к таблице необработанных данных, либо объединить более мелкозернистые агрегаты. Я обнаружил, что отслеживание в коде приложения, какой таблицы агрегации запрашивать, когда это больше работы, о которой вы могли бы подумать, и что потребуются изменения схемы, поскольку исходных диапазонов агрегации всегда будет недостаточно («Но я хотел посмотреть, наши продажи за последние 3 периода оплаты! ").

С другой стороны, запросы из необработанных данных могут быть очень медленными, но позволяют мне быть очень гибкими в отношении диапазонов данных. Когда границы диапазона меняются, я просто меняю запрос, а не перестраиваю таблицы агрегации. Аналогично, код приложения требует меньше обновлений. Я подозреваю, что если бы я был умнее в отношении своей индексации (то есть всегда имел хорошие индексы покрытия), я мог бы уменьшить штраф за выбор из необработанных данных, но это ни в коем случае не панацея.

Могу ли я в любом случае иметь лучшее из обоих миров?

Answer 1

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

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

Некоторые минусы:

1. Существует кривая обучения вокруг построение кубов и изучение MDX.
2. Нам пришлось создать несколько инструментов для автоматизировать работу с кубиками.

UPDATE: Поскольку вы используете MySql, вы можете взглянуть на Pentaho Mondrian , который представляет собой OLAP-решение с открытым исходным кодом, которое поддерживает MySql. Я никогда не использовал его, поэтому я не знаю, сработает ли он для вас или нет. Было бы интересно узнать, работает ли он для вас, хотя.

Answer 2

Это помогает выбрать хороший первичный ключ (например, [user_id, used_date, used_time]). Тогда для постоянного user_id очень быстро выполнить условие диапазона для used_date.

Но по мере роста таблицы вы можете уменьшить размер таблицы, агрегируя ее в таблицу, например [user_id, used_date]. Для каждого диапазона, где время суток не имеет значения, вы можете использовать эту таблицу. Другой способ уменьшить размер таблицы - это архивировать старые данные, которые вы больше не разрешаете (не разрешаете).

Answer 3

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

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