Форум пользователей MySQL

Боюсь себе представить PHP работающий на 10к RPS. Более лучший способ — шардировать базу так же,
как вы шардировали морды (не верю в 10к с одной морды). Если у Вас 100к видов баннеров, храните
первые 25к на одной машинке, вторые 25к на другой и т.д.

Горизонтальное масштабирование рулит

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

UPD: и после этого я почитал код

LOCK TABLES banner_stats WRITE, banner_views_memory WRITE;
UPDATE banner_stats d, banner_views_memory m SET d.views=d.views+m.views WHERE d.banner_id = m.banner_id;
TRUNCATE banner_views_memory;
UNLOCK TABLES;

paulus написал:

Боюсь себе представить PHP работающий на 10к RPS. Более лучший способ — шардировать базу так же,
как вы шардировали морды (не верю в 10к с одной морды). Если у Вас 100к видов баннеров, храните
первые 25к на одной машинке, вторые 25к на другой и т.д.

Горизонтальное масштабирование рулит

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

UPD: и после этого я почитал код

LOCK TABLES banner_stats WRITE, banner_views_memory WRITE;
UPDATE banner_stats d, banner_views_memory m SET d.views=d.views+m.views WHERE d.banner_id = m.banner_id;
TRUNCATE banner_views_memory;
UNLOCK TABLES;

Насчёт переноса данных с banner_views_memory в banner_stats то чо вы написали по моему отличный вариант.

Что насчёт начальных инсертов в  banner_views_memory.
Я при каждом обращении делаю INSERT INTO banner_views_memory (banner_id) VALUES ($banner_id) , таблица по бешеному растет ...
Мне предложили - складывать результаты сразу на лету в memory table, делать UPDATE  спомощию INSERT INTO ... ON DUPLICATE KEY UPDATE views=views+1

Лучший ли этот вариант ?
В моем случае при каждом обращении просто добавляется запись без всяких проверок.
Во втором предложении идет поиск по id, закрывается запись, производится запись.

Что скажите ?

Добрый день. У меня вопрос.

Почему эффективней хранить записи в виде небольших файлов?

Неужели PHP будет эффективней копаться в груде маленьких файлов с через запятую перечисленными значениями вида количество показов, количество кликов, реферер пользователя и т.д., а также подбирать необходимые к показу баннеры? Разве MySQL не для этого придумали?

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

Наверное, поздно уже, но да внесу свои пять копеек.

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

Общая идея:
Использовать генератор рандома, возвращающий равномерно распределенные значения.

Например, с точностью до десяти показов:
IF FLOOR(RAND()*10)+1 = 10 THEN
     UPDATE banner_stats d SET d.views=d.views+10 WHERE d.banner_id = m.banner_id;
END IF

Решение позволяет резко сбросить нагрузку на СУБД ценой точности.

Решение имеет смысл при показателях больших, чем точность в степени четыре.
Необходимое (но не достаточное) условие -- нормальный генератор рандома. А то бывает такой рандом, что хоть вешайся.
Чревато тем, что если есть какие-то баннеры, к которым редко обращаются, регистрация таких обращений будет проходить еще реже.