Уники и равы mysql

как собственно лучше писать в статы
определяем уник - 1 просмотр отдельно взятой страницы
ip cookie page col
777.77.77.77 vsdbbsdbvhujsdbjhb http://google.com 1
определяем рав - 1 просмотр отдельно взятой страницы
ip cookie page col
777.77.77.77 vsdbbsdbvhujsdbjhb http://google.com 2

или
определяем рав - 1 просмотр отдельно взятой страницы
ip cookie page
777.77.77.77 vsdbbsdbvhujsdbjhb http://google.com
777.77.77.77 vsdbbsdbvhujsdbjhb http://google.com

при первом способе определения рава, размер в 2 раза меньше, но менее удобно считать налету?

я бы предпочёл удобство подсчёта налету

промотров ожидается от 7к в сутки

В первую очередь нужно подумать как уменьшить размер хранимых данных, без этого производительность через несколько месяцев уйдет далеко за рамки определения реального времени.
1. IP адрес нужно хранить не как строку, а как 4-ех байтный INT
2. Количество вариантов URL ограничено, поэтому разумней создать справочную таблицу с ними и хранить лишь ссылку. Это в случае если будет храниться необработанная статистика долго.
3. Зачем хранить куку? Тем более это частный случай когда она одна, обычно их много.
4. Раз в сутки (например) производить обработку данных, сохраняя их в удобном виде для хранения и обработки, например:
дата | id url | хостов | хитов
первичный ключ по (дата, id url)

Хотя это все пальцем в небо без конкретной задачи, которая стоит.

1 согласен
2 многоуровневый каталог, страниц очень много и нужна статистика по разделам и т п
3 чтобы уникализировать посетителя - md5(IP+timestamp)
по одному IP мало, кука живет сутки
4 тоже думал об этом

2. Не проблема, их все равно меньше чем например UNSIGNED MEDIUMINT ~ 16M, а размер в сотни раз меньше получится. Справочная таблица создается на лету по мере необходимости - если есть запись, используется ее идентификатор, нет - добавляется и используется.
3. Так уникальность не обеспечишь - если с одного IP будет 2 запроса в секунду, например пользователь больно резкий и нажал 2 раза подряд, то будет неприятная ошибка БД. Куке можно сказать жить сколько надо. Тут еще и варианты подсчета быть могут - посетители и хосты - это разные вещи, первые определяются по IP, вторые по куке. Если считает именно посетителей, то нафиг их IP хранить?
В любом случае вызывающая система должна быть основана на JS чтобы отсеять поисковиков, они тебе создадут не хилую статистику
Без 4 через пару месяцев попытка построить отчет положит сервер, говорю по опыту - видел уже такие системы, которые сдавались заказчику без тестов под большими объемами данных.

В зависимости от задачи, в некоторых местах можно использовать таблицы типа MEMORY (HEAP). Если не ошибаюсь так реализовано в стримротаторе.

+1 по п.4 - архив желателен, также можно разграничить архив по неделе, месяцу, году (использовать разные таблицы)

Dim82 писал:

также можно разграничить архив по неделе, месяцу, году (использовать разные таблицы)

Это крайняя мера когда индекс не помещается в памяти
Таблица типа MEMORY в данном случае не подходит - объем данных слишком большой, интенсивность использования низкая.

iRoot писал:

В любом случае вызывающая система должна быть основана на JS чтобы отсеять поисковиков, они тебе создадут не хилую статистику

а примерно как это реализовать, я видел статы этого портала - удручающее зрелище

Sterx писал:

а примерно как это реализовать, я видел статы этого портала - удручающее зрелище

Какого портала? Реализовать довольно просто - на страницу вставляется JavaScript (JS) код, который вызывает обращение к системе статистики, сообщая, что на страницу зашел посетитель. Так например Google Analytics собирает статистику.
Этот метод исключает роботов, потому что JS исполняется только в браузере посетителей.

iRoot писал:

Какого портала? Реализовать довольно просто - на страницу вставляется JavaScript (JS) код, который вызывает обращение к системе статистики, сообщая, что на страницу зашел посетитель. Так например Google Analytics собирает статистику. Этот метод исключает роботов, потому что JS исполняется только в браузере посетителей.

по принципу каунтера в общем, понятно

iRoot:

Цитата:

