Вопросов будет несколько, извините. Просто связаны общей темой.
1) Где быстрее/надёжнее хранить логи (в лог-файлах или в БД)?
2) Какие поля необходимо делать в логе, чтобы в последствии можно было извлечь максимум информации из них в плане посещаемости сайта (я говорю о логах посещаемости)? Я подумываю над этими: дата, ip, браузер, ОС, страница, referer, идентификатор сессии. 

1) И быстрей и надежней естественно в базе данных.
2) Да, на первый взгляд все верно (если дата подразумевает под собой и время). А сессия зачем?
Вот только смысл? Логи сервера + webalizer дают полную картину без каких-либо усилий

Оно конечно так, только вот не будет ли напряжно писать столько информации в БД? А если посещаемость большая?..

Добавлено @ 18:37 

Чтобы отследить перемещение внутри сайта

Добавлено @ 18:37 
Нет, это бред.... Ну тогда весь список без сессии... 

1 (имхо) - файл. Можно на каждый день (неделю) свой файл. данные можно красиво удалять и экспортировать к себе на комп. Хотя того же эффекта можно добиться в базе.  (Пока писал уже изменил свое решение в силу базы  )


2 - что хочешь то и храни. Если хочешь узнавать IP - делай IP. Если хочешь мин. инфы - только Дата IP и действие.

Добавлено @ 18:47 
сессия конечно же лишняя будет! 

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

Да, это пока рабочий вариант.


Да, точно... Помню что для чего-то я это оставлял 
Одна проблема - долго это всё анализировать будет... 

AztEK, в файле - это плохо. представь при большой посещаемости, пишешь кучу логов. 
1. Как быстрее записать 
- в текстовый файл(надо искать конец файла)
- в типизированный файл(надо искать последнюю запись)
- в базу данных(где расположение записей не имеет значения, а физическое расположение, возможно, определяется по гораздо меньшему файлу главного индекса/ключа)
2. Где меньше места занимает:
- в файле храняться названия ОС, браузера
- в базе хранятся только индексы-ссылки на справочник ОС и браузеров
3. Что быстрее отсортировать 
- текстовый файл, который неминуемо придётся парсить для сортировки отбора
- база данных, с использованием индексов
Так что? Так где? одно дело - запись в день. другое дело - 1,5 тысячи записей. Потом - опять же транзакции и прочие механизмы, обеспечить которые "вручную" сложно и долго. так что? 

у меня для этого помнится целая софтина была сделана 

На чём написана? Может дашь посмотреть?


Это понятно. А в случае с БД, не будет ли обременительным засорять базу при каждом обращении?
Я не против БД, просто хочется найти оптимальный вариант. 

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

я совсем-совсем не понял  Если считаешь данные "мусором", то не записывай данные о посещении вообще. Или я не так тебя понял?

Софтина, которая реализует встроенные в ядро СУБД функции и операции  Я тоже подобные писал.



 

skyboy ладно-ладно, убедил  

нет-нет-нет 
просто для визуального отображения собранных данных.
Вот пара скриншотов:



 

z-END, классная штука! 

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

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

wil, ты видел когда-нибудь текстовый файл с разрушенным индексом, который не открывался?   Не надо категоричнсоти, просто помнить, что Цезарю - цезарево.  

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

Это сообщение отредактировал(а) wil - 15.6.2006, 11:04

Если говорить о надежности (а именно об этом спрашивалось вначале), то не понимаю как можно считать БД надежнее. Не так запишется, не то запишется, еще что-то....
Это во-первых. Во-вторых БД лучше там, где выбирать записи приходится чаще. А в данной ситуации, по-моему, чаще производится запись как раз таки. К этому добавим еще и индексы (кто-то о них кажется вспоминал) - при большой БД с индексами запись будет тормозить.
Так что не нужно такой категоричности.
Потом - какая БД хоть? Мускуль как я понимаю тоже на файлах работает и записывать оно тоже будет в файлы. О каких трудностях записи в файл идет речь??

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

Вот мое мнение ... 

Хранение в "plain text files" - это "третий клас, вторая четверть"... Не в каменном век живем , уважаемые.

Drache, 
Гм... вообще то любая БД пишет в файлы. И что теперь? оракл и постгрес на свалку отправить? 

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

PS: и ничего личного...  

Поправляю  
Далеко не всегда, допустим довольно крупные и не безызвестные новостные сайты хранят именно в файлах и на это есть ряд причин!

