Отдельные таблицы/базы данных для создания отчетов и операций CRUD
Периодически пользователи, выполняющие отчеты, блокируют пользователей, делающих операции CRUD и вызывающих тайм-ауты. Я хотел бы создать дублирующиеся местоположения текущих таблиц для пользователей отчета.
Я думал о создании задания, которое поддерживает базу данных моего приложения и восстанавливает ее к базе данных создания отчетов по тому же серверу так, чтобы пользователи, выполняющие отчеты, были разделены от тех, которые делают операцию в секунду CRUD. Задание будет работать каждые 10 минут или около этого. Начальное тестовое шоу начинает заканчиваться, будут приблизительно 30 секунд. Дисковое пространство не является проблемой.
Действительно ли это - хорошая/плохая идея? Какие ловушки я должен не упустить? Существует ли лучший способ сделать это?
4 ответа
Звучит неплохо. Единственное, что меня беспокоит, это нужно ли вам обновлять каждые 10 минут? Это также может замедлить работу во время обновления. Обычно это делается в течение ночи (чтобы иметь наименьшее влияние на других) или, если в течение дня, только в 3 фиксированных точках (скажем, 10:00, 13:00 и 16:00).
Прежде чем делать апгрейд вилочного погрузчика, вы можете посмотреть, смягчит ли проблему включение
...from sometable WITH (NOLOCK)
в ваши запросы к отчетам. Это, по крайней мере, может дать вам немного времени, чтобы понять, что является оптимальным.
Естественно, что в большинстве приложений корпоративного класса база данных транзакций всегда хранится отдельно от базы данных отчетов. Система транзакций настроена на OLTP, а база данных отчетов может быть денормализована в соответствии с потребностями сценариев отчетности. Поэтому это почти естественное предложение.
Будьте осторожны с частым резервным копированием - это может привести к большим простоям!
Общие решения
Это действительно распространенная практика - создавать отдельный экземпляр только для создания отчетов.
Некоторые люди даже идут дальше и размещают отчетность на отдельной физической машине или кластере, чтобы еще больше изолировать эту часть нагрузки.
Обе эти задачи можно решить с помощью репликации (что позволяет избежать проблемы простоя). Или вы можете просто делать ночное резервное копирование и создавать отчеты на его основе.
Я также хотел бы упомянуть, что высококлассным подходом к этому является хранилище данных, где вы, по сути, преобразуете эту новую базу данных отчетов в хранилище, оптимизированное для чтения и более эффективное для создания отчетов. Это, как правило, требует много времени на реализацию, поэтому это не быстрое решение, которое вы ищете.
Заключительные мысли
И последнее: я видел, как некоторые магазины, стоящие на пороге этой проблемы, пытались избежать ее решения. Вот что из этого следует: отчетность имеет тенденцию к всплеску в определенное время месяца или года, так что если вы обычно находитесь на грани того, чтобы убить свой сервер базы данных, последняя неделя месяца может подтолкнуть вас к краю!
Этот вопрос очень похож: https://stackoverflow.com/questions/190512/sql-server-separate-database-for-reports