Намечается крупный проект типа рекламной сети! И встает вопрос хранения данных статистики показов и кликов и ip адресов. Буду рад услышать ваши советы по этому поводу! Где хранить в БД(Mysql) или в текстовиках? и почему? Заранее благодарен!
ARACOOL База данных. Самое простое объяснение: файлы разрастаются, и каждый раз парсить большой файл...
Я тоже думал об этом. а если удалять со временем старые архивы? Что все таки выгодней и быстрей будет?
Это получается при каждом новом показе, идет запрос к БД, представим 1000 показов в минуту, это будет большая нагрузка на сервер. Как быть с этим?
База данных в любом случае, чтобы не выбрал. Просто для быстрой реакции используют кеш-решения в оперативной памяти.
для начала просто правильная настройка БД - выделение достаточного кол-ва памяти под демон + правильная индексация. Помогает в 95% случаев. Для высоконагруженных проектов советуют больше PostgreSQL, чем MySQL. затем - использование кеш-решений в памяти. Здесь уже на выбор вашего админа. после кеш-решений следует кластеризация. вроде всё а про хранение в файлах можешь забыть - тут даже кеш в памяти не поможет.
<offtop> Был бы чуть более распространен на хостингах постгрь, я бы давно уже на него перепрыгнул с мускуля. </offtop>
Не могли бы вы в двух словах описать взаимодействие Memcache и MySQL. Как должны быть они связаны и работать на пару?
гугл всегда придёт на помощь а если проще, то в классе доступа к БД при запросе происходит проверка - если запрос с данной строкой имеется в кеше мемкэшед, то делать запрос оттуда, иначе - из базы. Это принцип работы ЛЮБОГО кеширующего механизма. способов реализации - море. как будет удобнее - так и пользуются. оффтоп: как раз для этого и делаются абстракции и классы доступа к БД вместо прямого обращения через ф-ции mysql_ / pg_ / mysqli
Меня волнует больше не выборка из базы, спасибо за некоторые пояснения, а больше запись статистики. Это сколько будет показов и сколько кликов, столько ко же и запросов для записи. Вот это узкое место меня интересует!
тогда создаются две разные сущности: 1. история кликов - кто, когда, куда, откуда, во сколько, зачем и т.д... т.е. полная инфа о клике 2. счётчики кликов - значения, хранящиеся в кеше, которые пересчитываются при перезапуске приложения т.е. записываете клик в базу, +1 к необходимым счётчикам в памяти (счётчиков может быть несколько). а т.к. счётчики хранятся в памяти, то и запросы к БД даже делать не придётся и работать будет архибыстро. для просмотра истории, правда, всё же придётся, но не думаю, что вам нужно будет её смотреть так часто. у самого движка БД обычно есть встроенные механизмы отложенной записи на диск - т.е. запись производится не сразу после вставки новой строки, а через некоторое время скопом сбрасываются все изменения. Об этом слышал, но сам не сталкивался (то бишь читай документацию). Иногда может быть рассинхронизация счётчиков в памяти, которую можно изящно поправлять раз в 10 минут с помощью пары запросов в БД. Счётчики могут выступать также в качестве статистики при определённом умении иногда для статистики составляют несколько таблиц: 1. самая оперативная - посекундная, все операции в памяти 2. отложенная - это раз в 10 минут из памяти делается запрос за предыдущие 10 минут и записывается в данную таблицу. В самой же памяти данные, старше 10 минут удаляются (НЕ ТЕКУЩИЕ 10 МИНУТ!) 3. по часам - то же самое, что и отложенная, но статистика собирается уже из таблицы 2 4. по дням - статистика собирается из таблицы 3 5. и т.д... данный подход исходит из того, что пользователю врядли нужно будет смотреть секундную статистику 5-дневной давности - работает быстро, памяти требует мало. Обычно это выводят графиком. Если же нужно посекундный график 5-дневной давности, то тут же нужно серьёзно смотреть в сторону кластера для БД и терабайтных HDD. Вообще большинство зависит от того, что конкретно нужно в данном приложении. И, конечно же, от архитектуры.