Делать двиг на бд или файлах?

Нет тут никаких споров. Только факты (все это реализовано на Twilight CMS, работает несколько лет под приличной нагрузкой, пройдено множество граблей):

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

- конкурентная НАДЕЖНАЯ запись в БД на файлах реализуется не очень просто, но реализуется. В настоящий момент мы пишем команды в очередь (append в файл является быстрой бинарной операцией), а затем файл с данными кем-то одним лочится и модифицируется.

- скоростные характеристики файловых CMS vs СУБД имеет смысл сравнивать только при конкретном типе сайта. Если сайт генерируется из плоских таблиц (нет или почти нет сложного подчинения данных aka вложенные селекты) и используются индексы - файловая система не будет уступать СУБД, а при определенных условиях и превосходить по скорости работы. Если написать свой веб-сервер (или модуль к Апачу) который базу будет в памяти держать, иметь возможность мапировать файлы в память или еще что-то подобное - так и вообще СУБД за пояс затыкается. Но все это до тех пор, пока данные не начинают активно модифицироваться. Если постоянно модифицировать таблицы (например какой-то счетчик посещений конкретных страниц, скачивания файлов и т.п. обновляется), то придется постоянно перестраивать индексы, что при больших объемах данных уже станет определенной проблемой. Хотя если апдейты базы делать хитро, индексы перестраивать не всегда, а только когда нужно - основным тормозом будут только апдейты записей и их удаления. Хотя судя по задаче ТС это не его случай.

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

- если сайты объемные и на сайтах постоянно толпятся боты (как у нас) проблемы статического кэширования и взаимодействия с САПЕ являются ключевыми.

Вывод: на файлах все пишется. Вопрос в затратах и геморе. На разработку устойчивой базы данных на файлах с примерно вашими запросами у нас ушло около 5 лет, подводных камней миллион, сложных технически решений - масса. Ну, понятное дело у вас в остальном требования попроще к CMS будут, но я бы не стал рисковать бюджетом и изобретать велосипед. Полно готовых систем. Нужно просто выбрать подходящую.

Мой совет - заказать cms на БД. На сегодняшний день большинство крупных проектов используют базы данных. Правильный код+оптимизированные запросы к БД - залог успеха.

Лучше статики может быть только статика в памяти ;-)

Это где такое? :) Если юзать InnoDB в MySQL, то никаких задержек там не будет :p Есессно всё зависит от предполагаемых нагрузок.

Тут согласен, спор ни к чему :)

Neval добавил 26.10.2009 в 10:17

Золотые слова :D

Зачем? Есть же хорошие решения. Так будет существенно быстрее, дешёвле и предсказуемее при разработке, работе и поддержке.

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

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

Слава, ты вообще читал что я написал? О какой выгрузке в HTML идет речь, если человек делает сайт под SAPE (с большой вероятностью)?

классная тема. посмотрим кто выиграет. кстати 5 лет то вы по вечерам по 15 минут чтоли писали? долговато ...

1500 дней ориентировочно ... вы бд сервер сделали или учились языку програмимрования? :D

Максимализм в оценках - не дело профессионала. Причём Вы не правы во всех своих ехидствах в этом посте. А именно:

1. Диск имеет весьма мизерный кеш по стравнению с любой промышленной или полупромышленной СУБД. MySQL и любую промышленную СУБД можно настроить так, что все данные будут лежать в кеше.

2. Да, ряд надёжных СУБД а-ля memcachedb хранит все данные в оперативной памяти и никогда не обращается к диску.

3. Да, ряд СУБД может отдавать боту около 10 тыс. страниц в секунду, в то время как голый диск с кешами может отдавать боту до 200 страниц в секунду (техническое ограничение на перепозиционирование головок).

4. Да, в MySQL и любой промышленной дисковой СУБД разработчик, понимая типичное поведение ботов на основе структуры сайта, может так расположить данные на диске, что они будут отдаваться даже с диска за счёт одного позиционирования головок и одного считывания. Да, в файловой системе такое невозможно - разработчик практически никак не управляет расположением файлов на диске.

5. Да, администратор может настроить в nginx кеширование страниц, отдаваемых с диска. С тем же успехом он может настроить с помощью nginx и кеширование для страниц, отдаваемых из СУБД.

bearman, БД сервер сделали. Не очень понятно что вас удивляет, вы что, никогда не участвовали в крупных проектах? Время затраченное на разработку коробочного продукта складывается отнюдь не только из кодирования. Впрочем, "профессиональный программист" должен это понимать. А людей, которые недооценивали задачи я в жизни встречал пачками. К сожалению, учиться у них нечему.

stealthy добавил 26.10.2009 в 15:30

Слава Шевцов, а это было не ехидство. Я тонко намекнул, что при сравнении абстрактных крайних случаев результат будет не сильно полезен. Я согласен с тем что ты тут написал, но при условии "абстрактного сравнения" СУБД и файловой системы. Если говорить о конкретных применениях в контексте оговоренной ТС задачи, то п.5 все сказанное тобой превращает в не очень полезную информацию. А по мелочам можно спорить до хрипоты, не вижу смысла. Я видел достаточно баз, которые в память не помещались, а также проводил нагрузочное тестирование в реальных боевых условиях, которое показывало что для подавляющего большинства веб-сайтов наличие СУБД никак на скорости работы не сказывается, поскольку можно реализовать то же самое быстродействие и на файлах, а все что сверху слить на nginx или squid. Да и про перепозиционирование головок я не стал бы так заявлять, будто в операционках никаких кэшей нет между винтом и его встроенными аппаратными кэшами и приложением пользователя. Не вижу смысла туда копать сейчас, не в том суть.

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

stealthy, понятно. на пхп писали файловую бд?