У меня уже есть веб-сайт, работающий с использованием CodeIgniter и MySQL.База данных MySQL имеет размер около 110 таблиц и содержит в основном данные, относящиеся к конкретному веб-сайту, такие как пользовательские данные, данные о вакансиях и т. Д.
Теперь я хочу расширить этот веб-сайт, включив в него также полный статистический модуль.Мы собирали множество пользовательских действий и других агрегатов из данных, собранных на нашем собственном веб-сайте, а также извлекали бы некоторые данные из Google Analytics API для использования в нашей статистике (мы создадим отчет в Excel, но также покажем статистические графики ицифры на странице (используя chart.js)).Мы не думаем (в обозримом будущем) использовать эти данные в других программах, но мы должны иметь возможность открывать некоторые данные для общественности с помощью API.Мы рассчитываем начать с примерно 300 000-350 000 точек данных, собираемых в день, но, конечно, эта сумма будет расти с каждым днем, чем больше пользователей мы получаем.
Использование нескольких баз данных в CodeIgniter, по-видимому, не является проблемой, поэтому основная проблема, с которой я остаюсь, заключается в том, как мне следует создать архитектуру для этого статистического модуля.
У меня есть пара идей о том, как начать это делать, но я не знаю, есть ли влияние производительности на решение от одного к другому или другие вещи, которые следует принимать во внимание.Моя основная идея сводится к тому, чтобы иметь таблицу, содержащую все «события», которые просто вставляются в эту таблицу каждый раз, когда выполняется действие, например, «пользователь зарегистрирован», «пользователь перевел учетную запись в личную», «пользователь нажал на X»,... Затем один раз в день (возможно, около полуночи) задание CRON будет выполняться над этой таблицей за прошедший день и объединять все значения в формат, используемый для наших статистических показателей.Эти агрегированные значения будут сохранены в новой таблице.Таким образом, мы можем регулярно очищать таблицу «событий», так как она очень быстро станет очень большой.
Идея 1: Расширить текущую архитектуру базы данных MySQL новыми таблицами для включения статистики.Я бы продолжил использовать текущую архитектуру базы данных и добавил бы 2 новые таблицы для событий и агрегированных значений.
Идея 2: Создайте новую базу данных, отдельную от текущей существующей, и используйте ее для вставки всех событий в таблицу там и агрегированных значений в новую таблицу там.
Примечание: у нас уже есть несколько CRONS, работающих в нашей текущей базе данных, обновляющих статусы и даты, отправляющих электронные письма, ...
Примечание2: проблемы синхронизации между базами данных не являются проблемой, так как мыникогда не будет хранить статистику на уровне пользователя.