Сайт на БД VS на файлах

lift

Читатель
Заблокирован
Регистрация
1 Июл 2007
Сообщения
2.222
Реакции
1.487
Сижу я некоторое время уже в раздумьях. Есть проект сайта одного. И несколько вариантов двигла для него. 2 основных конкурента это сайт на базе (MySQL) и на файлах (txt).
Вот и выбираю. Может кто умных мыслей накидает по теме.
В чем суть выбора вообще:
Сайты планируются достаточно большими, многабукв будет. В исполнении юзеров. Это с одной стороны. С другой стороны сайт сильно нишевой, с монетизацией косяки будут. Тоесть не смотря на то, что они большими будут, бабла кучу не принесут. Оборотная сторона СДЛ, блин :)
По количеству контента планируется так: до более-менее внятной монетизации (чтоб я могу взять или мощный вдс или дедик) сайты выростут до 5-10 гигов размером уже. Соответсвтенно или базой или файлами. И до этого времени их надо где то хостить. Если с файлами проблем нет по большому счету, есть достаточно много хостингов, которые это протянут при вполне адекватном ценнике, то вот с БД напряг, куда впихнуть базу такого размера на хост я вообще не представляю (если представляете - делитесь контактами. хоть под 1200 постовым хайдом если не хотите совсем палить :))
Собсвтенно это основные сложности выбора.
Дополнительные в том, что оба движка как бы хороши не были, но всетаки на БД там больеш рющечек и феничек для юзеров. В итоге они будут это юзать и будут более довольны. Выглядит он в принцепе более солидно, больше вараинтов интеграции его с теми же форумаи например (на файлах интеграцию сделать будет очень большой проблемой). Ввиду того, что оба двига практически без русскоязычного комьюнити, в англоязычном тоже не шибко много, напильником работать много и там и там, но в двиге с БД ощутимо больше.
В общем слушаю мнения. Только желательно без "БД - гавно" или "файлы - гавно". Я и с тем и с тем работал, похожий проект с БД был и я представляю себе очень четко, как это все будет в итоге выглядеть и движки уже выбирал с этим учетом. Движки оба очень не плохо оптимизированны по нагрузкам, безопасности и куче чего еще, за это их и выбрал :)
 
Такой объём будет и для файлов и для БД проблематичен.
Файлы однозначно придётся дробить, потому что даже на рабочем столе, открывая папку со 100k файлов система подвисает, а по ftp вообще висанёт. И что делать, если нужно отредактировать какую-нибудь инфу и как найти нужный файл?

Вообще 5 - 10 Гб очень не реальный объём. Видел магазины с 1мил. товаров и базой не более 200 Мб.
Нужно попробовать залить в базу хотябы 500 Мб и сделать оптимизацию базы, уверен, что конечный объём будет отличаться.

Единственное преимущество файлов - это то, что они работают как кеш, т.е. сайты на них достаточно шустрые.
Но если cms изначально грамотно написана и страница собирается не более чем 5-7 запросов + есть кэширование блоков, то такая cms может даже обойти систему на файлах.
Супер мощный сервер не нужен, нужно потратиться на оптимизатора, который оптимизирует мускл и связку апач + nginx
 
bork75 я же написал
похожий проект с БД был
И тут видели юзеры некоторые (а некоторые даже помогали с работой) с этим проектом. 5-10 гигов это далеко не потолок, это точка проверки правильности бизнес-плана по сайту. Ибо если к этому моменту не будут выполнены определенные и не из головы взятые условия по монетизации и уровню посещаемости проекта то дальнейшее его развитие станет меценатством и очень маловероятно что мне будет нужно :)
Про папки со 100к файлами отдельно: двиги на самом деле оптимизированны, и о такой детали как разбор по многим папкам с приемлимым количеством файлов я уже позаботился выбирая двиг :) Будет там вполне адекватное и легкое для фтп-клиента дерево каталогов внутри.
Про магазин из примера. Во первых не магазин. Во вторых не будутыкать пальцем в М-Видео например, у которого база гигами и десятками гигов мериется в виду особенности использования и структуры. И это не единственный пример если уж магазины брать конкретно :) В общем я хочу сказать, что под сомнение размер базы/файлового набора даже ставить не стоит. Штучка будет на самом деле не маленькой даже на старте и с чисто моим косяком наполнения (без юзеров, пришедших на сайт)
С оптимизацией серверов/вдс вопрос тоже встанет уже после переезда на них непосредственно, а это случится не разу, сразу будет простой хостинг.
Вопрос сейчас только в выборе типа зранения инфы на сайте. С комментариями мнений )))
 
