Когда создать отдельную базу данных создания отчетов?
Мы создаем приложение, которое имеет базу данных (да, довольно захватывающий ха :). База данных является главным образом транзакционной (для поддержки приложения) и также делает немного "создания отчетов" как часть приложения - но ничто слишком напряженное.
Выше и кроме того у нас есть некоторые требования к отчетности - но они являются довольно неопределенными и высокоуровневыми в данный момент. У нас есть стандартный инструмент создания отчетов, который укрепляет мы-использование, внутреннее, который мы будем использовать, чтобы сделать "более тяжелое" создание отчетов как требования.
Мой вопрос: как Вы знаете, когда отдельная база данных для создания отчетов требуется?
Какие вопросы нужно задать? Какие вещи заставили бы Вас решить, что отдельная база данных создания отчетов была необходима?
4 ответа
В целом, чем более критичным является транзакционное приложение и чем сложнее требования к отчетности, тем больше смысла в разделении.
- Когда производительность транзакции критична.
- Когда трудно получить окно обслуживания транзакционного приложения.
- Если в отчетах необходимо сопоставить результаты не только из этого приложения, но и из других приложений.
- Если отчеты должны поддерживать тенденции или другие типы отчетов, которые лучше всего подходят для звездообразной схемы / среды Business Intelligence.
- Если отчеты долгие.
- Если транзакционное приложение находится на дорогостоящем аппаратном ресурсе (кластер, мэйнфрейм и т. Д.)
- Если вам необходимо выполнить операции очистки / извлечения-преобразования-загрузки данных транзакции (например, преобразование имен состояний в каноническое состояние сокращения).
Это добавляет нетривиальную сложность, так что, я думаю, должна быть веская причина для разделения.
Как правило, я бы попытался изначально составлять отчеты из транзакционной базы данных.
Убедитесь, что все индексы, которые вы добавляете для эффективного создания отчетов, используются часто. Чем больше индексов вы добавите, тем ниже будет производительность при вставках и (если вы изменяете ключи) обновлениях.
Когда вы перейдете на базу данных отчетов, помните, что для этого есть всего несколько причин:
В конечном итоге, главная особенность баз данных отчетов заключается в том, что вы удаляете блокировку из базы данных OLTP. Поэтому, если ваша база данных отчетов является прямой копией той же самой базы данных, вы просто используете отложенные снимки, которые не будут мешать производственным транзакциям.
Далее, вы можете иметь отдельную стратегию индексирования для поддержки сценариев использования отчетности. Эти дополнительные индексы можно поддерживать в базе данных отчетов, но они будут создавать ненужные накладные расходы в базе данных OLTP.
Теперь оба вышеперечисленных варианта можно сделать на одном сервере (даже на одном экземпляре в отдельной базе данных или даже просто в отдельной схеме) и все равно получить преимущества. Когда процессор и IO полностью исчерпаны, в этот момент вам определенно нужно иметь его на совершенно отдельном сервере (или модернизировать ваш единственный сервер).
И наконец, для достижения максимальной гибкости отчетности вы денормализуете данные (обычно в размерную модель или звездообразную схему), чтобы база данных отчетности представляла собой те же данные в другой модели. Отчетность по большим объемам данных (особенно агрегированных) чрезвычайно быстро выполняется в размерных моделях, поскольку схемы "звезда" очень эффективны для этого. Она также эффективна для большего разнообразия запросов без переиндексации или анализа для изменения индексов, потому что размерная модель лучше поддается непредвиденным шаблонам использования (старый запрос "нарежь и нарежь все, что можно"). Можно рассматривать это как своего рода мини-хранилище данных, где используются методы создания хранилищ данных, но не обязательно реализуется полномасштабное хранилище данных. Кроме того, схемы-звезды особенно просты для пользователей, а словари данных гораздо проще и легче создавать для BI-инструментов или инструментов отчетности на основе схем-звезд. Вы можете делать это на одном и том же ящике или на разных ящиках и т.д., как обсуждалось ранее.
Обычно, когда загрузка базы данных из приложения становится несовместимой с загрузкой базы данных для отчетов. Это могло произойти по следующим причинам:
Отчетность потребляет чрезмерное количество ресурсов сервера базы данных, влияющих на производительность БД приложения.
Частью этой категории может быть работа БД приложений, вынужденная ждать в основном медленного запроса отчета из-за блокировки, хотя это может быть возможно решить с помощью менее радикальных методов, таких как настройка блокировки.
Запросы отчетов очень несовместимы с запросами приложений в плане настройки (например, индексы, но не ограничиваясь этим) - самый глупый пример - это что-то вроде горячей точки, влияющей на вставки приложений из-за индекса цели отчетности.
Проблемы со сроками. Например. единственные небольшие окна для обслуживания БД (из-за использования приложений) - это времена тяжелой работы с отчетами
Чистый объем данных отчетов (например, журналирование, аудит, статистика) настолько велик, что архитектура вашего основного сервера БД - плохое решение для такие отчеты (см. Sybase ASE против Sybase IQ). Кстати, это реальный сценарий - из-за этого мы переместили нашу отчетность о производительности в IQ.
Основная причина, по которой вам может понадобиться отдельная база данных для отчетов о проблемах, - это когда создание отчетов мешает транзакционным обязанностям приложения. Например. если для создания отчета требуется 20 минут и используется 100% ЦП / диска и т. д. ... в период высокой активности вы можете подумать об использовании отдельной базы данных для отчетов.
Что касается вопросов, вот несколько основных:
- Могу ли я делать отчеты с высокой интенсивностью в непиковые часы?
- Мешает ли это пользователям, использующим систему?
- Если да, на # 2 , какова стоимость вмешательства по сравнению со стоимостью другого сервера базы данных, кода рефакторинга и т. д.?