MySQL - статистика веб-приложений и хранения - PullRequest
0 голосов
/ 17 ноября 2018

Я мог бы воспользоваться некоторыми советами о «лучшем» способе хранения статистических данных из созданного мной веб-приложения.

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

Допустим, у меня есть таблица posts, и posts можно назначить на categories, иметь tags и различные другие мета-атрибуты, такие как color, users mood и т. Д.

Я хочу создать отдельное веб-приложение, которое отображает различную статистику (без пользовательских данных), например, страницу, которая покажет, сколько сообщений было отправлено каждый день, сколько сообщений было color синего цвета, в X category и т. д. с красивыми графиками и функцией поиска по диапазону дат. Статистику нужно ежедневно компилировать и хранить для отображения в веб-приложении статистики.

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

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

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

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

Есть мысли о том, как правильно хранить статистику?

...