Учет показа баннеров с точки зрения производительности

[MrPIT]

Здравствуйте, уважаемые форумчане!
Пишу баннерную сеть, возник следующий вопрос:
Как правильно реализовать учет показа баннеров?
Смотрю на другие сети, почти у всех есть статистика показа на каждый день.
Вижу два пути:
1. Создать отдельную таблицу для показов, и туда записывать запись о каждом показе с фиксацией таймстемпа.
2. Записывать в таблицу баннеров число показов, а потом с помощью cron каждые сутки переносить число показов в таблицу статистики.

Кто сталкивался с такими вещами? Подскажите по поводу производительности. Или может есть ещё варианты?

Заранее, спасибо.

 

[AmdY]

MrPIT
а ты статистику в реляционной базе хранишь, типа mysql?

 

[Dovg]

Статистика - есть набор аггегированных показателей. Сырым данным там не место

Мы делаем так:
1. на каждом сервере на каждый показ статистика пишется в файл, в имени которого присутствует метка времени
2. раз в n минут файлы ротируются
3. раз в n минут запускается аналайзер файлов, который делает предварительную аггрегацию показателей статистики и записывает их в таблицу в бд.
4. таблица в бд в имени имеет метку часа
5. раз в час, при условии, что все данные уже поступили в таблицы, таблицы аггрегируются и данные попадают в "часовые таблицы статистики". Временные таблицы после этого удаляются
6. раз в сутки аггрегатор переносит данные из часовых таблиц в дневные.

Сразу скажу, что писать сразу в базу вредно - это очень плохо масштабируется. (гораздо хуже, чем файлы, да)
ps. Детальную статистику имеет смысл хранить, только если она действительно нужна.

 

[Dovg]

Chusha
Прошу аргументировать оба высказывания.

Мы раньше писали сырые данные в базу, но отказались. Видимо не просто так.
Сейчас у нас обрабатывается over 50М записей (хитов) в сутки и ничего не тормозит.

 

[MrPIT]

AmdY
да используется mysql

Dovg
Даже не думал, что все может быть так сложно.
Так когда вы писали сырые данные в таблицу вы чистили таблицу и тоже агрегировали данные? Или просто писали.

 

[AmdY]

не спешите, судя по всему товарищу нужно сразу посоветовать openx и не париться

 

[Dovg]

>Так когда вы писали сырые данные в таблицу вы чистили таблицу и тоже агрегировали данные? Или просто писали.
аггрегировали и удаляли (через delete) старое. Это медленно.

Если писать в базу, то надо ротировать таблицы, т.к. truncate/drop table в любом случае будет сильно легче, чем массовый delete.

 

[Dovg]

Chusha
Я утверждаю, что запись сырых данных в базу плохо масштабируется.
База - она для аналитики, а не сырья.
Моя мотивация:
Если я пишу в файлы, то при стоекратном росте нагрузки мне достаточно соразмерно увеличить число пишущих процессов (при условии, что они пишут на разные диски, например) или число серверов.
Если я пишу сырые данные в базу, то при таком же росте нагрузки все сдохнет, если не будет "сложных" решений типа мастер-мастрер репликации или шардинга, который может привести к потере целостности .

 

[grigori]

Dovg
я знаком с реализацией через демона, который сидит слушает udp и пишет в базу агрегированные данные раз в n минут
мне это кажется проще и на порядок производительнее, чем с файлом на каждый запрос

 

[AmdY]

кстати, и писать можно не в файл или лог, а сразу в демона.

 

[Вурдалак]

AmdY, мне что-то показалось, что grigori сказал то же самое.

 

[Dovg]

grigori: udp не гарантирует доставку, если я ничего не путаю.
А если демон упадет, то мы потеряем данные?

ps. По сути согласен

 

[ypeskov]

могу сказать, как это реализовано в том же openx.

текущая статистика пишется таки в промежуточные таблицы, а потом (там ест варианты и по крону и по определенному событию) переносится в финальные таблицы откуда потом выгребается.

Держит таки очень большие нагрузки и прекрасно масштабируется.