Рекомендации по статистике PHP и MySQL для веб-приложения

Question

справочная информация:

Я унаследовал php webapp в моей маленькой компании и после многих лет нытье, наконец, получили иди, чтобы выбросить код спагетти и начать снова.

Мы хотим регистрировать каждое действие, выполненное в системе, например:

• пользователь X просмотрел элемент Y
• пользователь X обновил элемент Y
• новый предмет Y по городу Z

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

В предыдущей версии у нас есть таблица с 20 000 000 записей с 2005, так что это даст вам представление о количестве данных, которые мы уже есть и это только для одной из многих статистических данных.

актуальный вопрос:

Какие рекомендации вы имеете при построении практически в реальном времени система для создания этой статистики?

Примечания:

1. Графика уже покрыта через API визуализации Google
2. Я не боюсь использовать какие-либо базы данных NoSql или серверы обмена сообщениями, кроны или все, что получает работа сделана, но предпочитаю mysql / php решение
3. Мой нынешний ход мыслей автоматически создавать таблицу для каждого статистику я хочу сохранить и создать несколько таблиц агрегации (по месяцам, по дням, по годам) кешировать результаты.
4. Я знаю, это широкий вопрос, но любые предложения приветствуются

Answer 1

Если все пользователи должны быть зарегистрированы, я бы пошел с полным нормализованным решением.

USERS TABLE            OBJECTS TABLE
---------------        -----------------     
user_id (primary)      object_id (primary)


USERS_TO_OBJECTS TABLE
--------------------
user_id (index)
object_id (index)
time (index)
action (index)
? object_type (index) // could be useful to speed things up

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

Редактировать:

Скажите, что город X (идентификатор 9876) был обновлен пользователем 123 (идентификатор 1234) ...

1234    - user_id (the user that did the action)
9876    - object_id (the object where the action was done)
xyz     - time
updated - action type (so that you select only specific actions)
city    - object type (so that you select only specific objects)

Я заполнил эту таблицу 40-миллионными строками, и результаты вполне приемлемы.

0,002 секунды для простого СЧЕТА по количеству ОБНОВЛЕННЫХ городов за последнюю НЕДЕЛЮ.Данные были вставлены случайным образом.

Редактировать 2

Если вы обнаружите, что таблица действительно огромная, вы можете прибегнуть к разделам MySQL, и ваша схема будет идеальной.Я действительно не знаю, как вы собираетесь использовать таблицы, но вы могли бы:

РАЗДЕЛЕНИЕ ПО ДИАПАЗОНУ.Организовать раздел по датам.Каждый новый месяц или около того у вас будет новый раздел.

РАЗДЕЛЕНИЕ ПО КЛЮЧУ.Организовать раздел по действиям.Каждое действие переходит к соответствующему разделу.

Вы можете проверить подробнее о разделах на сайте MySQL и . В этой статье вы узнаете о тонко настраиваемых разделах.

Answer 2

Вы можете рассматривать «базу данных», как Redis.Redis использует связанные списки для хранения типов списков, поэтому вы можете легко добавить LPUSH к списку, например так:

$action = array(
    "type"=>"page_view",
    "url"=>"/example/path",
    "user"=>"user1",
    "timestamp"=>$_SERVER["REQUEST_TIME"]
);
$r = new Redis();
// Redis connection info //
$r->lPush("global_history", json_encode($action));

Операция LPUSH выполняется на O(1), так что это не должно быть проблемой.Получение результатов может быть немного сложнее (O(n) время для списков).Redis также в значительной степени основан на памяти (хотя сборки dev включают в себя поддержку «виртуальной памяти»), поэтому он быстрый, но вы можете легко выйти из него.

Я использую эту технику для записи истории и статистики длямузыкальный сайт я запускаю.Он очень успешен и дает очень быстрые результаты с минимальными усилиями.

Если вы хотите сделать его более надежным, вы можете использовать Hadoop или другую технологию для удаления из конца списка (RPOP) и архивирования результатов.в более постоянный формат (например, XML отправляется в Amazon S3).После этого ваши визуализации Google могут искать свои данные из архива (который будет статическим, скомпилированным) при просмотре более старых данных и интерфейса Redis для получения более свежих данных.

Надеюсь, это поможет!

Answer 3

Я рад, что вы наконец-то получили зеленый свет на редизайн этого проекта.Возможно, уже слишком поздно для ответа на этот вопрос, но реализация MongoDB (с ее функцией Capped Collections) сделала бы такую ​​работу лучше.Это не слишком много времени для его реализации, так что, возможно, все еще есть шанс.

В любом случае, надеюсь, что все идет хорошо.