Производительность MySQL: представления против функций и хранимых процедур

Question

У меня есть таблица, которая содержит некоторые статистические данные, которые собираются за час. Теперь я хочу иметь возможность быстро получать статистику за день / неделю / месяц / год / всего. Каков наилучший способ сделать это с точки зрения производительности? Создание просмотров? Функции? Хранимые процедуры? Или обычные таблицы, в которые я должен писать одновременно при обновлении данных? (Я бы хотел избежать последнего). Моя текущая идея заключается в создании view_day, который суммирует часы, затем view_week и view_month и view_year, которые суммируют данные из view_day, и view_total, который суммирует view_year. Это хорошо или плохо?

Answer 1

По сути, у вас есть две системы: одна, которая собирает данные, и другая, которая отчитывается по этим данным.

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

Как правило, НАСТОЯТЕЛЬНО рекомендуется запускать периодическую задачу «сбора», которая собирает информацию из ваших (возможно, сильно нормализованных) транзакционных таблиц и помещает эти данные в денормализованные таблицы отчетности, образуя«хранилище данных».Затем вы указываете свой механизм / инструменты отчетности на денормализованное «хранилище данных», к которому можно обращаться, не затрагивая действующую транзакционную базу данных.

Эта задача сбора должна выполняться только так часто, как ваши отчеты должны быть "точными".Если вы можете сойти с рук один раз в день, отлично.Если вам нужно делать это один раз в час или больше, тогда продолжайте, но при этом следите за влиянием производительности на ваши задачи по написанию.

Помните, важна ли производительность вашей транзакционной системы (и обычно онаесть), избегайте отчетов против него любой ценой.

Answer 2

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

Answer 3

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

Принимая во внимание, что представления, а также SP и функции будут просто выполнять запросы к большим таблицам, что не так эффективно.

Answer 4

У нас похожая проблема, и мы используем отношения мастер / раб. Мы выполняем транзакционные данные (как чтение, так и запись, поскольку в нашем случае некоторые операции чтения должны быть очень быстрыми и не могут ждать репликации для транзакции) на главном сервере. Ведомое устройство быстро реплицирует данные, но затем мы выполняем каждый нетранзакционный запрос, включая отчеты.

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

Answer 5

Я считаю, что сложные вычисления должны выполняться только один раз, поскольку данные изменяются не каждый раз, когда вы запрашиваете. Создайте сводные данные и заполните их либо с помощью триггера (если журнал не приемлем), либо с помощью задания, которое запускается один раз в день или раз в час, или в любое другое время задержки, приемлемое для отчетности. Если вы идете по триггерному маршруту, тестируйте, тестируйте, тестируйте. Убедитесь, что он может обрабатывать несколько строк вставки / обновления / удаления, а также более распространенные одиночные. Убедитесь, что он работает максимально быстро и не содержит ошибок. Триггеры добавят немного обработки к каждому действию данных, вы должны убедиться, что он добавляет наименьший возможный бит, и не будет ошибок, которые бы помешали пользователям вставлять / обновлять / удалять данные.