Как организовать хранение фотографий для сайта?

Question

[romaro]

Предполагается хранить файлы на собственном сервере (NodeJS).
Объем — несколько десятков тысяч, т.е простейший вариант сваливать все в одну директорию уже не подходит. Кроме того, для файлов с изображениями нужно хранить тубмы.

Я сейчас вижу примерно такой алгоритм после того, как файл получен от клиента:
1) Вычислить хеш от изображения
2) По хешу определить путь до папки (как описано здесь, второй способ)
3) Сделать нужные тубмы и сохранить все это рядом. Примерно так:

../6a/c1/e68d51251ab2d826ce8d0b92dd08a7e01c3d.jpeg
../6a/c1/e68d51251ab2d826ce8d0b92dd08a7e01c3d_100x100.jpeg
../6a/c1/e68d51251ab2d826ce8d0b92dd08a7e01c3d_200x200.jpeg

Первый вопрос общий: насколько этот способ актуален и есть ли у него достойные альтернативы?

И второй: как реализовать саму файловую структуру?

fs.writeFile('/home/nodejs/project/static/6a/c1/e68d51251ab2d826ce8d0b92dd08a7e01c3d_100x100.jpeg, buffer, err => {
            if (err) console.error(err.message);
        });

Показанный выше код, естественно, выдаст ошибку, т.к. директории ../6a/c1/ еще не существует. Решать банальной проверкой наличия директории? Или, может быть, создавать директории по другому принципу?

Comments

[ThunderCat]

TheAndrey7,

Хеш лучше sha-256 минимум использовать, он длиннее что уменьшает вероятность коллизий.

Ух, круто, пацаны то не в курсе...

Вероятность случайного совпадения всего двух хешей MD5 составляет 1/2^128, что составляет 1 к 340 ундециллионам 282 дециллионам 366 нониллионам 920 октиллионам 938 септиллионам 463 секстиллионам 463 квинтиллионам 374 квадриллионам 607 триллионам 431 миллиардам 768 миллионам 211 тысячам 456.

Однако, если вы сохраните все хеши, то вероятность немного выше из-за парадокса дня рождения . Чтобы иметь 50% шанс совпадения любого хэша с другим хешем, вам нужно всего 2^64 хеша. Это означает, что для получения коллизии в среднем вам потребуется хэшировать 6 миллиардов файлов в секунду в течение 100 лет .

Answer 1

[Дмитрий Свиридов]

Загружайте файлы не в папку, а в s3-совместимое хранилище (чтобы при желании можно было без страданий и изменений в коде перейти на Amazon или в Linode какой-нибудь) - MinIO. Т.е. генерируете некий id, превращаете его в хеш, формируете ключ и по нему льёте в MinIO. Причём храните только оригиналы.

Что касается миниатюр, то их нарезать и хранить не нужно. Представьте, если размеры в дизайне поменялись - что тогда? А если для каждой миниатюры webp-версия потребовалась - все картинки опять обрабатывать? Есть решение - imgproxy. Это специальный прокси-сервис (можно на свой сервер поставить, как и MinIO), который нарезает картинки "на лету" в момент обращения (по параметрам в url). Кроме нарезки, есть ещё куча разных возможностей. Кеша внутреннего нет, т.е. перед imgproxy есть смысл поставить Nginx для кеширования миниатюр (чтобы при каждом обращении не нарезало).

Comments

[shurshur]

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

[Дмитрий Свиридов]

shurshur, и как это противоречит тому, что я написал? Я написал "формируете ключ" - а как именно его формировать - дело десятое.

[romaro]

Дмитрий Свиридов, я правильно понимаю, что MinIO - это такой Ceph для маленьких?

[romaro]

shurshur, а файловая структура настраивается в конфиге самого MinIO или это решается на стороне приложения, а MinIO просто предоставляет S3-совместимое API для загрузки файлов? То есть MinIO это такая черная коробка, которая сама управляет распределением файлов по ФС операционной системы или нет?

[shurshur]

Дмитрий Свиридов, если ключ не будет делиться на подкаталоги, то по крайней мере в minio это будет работать плохо. Увы, мне пришлось с этим столкнуться в проде на бакете с >4 млн. файлов на одном уровне.

[shurshur]

romaro, скорее Amazon S3, но не такой уж он и "маленький", он реально может использоваться и для больших проектов. Но, как водится, с оговорками.

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

Ещё вроде в минио завезли тенанты (позволяет отдельными экземплярами минио отдельные бакеты обслуживать), но мы их пока не использовали.

[Дмитрий Свиридов]

shurshur, я в курсе, и нигде не писал, что этого делать не нужно

Answer 2

[ThunderCat]

Вариантов масса, каждый из которых зависит от кучи нюансов и тонкостей проекта.
Суть одна - директория для хранения не должна содержать в себе большой объем файлов, что достигается распределением файлов между поддиректориями.
Принцип создания поддиректорий не суть важен, можно создавать по датам например, типа /16112021/ или более ветвистое 2021/11/16/, как собственно и тумбы - можно создавать как хеш+размер, а можно все как одинаковое название (тот же хеш), но хранить в подпапках размера, типа: /16112021/100x100/e68d51251ab2d826ce8d0b92dd08a7e01c3d.jpeg, что достаточно просто позволит работать с тумбами, зная только фуллсайз картинку.

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

Answer 3

[Владимир Коротенко]

Вот одна из реализаций
https://qna.habr.com/q/673339

Также можно попробовать azure blob storage.

Answer 4

[ASultonov]

Тоже считаю второй способ самым оптимальным. Когда-то смотрел разные варианты и остановился на этом. Генерируется уникальный ID, создаются директории для равномерного распределения согласно второму способу из stackoverflow... а дальше можно посмотреть по ссылкам (w - width, высота зависит от пропорций изображения):

// ID: 3d02573d-4d28-7144-9f6e-f7372a084069
// Путь: [uploads]/[первые два символа ID]/[след. два символа ID]/[ID]/[что угодно][разделитель][разрешение][расширение]
{
	...
	photos: [{
		original: '/uploads/3d/02/3d02573d-4d28-7144-9f6e-f7372a084069/3d02573d_4032x3024.jpg',
		w1024: '/uploads/3d/02/3d02573d-4d28-7144-9f6e-f7372a084069/3d02573d_1024x768.jpg',
		w600: '/uploads/3d/02/3d02573d-4d28-7144-9f6e-f7372a084069/3d02573d_600x450.jpg',
		w256: '/uploads/3d/02/3d02573d-4d28-7144-9f6e-f7372a084069/3d02573d_256x192.jpg',
		w56: '/uploads/3d/02/3d02573d-4d28-7144-9f6e-f7372a084069/3d02573d_56x42.jpg'
	}]
	...
}

Можно удалить фотографию вместе с тумбами за раз удалив папку 3d02573d-4d28-7144-9f6e-f7372a084069.