Стоит ли использовать файловый сервер в проекте?

Question

[Shurik]

Здравствуйте. Делаю небольшой проект на Symfony, в котором среди прочего функционала есть загрузка пользователями файлов, их удаление, скачивание. Появилась дилемма, как хранить файлы. В моем понимании есть два варианта: сохранять их в файловой системе ОС и использовать файловый сервер, например Minio. К своему стыду к второму варианту я ни разу не прибегал.
Что думаю я на этот счет. Первый вариант - это простота реализации, тем более требуемый функционал наипростейший. Второй - это освоение новой технологии и вероятно иметь возможность хранить файлы на удаленной машине. Хотелось бы заменить, что масштабировать проект не планируется.
Хотелось бы узнать мнение бывалых, стоит ли тратить время на освоение новой технологии для себя учитывая требуемый простой функционал? Понимаю в этом ничего плохого нет, но уверен при более сложных задачах я его при необходимости освою в небольшие сроки. Или возможно есть какие-то другие подводные камни в использовании файловых серверов. Если посоветуете использовать при любых обстоятельствах именно их, то какие посоветуете в связке php и symfony?

Comments

[tukreb]

Зачем вам в вашем маленькой проекте хранить файлы удалённо?
И даже в большой проекте, зачем? Вы делаете аналог порнхаба? Ютуба? Вряд ли.

[Shurik]

tukreb, в этом весь и вопрос, стоит ли изучать новую технологию ради маленького проекта. Вашу точку зрения уже разделили несколько отписавшихся ниже. Спасибо за мнение. И да, конечно же это не аналог порнхаба, к моему великому сожалению)))

Answer 1

[rPman]

Чем больше зависимостей, тем сложнее поддержка в будущем.

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

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

Я настоятельно рекомендую не городить лишних сущностей и хранить файлы на том же веб сервере как статические. Если нужны ограничения доступа, то используй штатные инструменты авторизации веб сервера либо свой велосипед. Это 10-15 строк кода, например файлы изначально хранятся в не опубликованном каталоге, а при предоставлении доступа к файлу в публичном создается симлинк, в имени которого id сессии (например id_сессии/id_файла причем если доступ сразу ко всем файлам, то достаточно линка на каталог по id_сессии), а при отзыве доступа, удаляются все симлинки с указанным id сессии.

Бонусом получаешь максимально ресурсоэффективный способ хранения и публикации файлов, минусом наверное только свой uploader писать (в наше время начинающие разработчики просто обязаны пройти через написание своих велосипедов типа upload файла, обслуживание очереди задач по времени и т.п. иначе такое городят, смотреть на этот кошмар невозможно)

Comments

[Shurik]

Свой uploader уже писал, это не проблема. Вопрос, как заметил товарищ ниже, в целесообразности использовании случая для освоения новой технологии.
Не совсем понял идеи с системой доступа по симлаинкам. Не в плане реализации, а в целом мне даже не приходило в голову сделать именно так. Если хранить файлы как статические, я планировал предоставлять доступ к ним через сущности бд. Т.е. один файл - одна запись в табличке. Посредством этого уже реализовывать доступ. Или вы что-то другое имели ввиду? И поясните в двух словах плиз про очередь задач по времени

[rPman]

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

Симлинки позволяют разрабатывать систему прав без привязки к веб серверу, оставляя файлы статикой (веб сервера работают со статикой максимально эффективно).

[Shurik]

rPman, о каких пользователях идет речь? Работая же через веб-приложение пользователь будет для всех один - www-data в случае nginx.

[rPman]

Shurik, сервиса

я не про техническую часть а организационную.

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

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

[Shurik]

rPman, понятно. Спасибо за советы)

Answer 2

[Ипатьев]

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

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

Почему не сначала интерфейс - просто потому что вы изначально не представляете себе все требуемые методы. Это будет видно только из практики.

Таким образом вы и задачу решите оптимальным способом (локально), и опыт получите (причём в первую очередь в программировании), и гибкость добавите - если вдруг надо будет перейти на облако (причём не обязательно именно на это) то это будет проще сделать просто написав ещё один адаптер, но не трогая основной код

Comments

[Shurik]

Вы верно заметили. Дело именно в этом. Т.е. в простом проекте лучше не мудрить и хранить файлы статически, а для освоения пощупать в тестовом режиме файловый сервер? Как сделали бы вы?)

[Ипатьев]

Дополнил ответ

[Shurik]

Ипатьев, спасибо огромное!

Answer 3

[Drno]

а webdav чем плох?
Minio это s3, сегодня масштабироваться не хотят, завтра захотят...

Comments

[Shurik]

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

[VoidVolker]

Shurik, масштабирование - это не про монтирование каталога по сети, а про увеличение числа и типов серверов, а так же сервисов и механизмы синхронизации всего этого добра.

[Shurik]

VoidVolker, имел ввиду несколько веб-серверов, например, и одна примонтированная папка по сети к каждому из них. Согласен такое себе масштабирование) Прочитал про тот же minio, да это +- минус о том, что написали вы, именно в контексте хранения данных

[Dmitry Bay]

Shurik,

Так изучите S3, нет необходимости даже minio поднимать.

[Drno]

Shurik, монтировать надо по какому то протоколу...
для сети считается оптимальными S3 \ webdav \ nfs
монтируйте что хотите)

Minio(s3) подниматься не обязательно, можно за копейки взять на таймвеб \ makecloud 10гб s3 и всё потестить, зато в проекте он будет на будущее

[Shurik]

Drno, ага уже при изучении вопроса увидел серверы s3 на таймвеб. На мой взгляд действительно недорогой выход для того, чтобы не поднимать самому minio, хотя если честно то руки чешутся))