Аналитика/отчетность - та же или отдельная база данных и какая БД?

У меня есть веб-сайт пользовательского контента с некоторыми бизнес-функциями. Все таблицы находятся в 1 базе данных. Теперь я добавляю аналитику с отчетами в отделе на основе таблиц активности и журналов пользователей - разбивая ее, чтобы иметь отчеты в отделах по каждому дню года, по каждому типу деятельности и т. д. Вопрос в том, создать ли мне отдельную базу данных. для аналитики (или, как люди называют это хранилище данных), или я просто добавляю эти новые таблицы в существующую базу данных? Если мне нужно создать для этого отдельную БД, то это означает, что мне нужно загрузить все данные из основной БД во временные таблицы в аналитической БД, а затем загрузить эти данные в аналитические таблицы, как я предполагаю?

Аналитические требования максимально приближены к реальному времени, поэтому я не уверен, какую БД использовать, если я выберу отдельную. Может ли MySQL, который я использую, выполнять работу по предоставлению аналитики в реальном времени, то есть пользователь выполняет действие, и в следующую секунду, если он просматривает отчет, числа уже будут агрегированы?


mysql database data-warehouse
person Mdillion    schedule 30.12.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Это зависит от количества отчетов, которые вы ожидаете. Базы данных обработки транзакций обычно разрабатываются в 3NF для эффективных вставок.

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

Вы сами должны взвесить возможную нагрузку на отчеты и влияние на производительность по сравнению с настройкой реплики отчетов и ETL для ее заполнения. Также вам нужно определить, есть ли у вас реплика, как часто нужно реплицировать. Существует аргумент, который вы можете использовать против требования «в реальном времени», что бизнес-отчетность может быть более «согласованной», если бизнес отчитывается по фиксированному моментальному снимку данных (например, по ежедневной копии).

Подходы см. в разделе Стратегии заполнения базы данных Reporting/Data Warehouse. для загрузки данных в базу данных отчетов.

person Kris C    schedule 30.12.2010

arrow_upward
0
arrow_downward

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

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

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

person Markus    schedule 12.01.2011