nkmr

Много слов, а задача тривиальная. Файлы на сервере хранят как дома. Представь тебе надо хранить фото. Распихал по папкам с названиями и тип-топ. Мало места - надо докупить или удалить лишнее. Надо бэкап значит надо. Это все элементарная логика и больше ничего. Все остальное как ее написать кодом.

Чтобы забыть о проблеме на долго конечно лучший выбор отдельное объектное хранилище. Не обязательно это должно быть облачное решение, можно организовать self-hosted S3-совместимое решение с использованием https://min.io/. Это позволит использовать любую готовую библиотеку s3-клиента для работы с файлами (upload/download/delete)

Плюсы - при правильной настройке размер хранилища можно бесконечно расширять и масштабировать/реплицировать.

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

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

Веб приложения максимально оптимизированы при работе с файлами на диске.
Никакой другой метод не позволит дать такую производительность.

Поэтому - авторизацию доступа делай на уровне веб сервера (вот пример с нормальным oauth)

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

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

Тупой пример - числовой идентификатор переводи в hex, дели на группы по 4 символа и создавай соответствующие каталоги: /images/0d4f/3b00/a841/0d88, тут 0d88 это файл, остальные части - каталоги. Идентификатор соответственно 64-битное число 0x0d4f3b00a8410d88

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

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

Как именно прокрастинируете-то?

Обычно помогает:

1) включить двухфакторную авторизацию во всех соцсетях - чтобы логиниться было настоящей болью и выработалась привычка туда зря не залезать
2) сон - его должно хватать
3) утром сходить выпить кофе в кофейню на улице, где по пути можно обдумать дела.
4) отвыкнуть от модели "мне нужно сегодня работать" и привыкнуть к "что конкретно сегодня надо успеть сделать (min/max)"

Если не поможет, то ничего не делайте, отдайтесь прокрастинации. Всё самоотрегулируется и вы окажетесь там где и должны оказаться. Рас вас работа ваша не радует, пусть вас уволят. Найдется то, что радует, ну или продолжите прокрастинировать на помойке. Это тоже в общем-то вариант. Почему нет? Должен же и на этом посту кто-то быть :)