Агрегироваться или не агрегироваться, который является вопросом о дизайне схемы базы данных
При выполнении минимальных/макс./в среднем запросов Вы предпочитаете использовать таблицы агрегирования или просто запрашивать через диапазон строк в необработанной таблице?
Это - очевидно, очень открытый вопрос и нет никакого правильного ответа, таким образом, я просто ищу общие предложения людей. Предположите, что таблица необработанных данных состоит из метки времени, числовой внешний ключ (скажите, что идентификатор пользователя), и десятичное значение (говорят что объем покупки). Кроме того, предположите, что существуют миллионы строк в таблице.
Я сделал обоих, и порван. С одной стороны таблицы агрегирования дали мне значительно более быстрые запросы, но за счет быстрого увеличения дополнительных таблиц. Отображение текущих значений для агрегированного диапазона или требует отбрасывания полностью назад к таблице необработанных данных или объединению более мелкомодульных агрегирований. Я нашел, что, отслеживая в коде приложения который таблица агрегирования запросить, когда больше работы, что Вы думали бы и та схема, изменения будут требоваться, поскольку исходные диапазоны агрегирования неизменно не будут достаточно ("Но я хотел видеть наши продажи за прошлые 3 периода платы!").
С другой стороны, запросы от необработанных данных могут быть медленным punishingly, но позволяют мне быть очень гибким о диапазонах данных. Когда диапазон ограничивает изменение, я просто изменяю запрос вместо того, чтобы иметь необходимость восстановить таблицы агрегирования. Аналогично код приложения требует меньшего количества обновлений. Я подозреваю, что, если бы я был более умным о своей индексации (т.е. всегда наличие хороших закрывающих индексов), я смог бы уменьшить штраф выбора из необработанных данных, но это ни в коем случае не панацея.
Есть ли так или иначе, у меня может быть лучший из обоих миров?
3 ответа
У нас была та же проблема, и мы столкнулись с тем же проблемы, с которыми вы столкнулись. В итоге мы переключили нашу отчетность на службы Analysis Services. С самими службами MDX и Analysis нужно научиться, но это здорово. Мы обнаружили следующие преимущества:
- У вас есть большая гибкость для запросы любым удобным для вас способом. Прежде чем мы пришлось строить конкретные агрегаты, но теперь один кубик отвечает на все наши вопросы.
- Хранение в кубе намного меньше чем подробные данные.
- Создание и обработка кубов занимает меньше времени и производит меньше нагрузка на серверы баз данных, чем агрегаты сделали.
Некоторые МИНУСЫ:
- Вокруг построение кубов и изучение MDX.
- Нам пришлось создать некоторые инструменты для автоматизировать работу с кубами.
ОБНОВЛЕНИЕ: Поскольку вы используете MySql, вы можете взглянуть на Pentaho Mondrian , решение OLAP с открытым исходным кодом, поддерживающее MySql. Я никогда не использовал его, поэтому не знаю, подойдет ли он вам или нет. Было бы интересно узнать, работает ли это для вас.
Я всегда склоняюсь к необработанным данным. После агрегирования вы не можете вернуться.
Ничего общего с удалением - если нет простейшего из агрегированных наборов данных, вы не сможете точно вернуть / транспонировать данные обратно в необработанные.
В идеале, Я бы использовал материализованное представление (предполагая, что данные могут соответствовать ограничениям), потому что это фактически таблица. Но MySQL не поддерживает их, поэтому следующим рассмотрением будет представление с вычисленными столбцами или триггер для обновления фактической таблицы.
Помогает выбрать хороший первичный ключ (т.е. [user_id, used_date, used_time]). Для константы user_id очень быстро выполнить условие диапазона по дате use_date.
Но по мере роста таблицы можно уменьшить размер таблицы, агрегируя ее в таблицу типа [user_id, used_date]. Для каждого диапазона, где время дня не имеет значения, вы можете использовать эту таблицу. Другой способ уменьшить размер таблицы - это архивирование старых данных, которые вы больше не (разрешаете) запрашивать.
.