Какую нагрузку держит текстовая база ?

[XeonN]

Есть сайт "Доска обьявлений" довольно распостраненная, работает на текстовых файлах...
Мне интересно какую нагрузку она может выдержать если уже база в несжатом виде весит ~34 Метра. На сайте 1.5-4к хостов в сутки.
Меня просто интересует вопрос с какой скоростью меня выпрет хостер (ХостПро) и реально ли перевести эту доску на MySQL.

 

[General Fizz]

ИМХО, оптимальнее всего с текстовых файлов перевести на плоские файлы flatfile или на db3/db4.

 

[medvoodoo]

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

 

[gob1in]

Хех, нагрузку на чтение? вполне, но нужно учитывать что скорость получения данных намного ниже чем в случае с мускулем, поиск чеголибо это вобще отдельный вопрос... Я думаю что текстовую базу хорошо использовать когда данные обновляются крайне редко, и при чтении получается больше 50% содержимого файла. Убедите меня в обратном.

Добавлено через 45 минут
Кста в спомнил по теме... древный скрипт CJ (движок для хитрого порносайта) на текстовой базе выдерживал нагрузку - 4-5к уников в сутки... но это был его максимум. Но стоит учитывать что он писал в базу логи от того и такие маленькие показатели.

 

[General Fizz]

ИМХО, текстовые файлы хорошо держат нагрузку если их в одном каталоге не слишком много. При очень большом их количестве система начинает неоправданно тормозить при поиске в каталоге, причем эти тормоза определить достаточно сложно, поскольку они могут быть нелинейными во времени. Кроме этого, в текстовом файле процесс поиска занимает достаточно длительное время, поскольку доступ к данным в файле - последовательный и надо считать весь файл, чтобы что-то найти, тогда как поиск в базе типа db4 -двоичный, а сама база организована в виде хэш-таблицы со всеми ее плюсами.

 

[gob1in]

Если хостер не дает mysql то лучше всего сначала поискать sqlite может он включил этот модуль... если нет то искать другого хостера или ждать когда база даст дуба при одновременной записи в файл...

Добавлено через 7 минут

реально ли перевести эту доску на MySQL.

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

 

[Jenni]

Работа с файлами будет ВСЕГДА быстрее чем с БД.

Кста в спомнил по теме... древный скрипт CJ (движок для хитрого порносайта) на текстовой базе выдерживал нагрузку - 4-5к уников в сутки... но это был его максимум. Но стоит учитывать что он писал в базу логи от того и такие маленькие показатели.

Не знаю что за скрипт такой Даже обычная ультра спокойна выдерживала 3-4к в час, а скрипты на Си держали несколько сотен тысяч посетителей в сутки и работали на файлах.

 

[gob1in]

кнопки хитро стоят...) немножко промахнулся...
ультра у мну сдохла на пяти...
на сях, редирект скрипт сдох на 50ти тысячах из-за проблем с блокировкой файла при записи.

 

[Jenni]

на сях, редирект скрипт сдох на 50ти тысячах из-за проблем с блокировкой файла при записи.

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

P.S.: Гугл юзает не БД, а файлы

 

[XeonN]

Сегодня доделал то чего не сделал разработчик, кеширование файлов теперь работает быстрее...

Пока занималься изучением кода понял что без глобальной переделки скрипта ничего не получится обработка БД не вынесена в отдельный клас
После недольших доработок теперь файлов больше и она меньшего размера было всего 4 файла теперь каждая рубрика имеет свой файл.(Только скорость поиска упала но это неизбежно) Встроеную систему логирования немного переделал теперь все логи архивируются каждые 24 часа и уходят на емыло )

З.Ы. Всем спасибо за ответы.