Форум hotibo.ru

Если ответить не сильно задумываясь:
количество посетителей в сутки;
откуда (по каким ссылкам) они пришли;
наиболее посещаемые страницы.

Остальное, imho, вторично и не сильно интересует.

Иногда возникает желание покопать глубже, скорее из интереса, посмотреть: что ищут на сайте; по каким словам находят сайт; как он представлен поисковиками; статистика по браузерам.

Статистика по операционкам;
еще есть:
- Коды ошибок HTTP;
- Роботы (какие, когда заглядывали);
- Трафик (сколько накачали от меня страниц и пр., интересно, но не актуально);

Мне кажется, верстальщику этого достаточно. Остальное (география, время на сервере) - скорее для рекламщика, раскрутчика.

Предпочитаю цифры. Довольно спартанская статистика, которой мне достаточно для общей картины посещаемости.
Наверняка, кто-то поинтереснее расскажет. Тема не закрывается. Интересно еще мнения послушать.

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

Кстати, неплохая идея просто посмотреть, как другие это cделали. Например, яндехом первое попавшееся:
вот (guest / demo).
Сразу скажу, никакого отношения к ней не имею, рекламой тоже не считать.

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

Мне бы еще понравилась не самая красивая, но быстрая система. Чтобы основную картину работы сайта можно было увидеть сразу на главной странице. Т.е. сперва основные, общие отчеты, а все подробности по ссылкам.

Splurov написал:

На счёт БД - ну допустим даже если каждый хит хранить в течении месяца - это 3 млн записей по вашим цифрам. Это не много для того же MySQL.

имелось ввиду не объемы информации, а нагрузка на базу из-за частого обращения.

Splurov написал:

И в чём ещё можно хранить данные, кроме чем в БД?

действительно, и как вообще другие программы без БД обходятся?

Splurov написал:

На счёт БД вы сказали чушь, извините.

не соглашусь

Splurov написал:

И ещё заостряю внимание. Что использовать, если не БД?

Обычные файлы. Работа с файлами в разы быстрее, чем с БД. Для статистики файлы как раз очень даже подходят.

400-500 тыс. обращений к БД. Это около 60 тыс. в час во время максимальной посещаемости. Т.е. 16 подключений к БД в секунду. Многовато получается, на грани фола :-)

"Обычные файлы. Работа с файлами в разы быстрее, чем с БД. Для статистики файлы как раз очень даже подходят.

400-500 тыс. обращений к БД. Это около 60 тыс. в час во время максимальной посещаемости. Т.е. 16 подключений к БД в секунду. Многовато получается, на грани фола :-)"
Выбоки из файлов тоже в разы быстрее?
16 подключений это мало. Загрузка сервера не велика. Я ещё раз повторюсь, что вы ошибаетесь в своих выводах. Может быть вы не используете индексы или испольузете их неправильно? Может быть вам никогда не приходилось делать сложные выборки?

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

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

Мммм...
Давайте вспомним историю. Зачем вообще придуманы СУБД?
Итак: хранили люди данные в файлах и бед себе не знали. Ну когда хранится только одно поле вообще проблем нет, если несколько - разделим их специальными символами-разделителями. Тоже хорошо.
Но если мне и этот символ нужно хранить? Ну используем другой разделитель. Или будем брать поля в кавычки. Постепенно файл растёт... Записать данные в файл - не проблема - добавить новую строку.
Считать значение из середины? Ну нужно открыть файл и начать считывать строку за строкой, пока не встретим нужную запись. Последовательный доступ. Знаете наверное. Чем больше файл, тем дольше... Неудобно. Долго. Ага. Придумали файлы прямого доступа. Нужно хранить в файле какой-то идентификатор записи.
Лучше файл хранить не в стандартном текстовом формате, а в специальном - удобном для быстрого чтения из файла.
Но это только если мы знаем, ЧТО нам нужно считать. А если нам нужно найти строку по шаблону? Опять последовательный доступ. Планомерное чтение всех записей и сравнение с шаблоном.
Постепенно стали вырисовываться алгоритмы поиска информации в записях и форматы хранения этих данных.

Теперь такая ситуация: к файлу обращается не один пользователь(программа), а несколько. Причём кто-то пишет, а кто-то считывает. Нужно грамотно следить за использованием файла - в нужно время блокировать с разными правами и т.п.

Постепенно люди и пришлю к понятию баз данных - стандартизированные форматы хранения информации.
Кроме того, если много разных людей обращаются из разных мест - им должен быть досконально известен формат хранения. И они должны придумывать свои алгоритмы работы с этими данными. А зачем, если можно отобрать лучшие алгоритмы и поставить между пользователем и БД специальную программу, которой дается стандартизированный запрос, а она сама обращается к файлу данных, блокирует его и т.п. и выдаёт обратно нужные данные (или выполняет нужную запись/измененение данных)?
Вот вам и СУБД.

Тут сказали мысль, что доступ к файлу быстрее, чем к БД. Конечно. Открыть файл быстрее. Считать одну строку - да, тоже быстрее. А дальше?
А если нужно цитирую:
количество посетителей в сутки;
откуда (по каким ссылкам) они пришли;
наиболее посещаемые страницы.

Если файл достаточно большой сколько займёт времени "определить количество посетителей в сутки"?
Мы будем читать весь файл в память. Мы будем писать свой алгоритм чтения и подсчёта....
Долго. Сложно.
Гарантирую, что СУБД с такой задачей справится НАМНОГО быстрее. А точнее - десятые и даже сотые доли секунды!!!

Кроме того, при 16 запросов в секунду из разных мест - как вы будете блокировать файл? Кто-то меняет файл, кто-то читает. На сами операции блокировки /открытия файла будет уходить много времени. Растёт нагрузка на систему. Сложные алгоритмы. Ужос одним словом.

СУБД же держит файл данных постоянно открытым. И блокирует/разрешает на программном уровне. Намного быстрее.

А если файл лежит на другом диске / сервере? ....

К чему я это всё? К тому, что СУБД - логичное продолжение хранения данных, истоками которого лежит "плоский" файл.

Если нам нужно хранить свою телефонную или записную книжку - подойдёт и файл.
А настолько объемные и сложные данные - конечно же СУБД. Это логично и правильно.