Как сохранять большое количество статистических данных php + mysql?

Question

[serjioms]

+ От сервиса приходит около 800 000 POST/GET запросов с данными в сутки (около 600 запросов в минуту, не учитывая пики). Запрос содержит до 10 параметров, которые и нужно хранить в БД, это данные необходимые для постоения лайф статистики.
+ Нужно сохранять их в БД mysql (возможно используя промежуточные решения).
+ На сервере используется связка php + mysql.

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

Comments

[Макс]

600 запросов в минуту - это 10 в сек. фигня, ничего такого страшного. а что планируете с ними дальше делать? и сколько хранить?

[serjioms]

Макс: 600 в среднем, есть пики, где количество в раза 3 выше. Данные нужны для построения статистики

[AlikDex]

у нас 40тысяч запросов в минуту, мускул даже не потеет. Таблицы для статистики инноДБ + транзакции. Так что можете даже не напрягаться (если бд настроена конечно не рукожопами).

[Макс]

serjioms: ок. повторю вопрос - насколько долго Вы планируете хранить данные? данные будут лежать в "сыром" виде или агрегированные по каким-то параметрам (за минуту/час/день)

[serjioms]

Макс: данные в сыром виде. Хранить минимум месяц.

[Макс]

serjioms: 24 млн строк... Хранить - без проблем. А вот если хотите потом по этому делу строить сводные отчеты... у меня всякие суммы строятся не быстро. Лучше считать заранее

[serjioms]

AlikDex: это делает демон, который держит связь с БД или запускается скрипт каждый раз при гет зарпосе и инициализирует новое соединение?

[AlikDex]

serjioms: второй вариант. Где-то на хабре кстати статья была, у парня одного в секунду овер 30к инсертов\апдейтов, и ничего. Вопрос грамотной настройки я думаю

Answer 1

[Immortal_pony]

Например так:

1. Приемщик сообщений складывает сырые данные в какую-то таблицу.
2. Агрегатор вычитывает пачками сырые данные, агрегирует их и складывает подготовленные для отчетов данные в другие таблицы. Сырые данные помечает как обработанные.
3. Архиватор мониторит таблицу сырых данных и переносит старые обработанные данные в архивные таблицы. После работы архиватора таблица оптимизируется.

Comments

[serjioms]

Что то подобное?
<?php

$mysql = \mysql::_init();

$rawData = ( \request::is_post ) ? \request::get_raw_post_data : \request::get_raw_get_data;

$mysql->query("
INSERT INTO `userStat`
( `data` )
VALUES ( '$mysql->real_escape_string( json_encode( $rawData) )' )
");

[Immortal_pony]

serjioms, если речь о складировании сообщений, то примерно так, да.
Только по возможности лучше отказаться от кодирования в json. Особенно если набор полей не меняется.

Answer 2

[serjioms]

Я вижу такое решение. На сколько оно быстро?

<?php

    $mysql = \mysql::_init();

    $rawData = ( \request::is_post ) ? \request::get_raw_post_data : \request::get_raw_get_data;

    $mysql->query("
        INSERT INTO `userStat`
        ( `data` ) 
        VALUES ( '" . $mysql->real_escape_string( json_encode( $rawData) ) . "' )
    ");;

Далее кроном запускаться и обрабатывать данные для дальнейшей статистики.

Answer 3

[Кирилл]

pinba.org