это я к тому, что часто видел на форумах такие вопросы - что выбрать: бд или файлы. и народ сначала думат, решает, выбирает, сравнивает, а потом вроде как делает выбор в сторону бд. а что тут думать, ответ - БД   
ты видел когда-нибудь текстовый файл с разрушенным индексом, который не открывался?  
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) хватит с головой, о чем собственно я уже говорил в первом ответе.

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

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

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