Когда создавать отдельную базу данных отчетов?

Ответ 1

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

• Когда производительность транзакции имеет решающее значение.
• Когда трудно получить окно обслуживания транзакционного приложения.
• Если отчет должен сопоставлять результаты не только с этим приложением, но и с другими силосами приложений.
• Если отчеты должны поддерживать тренды или другие типы отчетов, которые лучше всего подходят для среды звездочки/среды бизнес-аналитики.
• Если отчеты работают долго.
• Если транзакционное приложение находится на дорогостоящем аппаратном ресурсе (кластер, мэйнфрейм и т.д.)
• Если вам нужно выполнить операции очистки данных/извлечения-преобразования-загрузки транзакционных данных (например, имена состояний для сокращений канонических состояний).

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

Ответ 2

Как правило, я бы попытался сначала сообщить о транзакционной базе данных.

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

Когда вы переходите в базу данных отчетов, помните, что есть несколько причин, по которым вы собираетесь туда:

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

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

Теперь оба указанных выше могут быть выполнены на одном и том же сервере (даже один и тот же экземпляр в отдельной базе данных или даже только в отдельной схеме) и по-прежнему видят преимущества. Когда CPU и IO полностью привязаны, в этот момент вам определенно нужно иметь его на полностью отдельной коробке (или обновить один ящик).

Наконец, для максимальной гибкости отчетности вы денормализуете данные (как правило, в размерную модель или звездные схемы), так что база данных отчетов представляет собой одни и те же данные в другой модели. Отчетность больших объемов данных (в частности, агрегатов) чрезвычайно велика в размерных моделях, потому что схемы звезд очень эффективны для этого. Он также эффективен для более широкого круга запросов без большого переиндексации или анализа для изменения индексов, поскольку размерная модель лучше подходит для непредвиденных шаблонов использования (старый запрос "срез и кости каждый" ). Вы можете видеть, что это своего рода хранилище мини-данных, в котором вы используете методы хранилищ данных, но не обязательно внедряете полномасштабный хранилище данных. Кроме того, звездные схемы особенно удобны для пользователей, и словари данных гораздо проще и проще создавать для инструментов BI или средств отчетности из звездных схем. Вы можете сделать это в том же поле или в другой коробке и т.д., Как описано ранее.

Ответ 3

Этот вопрос требует опыта, а не науки.

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

Лично я предпочитаю как можно больше поддерживать процессы отчетности на стороне базы данных (Лучшая практика в мире BI). ИНСТРУМЕНТЫ ОТЧЕТНОСТИ ТОЛЬКО ДЛЯ ОТОБРАЖЕНИЯ (МАКСИМАЛЬНЫЙ ДЛЯ МАЛЫХ РАСЧЕТОВ). Этот подход требует большой предварительной обработки данных, которая требует различных промежуточных таблиц, триггеров и т.д.

Когда вы сказали:

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

Есть несколько вещей не так с вашим утверждением.

1. Сотни миллионов строк много. даже сегодня в таких инструментах памяти, как Cognos TM1 или Qlikview, будет трудно получить такой результат. (посмотрите на SAP HANA от SAP, чтобы понять, как гиганты в отрасли справляются с этим).

2. Если в базе данных есть сотни миллионов строк, это не обязательно означает, что отчет должен пройти через все эти записи. может быть, отчет работал на тысячи, а не на миллионы. наверное то что ты видел.

3. Транзакционные отчеты сильно отличаются от панелей мониторинга. Большинство инструментов панели инструментов предварительно обрабатывают и кэшируют данные.

Я хочу сказать, что все это приходит к опыту, когда вы решаете, когда:

1. разработать новую схему
2. создать семантическую базу данных
3. работать на той же транзакционной базе данных
4. или даже использовать инструмент создания отчетов (иногда рукописные панели инструментов с Java/JSF/Ajax/jQuery или JSP могут работать нормально для клиента)

Ответ 4

Основная причина, по которой вам понадобится отдельная база данных для отчетности, - это когда генерация отчетов мешает транзакционным обязанностям приложения. Например. если отчет занимает 20 минут, чтобы генерировать и использовать 100% CPU/Disk/etc... во время высокой активности, вы можете подумать об использовании отдельной базы данных для отчетности.

Что касается вопросов, вот несколько основных:

• Могу ли я делать отчеты о высокой интенсивности в непиковые часы?
• Это мешает пользователям, использующим систему?
• Если да на # 2, каковы затраты на интерференцию Vs на стоимость другого сервера базы данных, код рефакторинга и т.д.??

Ответ 5

В принципе, когда загрузка базы данных из приложения становится несовместимой с нагрузкой базы данных для отчетности. Это может быть связано с:

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

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

• Отчеты, которые очень несовместимы с запросами приложений в отношении настройки (например, индексы, но не ограничиваясь этим) - самый немой пример - это что-то вроде горячей точки, влияющей на вставки приложений из-за индекса целевой отчетности.

• Сроки. Например. единственные небольшие окна для обслуживания БД (из-за использования приложений) - это время тяжелой работы с отчетами

• Объем данных отчетов (например, ведение журнала, аудит, статистика) настолько велик, что ваша основная архитектура сервера БД является плохим решением для такой отчетности (см. Sybase ASE vs. Sybase IQ). Кстати, это реальный сценарий - из-за этого мы перенесли нашу отчетность о производительности в IQ.

Ответ 6

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

Ответ 7

Я также добавлю еще одну причину, по которой вы можете использовать базу данных отчетов, и это: шаблон CQRS (разделение ответственности за запросы команд).

Если у вас есть большое количество пользователей, которые обращаются к маленькому набору данных и записывают их, вам следует подумать об этом шаблоне. В простейшей форме это означает, что все ваши команды (Create, Update, Delete) помещаются в транзакционную базу данных. Все ваши запросы (Read) взяты из вашей базы данных отчетов. Это позволяет свободно скопировать вашу архитектуру и функцию обновления.

В шаблоне много БОЛЬШЕ, я просто упомянул бит, который был интересен из-за вашего вопроса относительно базы данных отчетов.