На сервере есть понятие иноды, вот они не очень хорошая вещь) Они любят заканчиваться) У самого был проект на файлах, по месту все идеально, по инодам пролетал. В штатах щас наплевать на место, они по кол-ву файлов гробят.

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

Если мудрый админ и руки на месте то апачи+ нгникс+скул хорошо настроенный и проблем нету. Если грамотный админ то лайттпд, если найдешь отличного то поставит чероки, и все будет летать. Да и wvc со скулом имеет преимущества, так как если найдут дырку и положат шелл, то восстановить такое кол-во текстовых файлов будет очень проблематично.

Так вот резюмируя, иноды + безопасность. Лучше перейти на скул + лайттпд.
 
если CMS выбрана, то по сути один х. с файловой, правда, отваливается труд по оптимизации и быстродействие не особо критично.
можно БД вариант допилить так, чтобы текстовые данные писались в файлы с формированием независимых файловых архивов (чтобы архивы были доступны с удалённых адресов)
короче кластерную систему.
 
lift
могу сказать со 100% уверенностью (лично моё мнение) что если на сайте более 500 страниц то делать его надо на MySQL тк такой сайт будет геморно содержать, обслуживать и переносить если он будет на файлах (переносить будет мегагеморно). Занимаемый объём сайта на файлах всегда значительно больше чем на MySQL отсюда идёт нагрузка на файловую систему сервака, и разница в нагрузке стирается а бывает что и выше чем при использовании MySQL

По мне так без MySQL это только если сайт 3-100 страниц, не более.

В твоём случае если посещалка большая планируется то дедик + оптимизация кеширования MySQL - спецом по этому делу. Если не больше 3-5к в сутки то vps

Может стоит попробовать запуститить sql двиг на MariaDB ??
 
По моему все один момент забыли: стартовать это на хостинге будет. На простом хостинге. Я не альтруист в воздух не проверив бабки выкидывать на дедик. Малоли что не пойдет. А пойдет, то и mariadb + apache + nginx на дедике/вдс настроить прямота рук вполне позволяет :) Был бы стразу такой хост, вопроса изначального бы небыло, 99.99% что сразу на БД погнал бы.
А сейчася упрусть сразу в то, что нет хостингов, куда повесить сайт с скольк нибудь большой базой можно. По этому вариант на файлах и появляется.
 
По моему все один момент забыли: стартовать это на хостинге будет. На простом хостинге. Я не альтруист в воздух не проверив бабки выкидывать на дедик. Малоли что не пойдет. А пойдет, то и mariadb + apache + nginx на дедике/вдс настроить прямота рук вполне позволяет :) Был бы стразу такой хост, вопроса изначального бы небыло, 99.99% что сразу на БД погнал бы.
А сейчася упрусть сразу в то, что нет хостингов, куда повесить сайт с скольк нибудь большой базой можно. По этому вариант на файлах и появляется.



Я у него сильные проекты держу и база есть одна под 1.3 гига все работает ниче не падает)
 
  • Нравится
Реакции: lift
А вот это оооочень по теме. Респект.
Локальный сервер где все делаю сейчас без особых наворотов жрет не больше их конфигов и на нем все работает как надо.
Не спалиш тариф, на котором у тебя это крутится и посещалку?
 
А вот это оооочень по теме. Респект.
Локальный сервер где все делаю сейчас без особых наворотов жрет не больше их конфигов и на нем все работает как надо.
Не спалиш тариф, на котором у тебя это крутится и посещалку?
 
  • Нравится
Реакции: lift
Назад
Сверху