Как хранить очень большое количество файлов? Как сохранять пути в БД?

Question

[Михаил Иванов]

У меня в проекте будет очень много картинок (аватары пользователей, постеры для фильмов, обложки для альбомов и т.д.).
Вопрос: как лучше сохранять картинки на сервере и как сохранять пути в БД?
Насколько мне известно, в одной папке можно хранить ограниченное количество файлов, иначе могут быть проблемы (вплоть до полной потери данных). Поэтому нужно создавать какое-то дерево папок и по ним разбрасывать файлы.
На данный момент я не придумал ничего лучше, как генерировать при загрузке файла GUID и, например, для 6F9619FF-8B86-D011-B42D-00CF4FC964FF хранить фото в папке 6F/6F96/6F9619FF-8B86-D011-B42D-00CF4FC964FF.jpg. В БД я планирую хранить только GUID, а загружаемый формат для картинок ограничу одним JPG. Сильно ли костыльно?
Какие еще варианты можно придумать?

Comments

[Сергей delphinpro]

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

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

[sim3x]

Сергей:
разбивать нужно, если нужно ходить по директории через ssh/ls/etc

Answer 1

[sim3x]

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

нет

Как хранить в СУБД - как угодно, можно хранить путь относительно какой-то директории

Comments

[Михаил Иванов]

Да

[sim3x]

apiquestion:
да, только если требуется просмотр через фтп / ссш

this makes listing the files in the directory (through FTP or SSH client) take a few seconds

Сама ФС может держать очень большое количество файлов

Maximum number of files: 232 - 1 (4,294,967,295)

без всяких проблем

there doesn't seem to be any impact on how quickly an image file is served to the user.

Answer 2

[Петр]

Вот и зачем GUID?
Достаточно автоинкрементного int + соль (чтобы не скачивали по id).
А хранить можно в сторадже (Google cloud storage, S3, и т.п.), место занимать на вашем сервере не будут, да и бекапы там делают. А у вас только кеширование в пределах 1-10Gb (зависит от задачи)

Answer 3

[Andrey Shatokhin]

Конечно с поддиректориями. Метод генерации пути - любой.
Но я бы посоветовал сделать именами папок дату. Типа 2017/7/1/hash.jpg - и весь этот путь хранить в БД.
Когда у вас что-то сломается или просто захотите понять что вы там храните - вам это очень поможет. Ну и бекапить инкрементально очень удобно.

Answer 4

[Everything_is_not_so_bad]

Ну если нужно прям очень большое количество файлов хранить, то вот есть список DFS.

Answer 5

[d-stream]

На данный момент я не придумал ничего лучше, как генерировать при загрузке файла GUID и, например, для 6F9619FF-8B86-D011-B42D-00CF4FC964FF хранить фото в папке 6F/6F96/6F9619FF-8B86-D011-B42D-00CF4FC964FF.jpg. В БД я планирую хранить только GUID, а загружаемый формат для картинок ограничу одним JPG. Сильно ли костыльно?

Собственно подход не нов. Та же WSUS хранит контент именно так, правда ей хватает всего одного уровня вложенности.

Answer 6

[Dimonchik]

так и делают, разве что только
6F/96/6F9

иногда можно в одну папку скинуть симлинки на реальные , разложенные по директориям

Answer 7

[Saboteur]

"очень много картинок" - это сколько?
десятки тысяч - легко живут в одной папке.

Если обращаться к файлам по прямому пути, задержки в чтении не будет. Задержка в записи - минимальная.
Если файлов больше 100к, то в принципе да, можно идти так, как вы указали - создавать подпапки, но желательно алгоритм генерации файлов подправить таким образом, чтобы самих папок было не слишком много, ибо если у вас будет 100к папок по 1-3 файла в каждой - это неэффективно и неэкономно.
В линукс каждая папка - минимум 3 directory entry.

Answer 8

[АртемЪ]

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

У каждой файловой системы есть ограничения.
Например максимальный объем файла, или длина пути к файлу. Если вы их не превышаете - все нормально.
Если вы сгрузите все файлы в одну папку - ну вероятно вам будет просто неудобно с ними работать и их сортировать. Возможно некоторые файловые системы будут работать медленнее при большом количестве файлов в папке. Я с таким не сталкивался.
Сколько миллионов файлов у вас будет в одной папке?

На данный момент я не придумал ничего лучше, как генерировать при загрузке файла GUID и, например, для 6F9619FF-8B86-D011-B42D-00CF4FC964FF хранить фото в папке 6F/6F96/6F9619FF-8B86-D011-B42D-00CF4FC964FF.jpg

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