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

Question

Мы создаем приложение, которое имеет базу данных (да, довольно захватывающе, да :).База данных в основном транзакционная (для поддержки приложения), а также делает небольшую «отчетность» как часть приложения - но не слишком трудоемка.

Помимо этого у нас есть некоторые требования к отчетности - но они 'на данный момент довольно расплывчато и на высоком уровне.У нас есть стандартный инструмент отчетности, который мы используем внутри компании, который мы будем использовать для составления «более тяжелой» отчетности по мере того, как требования укрепляются.

Мой вопрос: как узнать, когда существует отдельная база данных для отчетноститребуется?

Какие вопросы нужно задавать?Какие вещи заставят вас решить, что отдельная база данных отчетов необходима?

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

В вашем утверждении есть несколько ошибок.

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

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

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

Моя точка зрения заключается в том, что все решает, когда:

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

Answer 4

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

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

В этом шаблоне НАМНОГО больше всего, я только что упомянул интересный фрагмент из-за вашего вопроса относительно базы данных отчетов.

Answer 5

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

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

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

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

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

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

Answer 6

Основная причина, по которой вам понадобится отдельная база данных для сообщений о проблемах, заключается в том, что создание отчетов мешает транзакционным обязанностям приложения.Например, если создание отчета занимает 20 минут и использует 100% ЦП / диска / и т. Д. Во время высокой активности, вы можете подумать об использовании отдельной базы данных для отчетов.

Что касается вопросов,Вот некоторые основные:

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

Answer 7

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