Справочная таблица создается на лету по мере необходимости - если есть запись, используется ее идентификатор, нет - добавляется и используется.

а примером запроса можешь помочь? в смысле INSERT в один запрос с вложенными селектами?

Вообще правильно писать тупо в текстовый файл логом, а кроном пускать скрипт каждые n минут, распарсывать лог и записывать в базу. Для сервера нагрузка будет в десятки раз меньше.

Но это все херня, ибо Sterx: не подумал о такой вещи, как время, за которое он будет считать уника / рава, т.е. когда рав скинет флаг рава и снова станет уником Эта простая поправка напрочь выкидывает ему пункт 1 и оставляет только пункт 2, где добавляется еще одно поле "время визита".

Sterx писал:

а примером запроса можешь помочь? в смысле INSERT в один запрос с вложенными селектами?

INSERT INTO visits SET url_id=(SELECT id FROM urls WHERE url='....')
Столбец url конечно должен быть уникальным с соответствующим индексом

Stek:
не нравится мне такая реализация
рав - это повторная запись с той же кукой, которая живет сутки
iRoot:
это понятно, но по твоим словам делать нужно проверку на наличие того самого url и если нет - писать
если хранить связи - либо несколько запросов либо хранимая процедура

Нуу... я только предоставляю варианты, а не готовое решение.
Дальше можно продолжать додумывать:
- 2 легковесных запроса, ничего страшного не произойдет, все будет шустро бегать
- хранимая процедура - замечательный вариант, немного лучше первого
- внешние ключи, обеспечивающие целостность базы, нужно перехватывать исключение при вставке несуществующей связи, добавлять ее и повторять запись. Экстравагантно, работать будет, но в программировании строить логику на обработке ошибок считается дурным стилем.
- другие варианты...

P.S. текстовый файл это конечно жесть... особенно в плане реализации блокировок, работать будет только под слабой нагрузкой, тогда вероятность сбоя низка

Цитата:

P.S. текстовый файл это конечно жесть... особенно в плане реализации блокировок, работать будет только под слабой нагрузкой

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

Код:

<?php $fp = fopen('file.txt', 'a'); fwrite($fp, "IP;TIME;COOKIE;PAGE"); fclose($fp); ?>

Stek писал:

лоооллл , ты хоть представляешь себе, сколько записей в секунду отработает конструкция Код: <?php $fp = fopen('file.txt', 'a'); fwrite($fp, "IP;TIME;COOKIE;PAGE"); fclose($fp); ?>

В однопотоковой среде - очень много, но мы же говорим про реальный мир, где бывают ситуации, когда один и тот же ресурс запрашивает несколько процессов одновременно и если они не синхронизированы и отсутствует механизм блокировок, то результаты могут быть плачевны.
Хотя, да, действительно, я уже загибаю - в данном случае потери данных не приведут к серьезным последствиям, да и будут они происходить крайне редко при такой прогнозируемой посещаемости. Для решения "на коленке" волне годиться.

iRoot: дабы не быть голословным, мой домашний компик, купленный пару лет назад, на единственном диске под виндами и с включенными торрентами, сделал 100к записей за 18 секунд. Т.е. грубо говоря 5к в секунду.
В сутках 86400 секунд, ну с учетом плаванья трафика возмем 30000 активных. 30000*5000 = 150.000.000 , т.е. 150миллионов записей в файл.
Не думаю что грозит такая интенсивность записи

Ты кстати не обращал внимания, что большинство логов пишуться именно в текст ? Что тот же mysql для транзакций и их отката, использует текстовые лог файлы. Что вэб серверы пишут логи так же в текстовые файлы ... хотя могли бы и в базу данных. Но видимо в текстовый файл легче и быстрее.

Да, именно так, это для меня не новость, но они это делают в последовательном режиме - с файлом работает один процесс, открыт на запись только один дескриптор. Проблемы возникают при параллельной работе на запись нескольких процессов.
По поводу логов MySQL было бы наивно использовать для лога отката при сбое базу данных, ведь именно для отката БД она и используется. Там много своих тонкостей.
Пошел страшный offtop, думаю основная идея, которую я пытался донести - а именно возможные проблемы с параллельной работой на запись в файл несколькими процессами ясна.
Да и автор топика спрашивает в первую очередь как удобней считать потом статистику. В этом вопросе текстовый файл конкретно отсасывает!