Меньшее подмножество данных (уменьшение на 99%) будет использоваться из моей заявки на отчетность.Просмотр или сохраненная процедура для сводного запроса?
Поскольку это будет «построено» на ежедневной основе; какой лучший инструмент - хранимая процедура, просмотр или что-то еще?
Построение и ведение сводной таблицы. Сначала вам нужно будет запустить большой GROUP BY, чтобы собрать все старые данные. После этого ночная работа будет вычислять COUNT(*), SUM(...) и т. Д. За предыдущий день.
Тогда «отчет» будет работать намного быстрее против этой новой таблицы.
Ключ для этой таблицы будет включать в себя день (не дату + время) плюс несколько столбцов, которые могут понадобиться для отчета (ов).
Я нахожу, что типичное ускорение составляет 10x; вы можете получить 100x (уменьшение на 99%).
Лучший инструмент - это скрипт, который вы запускаете через cron (или, возможно, MySQL EVENT). Это просто сделало бы что-то вроде
INSERT INTO SummaryTable (dy, ..., ct, tot, ...)
SELECT DATE(datetime), ..., -- key
COUNT(*), SUM(..), ... -- data
FROM FactTable
WHERE datetime >= CURDATE() - INTERVAL 1 DAY
AND datetime < CURDATE();
Этот один оператор SQL может быть всем, что необходимо. Да, это может быть в Хранимой процедуре, но это не сильно отличается от того, что она есть непосредственно в ночном сценарии.
В некоторых случаях может быть лучше использовать INSERT ... ON DUPLICATE KEY UPDATE ... SELECT ... (но это становится беспорядочным).
Когда речь идет о «средних», необходимо учитывать следующее:
AVG(...), ноSUM(daily_sums)/SUM(daily_counts). То есть, сводная таблица, вероятно, нуждается в COUNT(*) и SUM(...).Чтобы изначально заполнить эту сводную таблицу, я бы написал одноразовый скрипт, чтобы медленно проходить через строки 600 М один день за раз. Конечно, вы могли бы сделать все сразу, но вмешательство во все остальное могло быть «плохим».
Еще лучше было бы, чтобы ночной сценарий включал код, чтобы «забрать, где он остановился». Таким образом, если сценарий не запускается ночью, он восстановит упущение на следующую ночь. Или вы можете вручную запустить его, когда увидите проблему. И дополнительный прогон ничего не повредит.
Пока вы на нем, подумайте о других сводных таблицах, которые могут вам понадобиться. Обычно я считаю, что для приложения Data Warehouse необходимы 3-7 сводных таблиц.С другой стороны, имейте в виду, что еженедельные и ежемесячные сводки могут быть получены (достаточно эффективно) из ежедневной сводной таблицы. В нескольких случаях у меня была сводная таблица по часам для одного, а затем ежедневные таблицы для разных вещей.
600M строк большой. Будут удалены «старые» данные? Как только у вас появятся сводные таблицы, будут ли старые данные больше не нужны? Blog on using Partitioning for such.
Спасибо, что набрали все это. Это помогло мне получить именно то, что я искал, создав хранимую процедуру, которая вставляет вчера средние значения, а затем создает событие для его выполнения. – OmisNomis
У вас будет задание, которое выполнит запрос, сохранит результаты в таблице и выполнит другие операции по ведению бухгалтерского учета. –
ПРОСМОТРЫ не материализуются или не кэшируются, поэтому вы не можете получить преимущество в производительности от использования одного, если хотите генерировать новые агрегированные результаты, хранить их в таблице, а затем запрашивать, вы будете использовать процедурный подход, предоставляемый хранимой процедурой. –
Таким образом, рекомендуется использовать хранимую процедуру для запуска задания каждый день, который вставляет новые записи в новую таблицу? – OmisNomis