Как хранить большое количества изображений на сервере?

Question

[Андрей]

Сейчас я занимаюсь проектом, в нем каждый день пользователь будет загружать по 10 изображений, пользователей около 50-70, залитое изображание должно хранится как миннимум 1 месяц, как лучше всего это организировать на сервере? Хранить у себя на хостинге или зиливать на другой и хранить только ссылку? или есть другие варианты?

Comments

[Андрей]

MaxKorz, node js использую

Answer 1

[Alexander Litvinenko]

Если речь идет о Node.js, могу поделиться своей реализацией.

Но в целом файлы хранят по хешам, тоесть если у вас например есть файл с хешем

ddcab4080b10682d9384b04f41ddbf3e907165a5

то сохраняете его к примеру по пути

upload/ddc/ab4/080/b10682d9384b04f41ddbf3e907165a5/file.jpg

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

upload/ddc/ab4/080/b10682d9384b04f41ddbf3e907165a5/250x140.jpg

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

Это в основе, далее идет уже мультисерверность и различные серверы кеша для файлов.

Comments

[Андрей]

а можешь хостинг посоветовать?

[Alexander Litvinenko]

Андрей, юзаю digitalOcean, ничем не хуже\не лучше, дисковое пространство можно докупить.

[Андрей]

Alexander Litvinenko, prntscr.com/hlm3wi например на самом минимальном плане я смогу залить 1тб изображений? а для чего ссд там тогда?

[Alexander Litvinenko]

Андрей,

1тб изображений

1тб транфер имееться виду что вы можете прогнать такое количесто трафика, а вот диск в минимальном плане у вас будет 20GB

а для чего ссд там тогда?

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

[Roman K]

Андрей, там вообще-то 20гб написано. 1тб — это предел трафика месячный.

[Дмитрий Донской]

Alexander Litvinenko, особенность того что ФС имеет вид дерева. Когда много файлов в одной папке, идет дизбаланс листьев на ветке, приходится загружать всю информацию о ветке(папке), а не только часть, если все разбито по папкам

[Андрей]

Alexander Litvinenko, перед созданием хєша надо уменьшать размер изображения? влияет ли это на результат хэширования, или на производительность его создания?

[Андрей]

Дмитрий Донской, спасибо, ясно теперь, и если посмотреть например как это у вк устроено, то можно такую же схему увидеть) https://pp.userapi.com/c840326/v840326292/300c7/Zx...

[Alexander Litvinenko]

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

[Alexander Litvinenko]

Дмитрий Донской, да, именно про эту особенность и шла речь.

[Андрей]

Alexander Litvinenko, перед тем как сохранять изображение я его буду обрезать, так мне до или после обрезания делать хеш?

[Alexander Litvinenko]

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

[Андрей]

Alexander Litvinenko, а как лучше сделать очистку изображений которые хранятся на сервере больше месяца, перебором?

[Дмитрий Донской]

Андрей, я у себя сохраняю оригинал и на бэке делаю large для fullhd и small для превью.

В БД храни информацию о дате создания изображения, далее делай выборку устаревших записей по расписанию / вручную и удаляй файлы / папки

[Alexander Litvinenko]

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

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

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

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

[Alexander Litvinenko]

Дмитрий Донской, можно это делать при формирования урла. Запросили создать сылку на файл с ид таким-то, под формат fullhd, создаем ссылку и паралельно формируем нужный файл. Тогда у нас не накапливаеться лишних файлов и нет необходимости думать какие размеры нужны для каких файлов.

[АртемЪ]

Alexander Litvinenko, Со всем согласен, решение на основе хэшей правильное, но вот это -

при большом количестве файлов в одной папке, скорость работы файловой системы замедлиться

вызывает сильные сомнения.
С чего это вдруг скорость работы ФС замедлится? Разве что старинная какая нибудь ФС.

Ну и у автора вопроса речь идет насколько я понял о 10*70*30 =21тыс изображений.
Это очень мало.
Много это хотя-бы миллион.

[Alexander Litvinenko]

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

[АртемЪ]

Alexander Litvinenko, Ну насчет дерева - не все ФС на деревьях - ntfs, btrfs и наверное все из популярных?
В ext3 вроде простая индексация используется, или я не прав?

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

[Alexander Litvinenko]

АртемЪ, это так, но заранее не знаешь что там будет в дальнейшем.

Answer 2

[Кирилл Горелов]

От себя добавлю такой момент.
Просто сейчас как раз с этим связался.
Сайт на битриксе, владелец загружал фотографии в одну папку, она у него разрослась до 500 тысяч штук. И из-за этого весь сайт тормозит не смотря на то, что у него свой выделенный и очень мощный сервер. Тупит и все. Надо решить это проблему, что бы сайт работал быстрее.
Решение следующее.
Папку, в которой хранятся все картинки, надо разбить на под папки. и распихать туда картинки.
Готово, сайт ожил и стал работать быстрее. Дело в том, что файловая нагрузка сервера сильно нагружена, потому что приходится делать выборку из всей этой кучи картинок только нужные.

Comments

[АртемЪ]

С точки зрения ФС - как правило одинаково.
Скорость доступа к файлу не зависит от количества файлов в папке.
Можно с одинаковым успехом разложить миллион файлов по тысяче папок, или запихать все в одну.
Такое в основном на старых ФС наблюдалось.
А так - ext3 там индексирование есть, в ntfs вообще деревья.

Тормоза наблюдаются из за реализации - кто нибудь листинг файлов в коде сделает или что-то подобное.

[Кирилл Горелов]

АртемЪ, О том какая ФС была не могу сказать точно, но нам помогло!
И я решил на всякий написать!