Ну а в целом и данной ситации в частности конечно бд рулит имхо.


 

Каких?
 

Скорость. Невозможность SQL-инъекций. Плюс, можно так же самому разработать алгоритм поиска, какой-нибудь сверхумный метод деления пополам. 

Ну конечно... Файлы быстрее БД??



Бред. Оно того не стоит, достаточно нормально обрабатывать данные.


Можно. Только геморроя... И скорость... 

имхо бд будет медленней только при хранении очень больших кусков информации (записи мегов по 5). не знаю что так можно хранить.

тогда уж сразу на голый html переходить  

      при ведении логов?! пример в студию=) 

В общем-то, да. Гугл-то на файлах построен.
Но сам не проверял. Потому что от мускула отказаться не могу  

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

Короче за самоуверенные и непрофессиональные утверждения очень чешутся руки поставить минус. 

AztEK,  а BobiKK то прав.
Да действительно, у гугля не так как у людей, но на то есть свои причины...

далее оффтоп:

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

Во-первых, это собственная файловая система Google File System, которая оптимизирована для работы с большими блоками данных по 64 МБ, а также обладает повышенной защитой от сбоев. Вся информация копируется и хранится в трех местах одновременно, при этом система способна очень быстро находить реплицированные копии, если какая-то машина вышла из строя. Задачи автоматического восстановления после сбоя решаются с помощью программ, созданных по модели MapReduce.

Серверы работают под управлением Linux. За основу был взят стандартный дистрибутив Red Hat, в котором ядро операционной системы было модифицировано с учетом нужд Google.

От себя добавлю, что все это связано воедино и представляет собой нечто похожее на NetOs Plan9.

Tristan Louis отталкиваясь от суммы затрат Google на оборудование (250 миллионов долларов) подсчитал, что поисковик обслуживает кластер в котором находится от 45000 от 80000 серверов. Производительность такого кластера оценивается от 126 до 316 терафлопов.


Но это не меняет моей точки зрения по поводу использования БД, которую в данном контексте можно назвать скорее надстройкой над файловой системой вкупе с функциональным шеллом. 
 

Оу... Тогда извинясь...
Именно ! 

Alone, собственная файловая система — есть отдельные файлы индекса и отдельные файлы данных (в действительности там 5 типов данных, 3 — индексных и 2 для данных, но не суть). Алгоритмы чтения-записи оптимизированны по моим сугубо личным ощущениям для работы с действительно большим количеством информации и хранения копий файлов в оперативной памяти (memory maping). Отказались от БД видимо из-за невозможности построения на ней в большинстве случаев (кроме Radware и ему подобных) полноценной кластерной системы.
Все это не абы с потолка, а в виду наличия сервера GB-5005 (http://www.google.com/enterprise/gsa/product_models.html) с полным SDK и частичным исходным кодом индексирующего механизма.

Не люблю огорчать, но BobiKK все-таки не прав. Точнее не совсем прав.

Ну а по теме, создание собственной ФС для ведения логов не оправдано ни на грош. В каких бы масштабах эти логи не велись. БД (MySQL или MSSQL) хватит с головой, о чем собственно я уже говорил в первом ответе.

Кстати, по-моему здесь неправильно звучит название темы.
Логи - это, в моем понимании, просто отслеживание и записывание ситуации на случай если что-то пойдет не так и нужно будет узнать что же случилось.
А то, о чем мы все здесь говорим, по-моему, называется статистика.

Так вот для логов, думаю, удобнее юзать файлы, а для статистики, конечно же, БД.

Или я в чем-то неправа? 

Drache, лог - это протокол. Протокол чего угодно: сбойной ситуации, поведения юзера на сайте, работы парламента, в конце концов... а статистика - это уже процесс анализа этих самых протоколов для извлечения "полезных" или нужных сведений.  

значит я была неправа изначально, вследствие моего неправильного понимания этого слова  

Исходя из всего выше сказанного, появились определенные выводы:
1) для сбора и храниения информации (так называемых логов сервера/сайта) наиболее рациональнее, с точки зрения скорости и удобства выборки, подходит База Данных.

2) для обработки логов (сбора статистики и наглядного представления получившихся данных) удобнее использовать отдельную программу/скрипт (у кого что)... подразумевается нечастое обращение (1-2 раза в неделю/месяц).