)2 - что хочешь то и храни. Если хочешь узнавать IP - делай IP. Если хочешь мин. инфы - только Дата IP и действие.
Добавлено @ 18:47
сессия конечно же лишняя будет!
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Для профи > Грамотное ведение логов |
| Автор: AztEK 14.6.2006, 18:05 |
| Вопросов будет несколько, извините. Просто связаны общей темой. 1) Где быстрее/надёжнее хранить логи (в лог-файлах или в БД)? 2) Какие поля необходимо делать в логе, чтобы в последствии можно было извлечь максимум информации из них в плане посещаемости сайта (я говорю о логах посещаемости)? Я подумываю над этими: дата, ip, браузер, ОС, страница, referer, идентификатор сессии. |
| Автор: xolod 14.6.2006, 18:30 |
| 1) И быстрей и надежней естественно в базе данных. 2) Да, на первый взгляд все верно (если дата подразумевает под собой и время). А сессия зачем? Вот только смысл? Логи сервера + webalizer дают полную картину без каких-либо усилий |
| Автор: AztEK 14.6.2006, 18:36 | ||||
Оно конечно так, только вот не будет ли напряжно писать столько информации в БД? А если посещаемость большая?.. Добавлено @ 18:37
Чтобы отследить перемещение внутри сайта Добавлено @ 18:37 Нет, это бред.... Ну тогда весь список без сессии... |
| Автор: Рыжий 14.6.2006, 18:45 |
| 1 (имхо) - файл. Можно на каждый день (неделю) свой файл. данные можно красиво удалять и экспортировать к себе на комп. Хотя того же эффекта можно добиться в базе. (Пока писал уже изменил свое решение в силу базы ) 2 - что хочешь то и храни. Если хочешь узнавать IP - делай IP. Если хочешь мин. инфы - только Дата IP и действие. Добавлено @ 18:47 сессия конечно же лишняя будет! |
| Автор: z-END 14.6.2006, 18:48 | ||
почему-же... я на одном сайте так делал... чтобы можно было получать детальную статистику по каждому юерзу откуда пришел, где ползал и т.п. |
| Автор: AztEK 14.6.2006, 20:54 | ||||
Да, это пока рабочий вариант.
Да, точно... Помню что для чего-то я это оставлял  Одна проблема - долго это всё анализировать будет... |
| Автор: skyboy 14.6.2006, 21:06 |
| AztEK, в файле - это плохо. представь при большой посещаемости, пишешь кучу логов. 1. Как быстрее записать - в текстовый файл(надо искать конец файла) - в типизированный файл(надо искать последнюю запись) - в базу данных(где расположение записей не имеет значения, а физическое расположение, возможно, определяется по гораздо меньшему файлу главного индекса/ключа) 2. Где меньше места занимает: - в файле храняться названия ОС, браузера - в базе хранятся только индексы-ссылки на справочник ОС и браузеров 3. Что быстрее отсортировать - текстовый файл, который неминуемо придётся парсить для сортировки отбора - база данных, с использованием индексов Так что? Так где? одно дело - запись в день. другое дело - 1,5 тысячи записей. Потом - опять же транзакции и прочие механизмы, обеспечить которые "вручную" сложно и долго. так что? |
| Автор: z-END 14.6.2006, 23:00 | ||
у меня для этого помнится целая софтина была сделана |
| Автор: AztEK 15.6.2006, 07:49 | ||||
На чём написана? Может дашь посмотреть?
Это понятно. А в случае с БД, не будет ли обременительным засорять базу при каждом обращении? Я не против БД, просто хочется найти оптимальный вариант. |
| Автор: skyboy 15.6.2006, 08:19 | ||||
| AztEK, опять же - не понял. "Засорять базу" не хочешь, а "засорять" текстовый файл на том же сервере, но при более медленном(не кешируется запись), менее безопасном(где транзакции) и менее эффективном(я ж приводил пример про запись в файл дублирующейся информации - ОС, браузеры) доступе - это тебе как? А вот это
я совсем-совсем не понял Если считаешь данные "мусором", то не записывай данные о посещении вообще. Или я не так тебя понял?
Софтина, которая реализует встроенные в ядро СУБД функции и операции Я тоже подобные писал. |
| Автор: AztEK 15.6.2006, 08:37 |
skyboy ладно-ладно, убедил  |
| Автор: z-END 15.6.2006, 10:06 | ||
нет-нет-нет просто для визуального отображения собранных данных. Вот пара скриншотов:     |
| Автор: wil 15.6.2006, 10:30 |
| z-END, классная штука! поправьте меня если я не прав, но думаю всегда если есть выбор стоит использовать для записи данных бд, ибо и быстрей и лучше, удобней, все-таки специально для этого сделанная вещь. |
| Автор: z-END 15.6.2006, 10:43 |
| wil, незнаю. я когда перешел с файлов на БД вздохнул с огромным облегчением.. быстрее, проще, удобней за двумя руками за БД |
| Автор: skyboy 15.6.2006, 11:00 |
wil, ты видел когда-нибудь текстовый файл с разрушенным индексом, который не открывался?  Не надо категоричнсоти, просто помнить, что Цезарю - цезарево. |
| Автор: wil 15.6.2006, 11:03 |
| это я к тому, что часто видел на форумах такие вопросы - что выбрать: бд или файлы. и народ сначала думат, решает, выбирает, сравнивает, а потом вроде как делает выбор в сторону бд. а что тут думать, ответ - БД ты видел когда-нибудь текстовый файл с разрушенным индексом, который не открывался? repair и все дела ) |
| Автор: Drache 17.6.2006, 01:50 |
| Если говорить о надежности (а именно об этом спрашивалось вначале), то не понимаю как можно считать БД надежнее. Не так запишется, не то запишется, еще что-то.... Это во-первых. Во-вторых БД лучше там, где выбирать записи приходится чаще. А в данной ситуации, по-моему, чаще производится запись как раз таки. К этому добавим еще и индексы (кто-то о них кажется вспоминал) - при большой БД с индексами запись будет тормозить. Так что не нужно такой категоричности. Потом - какая БД хоть? Мускуль как я понимаю тоже на файлах работает и записывать оно тоже будет в файлы. О каких трудностях записи в файл идет речь?? В общем, поставить нужно конкретнее задачу. Как часто эта статистика будет обрабатываться? Если это что-то типа счетчика, как на большинстве сайтов, то тогда лучше в БД (там и запись и чтение происходит примерно одинаковое количество раз). Если же статистика посерьезнее и обрабатываться она будет не очень часто, то лучше уж все это записывать в файл, а потом выбирать и анализировать. Можно даже попробовать проанализированную инфу уже записывать в БД, а потом повторно выдавать ее же (правда будет не точно). Вот мое мнение ... |
| Автор: Alone 20.6.2006, 14:31 | ||
| Хранение в "plain text files" - это "третий клас, вторая четверть"... Не в каменном век живем , уважаемые. Drache,
Гм... вообще то любая БД пишет в файлы. И что теперь? оракл и постгрес на свалку отправить? А вообще я даже и пояснять ничего не буду, почему БД лучше в этом плане... (да и в другом тоже.) Раз человек "за файлы" значить он просто еще не дорос до соответствующего уровня. Время - хороший логгер. Посмотрим что он скажет через полгодагод.... Когда "подрастет" PS: и ничего личного... |
| Автор: SpecAgent 21.6.2006, 02:00 | ||
Поправляю Далеко не всегда, допустим довольно крупные и не безызвестные новостные сайты хранят именно в файлах и на это есть ряд причин! Ну а в целом и данной ситации в частности конечно бд рулит имхо. |
| Автор: AztEK 21.6.2006, 09:13 | ||
Каких? |
| Автор: BobiKK 21.6.2006, 09:32 | ||
Скорость. Невозможность SQL-инъекций. Плюс, можно так же самому разработать алгоритм поиска, какой-нибудь сверхумный метод деления пополам. |
| Автор: AztEK 21.6.2006, 09:51 | ||||||
Ну конечно... Файлы быстрее БД??
Бред. Оно того не стоит, достаточно нормально обрабатывать данные.
Можно. Только геморроя... И скорость... |
| Автор: wil 21.6.2006, 10:08 | ||||
имхо бд будет медленней только при хранении очень больших кусков информации (записи мегов по 5). не знаю что так можно хранить.
тогда уж сразу на голый html переходить |
| Автор: z-END 21.6.2006, 11:33 | ||
при ведении логов?! пример в студию=) |
| Автор: BobiKK 21.6.2006, 15:03 | ||
В общем-то, да. Гугл-то на файлах построен. Но сам не проверял. Потому что от мускула отказаться не могу |
| Автор: AztEK 21.6.2006, 18:39 |
| Оо-хх... Гугл постоен на файлах?? Откуда такая информация? Ты думаешь, амый большой в мире индекс страниц Интернета будут хранить на файлах?? При том, поиск по которым занимает микросекунды (пусть даже и с помощью мейнфрейма)... Короче за самоуверенные и непрофессиональные утверждения очень чешутся руки поставить минус. |
| Автор: Alone 27.6.2006, 11:40 |
| AztEK, а BobiKK то прав. Да действительно, у гугля не так как у людей, но на то есть свои причины... далее оффтоп: По словам Хольцля, компьютерная инфраструктура Google построена на тысячах "обычных", относительно дешевых, серверов. Общая стоимость оборудования составляет несколько миллионов долларов. Это оказалось выгоднее, чем приобретение меньшего количество дорогих многопроцессорных машин, которые в общей сложности обошлись бы в десятки миллионов. Во-первых, это собственная файловая система Google File System, которая оптимизирована для работы с большими блоками данных по 64 МБ, а также обладает повышенной защитой от сбоев. Вся информация копируется и хранится в трех местах одновременно, при этом система способна очень быстро находить реплицированные копии, если какая-то машина вышла из строя. Задачи автоматического восстановления после сбоя решаются с помощью программ, созданных по модели MapReduce. Серверы работают под управлением Linux. За основу был взят стандартный дистрибутив Red Hat, в котором ядро операционной системы было модифицировано с учетом нужд Google. От себя добавлю, что все это связано воедино и представляет собой нечто похожее на NetOs Plan9. Tristan Louis отталкиваясь от суммы затрат Google на оборудование (250 миллионов долларов) подсчитал, что поисковик обслуживает кластер в котором находится от 45000 от 80000 серверов. Производительность такого кластера оценивается от 126 до 316 терафлопов. Но это не меняет моей точки зрения по поводу использования БД, которую в данном контексте можно назвать скорее надстройкой над файловой системой вкупе с функциональным шеллом. |
| Автор: AztEK 27.6.2006, 12:06 | ||
Оу... Тогда извинясь...
Именно ! |
| Автор: xolod 29.6.2006, 03:21 |
| Alone, собственная файловая система — есть отдельные файлы индекса и отдельные файлы данных (в действительности там 5 типов данных, 3 — индексных и 2 для данных, но не суть). Алгоритмы чтения-записи оптимизированны по моим сугубо личным ощущениям для работы с действительно большим количеством информации и хранения копий файлов в оперативной памяти (memory maping). Отказались от БД видимо из-за невозможности построения на ней в большинстве случаев (кроме Radware и ему подобных) полноценной кластерной системы. Все это не абы с потолка, а в виду наличия сервера GB-5005 (http://www.google.com/enterprise/gsa/product_models.html) с полным SDK и частичным исходным кодом индексирующего механизма. Не люблю огорчать, но BobiKK все-таки не прав. Точнее не совсем прав. Ну а по теме, создание собственной ФС для ведения логов не оправдано ни на грош. В каких бы масштабах эти логи не велись. БД (MySQL или MSSQL) хватит с головой, о чем собственно я уже говорил в первом ответе. |
| Автор: Drache 29.6.2006, 13:08 |
| Кстати, по-моему здесь неправильно звучит название темы. Логи - это, в моем понимании, просто отслеживание и записывание ситуации на случай если что-то пойдет не так и нужно будет узнать что же случилось. А то, о чем мы все здесь говорим, по-моему, называется статистика. Так вот для логов, думаю, удобнее юзать файлы, а для статистики, конечно же, БД. Или я в чем-то неправа? |
| Автор: skyboy 29.6.2006, 13:12 |
| Drache, лог - это протокол. Протокол чего угодно: сбойной ситуации, поведения юзера на сайте, работы парламента, в конце концов... а статистика - это уже процесс анализа этих самых протоколов для извлечения "полезных" или нужных сведений. |
| Автор: Drache 30.6.2006, 00:11 |
| значит я была неправа изначально, вследствие моего неправильного понимания этого слова |
| Автор: WMBE 18.7.2006, 11:50 |
| Исходя из всего выше сказанного, появились определенные выводы: 1) для сбора и храниения информации (так называемых логов сервера/сайта) наиболее рациональнее, с точки зрения скорости и удобства выборки, подходит База Данных. 2) для обработки логов (сбора статистики и наглядного представления получившихся данных) удобнее использовать отдельную программу/скрипт (у кого что)... подразумевается нечастое обращение (1-2 раза в неделю/месяц). |
