Построение файловой системы веб-сайта.

Насчёт "проще" всего этого я бы поспорил. Если хранить и манипулировать ещё зависит от конкретных задач, то последнее...То ли дело забекапить файлы, то ли базу в несколько гиг. И, соответственно, развернуть.

Ayavryk, а есть реальный опыт использования такого? Может не у самого.. у знакомых "фанов" (с)?

- Проще хранить = ? гигантская таблица о_О чем проще-то?

- манипулировать большими объемами.. можно на уровне fs "манипулировать"

- бэкапить - тот же инкрементальный архив.. или rsync.. аккуратно всё положит вместо дампа на гигабайты

- обеспечить безопасность/приватность nginx + x-accel-redirect - имхо, вполне приемлемая безопасность в сочетании со скоростью отдачи. Если речь о безопасности на уровне сервера - с правами "поиграться"...

И что проще? Любая БД на гиг забэкапиться быстрее чем большое количество мелких файлов на тот же самый гиг. И точно так же быстрее развернется.

Сам не реализовывал (я вообще не программист), но в двух конторах которых работал это практиковалось. Назвать этих программистов лохами не смогу. Реально большие высоконагруженные проекты (400.000 хитов)

UPD ПО поводу инкрементального архива. В обоих случаях были MS-разработчики. А там насколько я знаю можно делать бэкап частичный. Всю БД гнать в бэкап не надо.

Стесняюсь спросить - ты это сам на шаред хостинге проводил? Ну или где-нить без доступа к консоли? С пом. внешних инструментов - ПМА там, или др. дамперов.

В БД изображения хранить удобно лишь в случае, когда имеется кластер из нескольких web-серверов. Для этого хорошо подходит http://docs.mongodb.org/manual/core/gridfs/

не-не.. речь не о "лох-нелох".

Я бы на статистику/бенчмарки (если с пояснениями - вообще круть) посмотрел... ну т.е. если БД "делает" FS (по производительности и/или безопасности и/или удобству использования), то за счёт чего...

права на файлы настраиваются, отдача "после проверки" - легко;

под кэш ФС можно место выделить;

по поводу удобства - не хватает знаний+фантазии представить...;

Вы еще напишите без доступа к SSH.

1. Я не пропагандирую этот метод, и сам делать не буду - в собственных проектах таких проблем никогда не возникало. нет таких задач. Но отмечаю что он существует и Яндекс знает 2 миллиона страниц в которых эта тема обсуждается.

2. Речь насколько я понимаю идет о чем-то очень большом. Иначе не было бы смысла заморачиваться этим вопросом.

когда имеется кластер из нескольких web-серверов, можно и в распределённой FS хранить... понимаю, что web-сервер употреблён в значении "железяка", но тем не менее

1. Я вообще-то так и написал:

;)

2. Было сказано о "проще".

А если обращаться к Яндексу, то я уверен - там гораздо больше страниц, с вопросом аля "не могу залить базу больше 20метров". Кстати, к вопросу о "проще".

Я могу лишь представить, что кодеру проще залить пикчу в базу (создав все необходимые индексы), нежели заморачиваться с правами разных хостингов. Ну типа для универсальности. Ну отчасти для безопасности (включая хотлинкинг).

//Т.е. типа для того, что бы не заморачиваться с настройками сервера.//

Для чего ещё так извращаться - тоже как-то слабо представляю.

Самая длинная дискуссия на эту тему здесь. Те кто ратует за такой способ (они в меньшинстве), как правило работают или с Oracle или c MS SQL. И там и там всегда был механизм, оптимизирующий хранение BLOB. В отличие от MySQL, в котором он в оригинале не присутствует.

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

Мне как раз сложно представить проект в котоором приходится заморачиваться хранением большого числа картинок и при этом он размещается на пятикопеечном шареде.