Организация хранения статистики тизерной сети

teni13

Новичок
Доброго времени суток.

Есть тизерная сеть - сайты размещают у себя код, по коду сеть отдаёт блок с тизерами, учитывает показы тизеров и клики по ним. В систему входит mysql-сервер (живёт на отдельном физическом сервере, где больше нет ничего пока) и php-фронт + мемкеш на другом физическом сервере. Веб-сервер nginx.

Был выбран следующий вариант работы статистики:
При показе блока (так же и при клике) информация о нём заносится в мемкеш, для статистики необходимо учитывать следующие данные ИДБлока_ИДСайта_ИДТизера_ИДРекламнойКампании_ИДКатегорииТизера_ИДРегионаПоказа и соотв. количество показов и кликов для этого набора данных, суммы списанных и начисленных денег.
Именно под таким ключём: "stats_ИДБлока_ИДСайта_ИДТизера_ИДРекламнойКампании_ИДКатегорииТизера_ИДРегионаПоказа" данные и записываются в мемкеш при каждом клике-показе (если ключ уже есть, в нём просто обновляются числа)
Для учёта существующих ключей такого вида используется массив, так же лежащий в мемкеше.

Соответственно, при каждом показе блока из мемкеша читается список ключей, находится там соответствующий (или создаётся новый), модифицируется массив, с данными, лежаший под этим ключём и записывается в мемкеш:
PHP:
$aRecord = array(
	    			'views_teaser' => 0,
	    			'views_block' => 0,
	    			'clicks' => 0,
				'money_out' => 0,
				'money_in' => 0,
	    		);
Раз в Н минут (сейчас каждые 2 минуты) срабатывает скрипт, который всё это дело сбрасывает в базу, в одну таблицу stats, которая выглядит следующим образом:
PHP:
block_id,site_id,teaser_id,campaign_id,category_id,date,region_id,views_teaser,views_block,clicks,ctr,money_out,money_in
Эта таблица используется только для вывода статистических данных клиентам, все финансовые расчёты производятся по таблице лога кликов (каждый клик сразу пишется в базу, без всякого мемкеша).
И именно с этой таблицей возникла проблема, по которой и требуется хороший совет.

При сбросе статистики из мемкеша в базу на каждый ключ делается 2 запроса (селект - проверить наличие такой записи в таблице) и инсерт-апдейт. При росте показов до 10млн. уже начинаются проблемы - сброс статистики генерит очень много запросов и не понятно, как это количество уменьшить, mysql получает 1,5к запросов в секунду и виснет. Реже сбрасывать статистику можно, разница по объёму данных будет несущественна, но это всё равно будет пиковая нагрузка, которая повесит сервер.
Ещё интересно мнение, как можно лучше организовать временное хранение статистических данных в мемкеше (или без него)

Заранее спасибо за ответы.
 

WMix

герр M:)ller
Партнер клуба
ну вроде логично все, только не понимаю зачем ты порциями сбрасываешь мемкэш
с моей точки зрения в данном случае мемкеш это просто промежуточное хранение, созданное только лишь для того чтобы как можно быстрее обработать запрос....
те. дальнейший механизм представляет из себя постоянную обработку очереди запросов (возможно порциями) для записи постоянное хранилище...

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

...делить на сервера и тд

При сбросе статистики из мемкеша в базу на каждый ключ делается 2 запроса
PHP:
INSERT IGNORE
Ещё интересно мнение, как можно лучше организовать временное хранение статистических данных в мемкеше (или без него)
чесно мне сложно сказать, тужно тестировать, но возможно простая очередь звучит прозначнее... вопрос механизма этой очереди...
 

teni13

Новичок
те. дальнейший механизм представляет из себя постоянную обработку очереди запросов для записи постоянное хранилище...
Надо будет продумать этот вариант, спасибо
 

artoodetoo

великий и ужасный
Если я ничего не напутал, то сюда напрашивается

1. redis вместо memcache. т.к. редис персистентный (с опцией устаревания)

2. при записи в mysql использовать REPLACE или INSERT...ON DUPLICATE KEY UPDATE
 
Сверху