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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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