Имхо, если в бд пихается такой жсон, значит с архитектурой явно что то не то.

Но я вот что не понимаю, если ты обращаешься за файлом в БД, получаешь путь к нему, потом сервер идёт и находит этот файл и отправляет клинту, то это не такое же простое забивание канала, как и обращение сразу к БД за файлом/бинарником ?

Нет.

Не такое же

А что?

Если тебе нужно хранить данные такого объема и много то используй самую простую древовидную структуру из md5 хеша имени файла

А в БД можешь хранить только хеш

Ок, я просто не знаю как гуглиться это, могли помочь с нахождением ресурсов про это?

первые 6 символов хеша первый уровень
следующие 7-12 символов - второй уровень вложенности

и на второй уровень вложенности уже сохранять. Но нивкоем не сохранять все в одну папку

Например
название файла elixir.json
хеш имени 81e305e27948cca943d8aceb8e3fce06
итоговый путь /content/81e305/e27948/81e305e27948cca943d8aceb8e3fce06

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

Ok. thank you very much

Во-первых, всё работает не в таком порядке: ты отдаёшь на клиент ссылку на файл, а клиент сам его у тебя потом запрашивает.
Во-вторых, клиент может закэшировать результат этого запроса тем самым сильно уменьшив нагрузку на сеть
В-третьих, реляционная база данных - это не просто место, куда кладётся вся информация приложения. Это программа, которая организует быстрый доступ к данным, оптимизирует хранилище, осуществляет поиск, кэширует запросы и так далее. Для того чтобы кэширование, поиск и оптимизации работали хорошо, нужно соответствовать требованиям базы по формату хранящихся в ней данных. Формат в данный момент таков - конечное количество столбцов фиксированной или ограниченной размерности, количество столбцов не часто изменяется. Доступ к данным по индексам. Чтение/запись = 80/20

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

Ещё агрумент - общая нагрузка на сеть. Просто посчитай количество сетевых соединений которые нужны для всего этого:
Вариант с базой
клиент <=> прокси (nginx) <=> приложение <=> база
Вариант со статикой на вебсервере
клиент <=> прокси (nginx)

А передача файла по TCP полностью забивает соединение в одну сторону

И при этом, файл будет храниться в оперативной памяти приложения

Если одна картинка 2мб в среднем, то 100 картинок (а это не очень большой рпс) в секунду будут занимать 200мб оперативки. Для дешевого сервера с 8гб оперативки это будет уже 2.5% от всей оперативной памяти

Я думаю, что теперь я тебя убедил

Не то слово.
Я тут только одно не понял. Ты говоришь, что соединение будет таким
клиент <=> прокси (nginx)
А как прокси понять, где этот файл, нужен же сам путь, который хранится в БД