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

Сейчас все хостинг-провайдеры перешли на SSD/SAS-диски. В итоге тот же объём дискового пространства стал стоить в разы больше. Становится актуальным вопрос хранения на сервере оригинальных изображений, которые занимают 80% места (от объёма, занимаемого всеми изображениями вместе взятыми).

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

Приходят в голову такие варианты :
1. Хранить оригиналы на локальном компьютере. При необходимости перегенерации малых изображений выполняется закачка на сервер небольших порций оригинальных изображений и на их основе - перегенарция малых изображений. И так N раз (насколько позволяет место на сервере).
2. Хранить оригиналы на другом сервере со старыми SATA-дисками (где найти таких хостеров ?). При необходимости перегенерации скрипт просто-напросто скачивает нужные оригиналы с этого сервера.

На практике крупные медиа-порталы как организовывают хранение больших объёмов медиафайлов. Не уж-то всё хранят на SSD/SAS-дисках ?

авторвыделенный сервер
Физический или виртуальный ?

авторА статику и в облачном хранилище можно хранить
Так облако дороже выходит. Того же необлачного VPS.

В идеале смонтировать на VPS облачное хранилище типа Яндекс.Диска или Облака@Mail.ru и отдавать клиентам статику с этих хранилищ как будто она отдаётся с нашего сервера.

Такое возможно ?

авторКак вариант, Яндекс.Фотки для оригиналов.
Да, только так. Правда, придётся писать интерфейс взаимодействия на основе Яндекс.API, т.к. генерация превью выполняется программно.

Можно было бы и всю статику хранить в облачном хранилище, например, в Amazon S3 или Selectel Cloud Storage
https://selectel.ru/services/cloud-storage/
https://habrahabr.ru/company/selectel/blog/231469/

но только прямые ссылки в этом случае будут ссылаться не на наш сайт, а на их сервер - для SEO нашего сайта это не есть хорошо...

vkleCyrax_02пропущено...

Да, только так. Правда, придётся писать интерфейс взаимодействия на основе Яндекс.API, т.к. генерация превью выполняется программно.Нафига? К фоткам же есть прямой доступ. Достаточно скармливать сайту и хранить в базе яндексяческий URL исходной картинки.
Т.к. загрузка фотографий (оригиналов), их обработка и генерация превью выполняется программно, то и эти самые Яндексовские URL нужно будет получать (и сохранять в БД) тоже программно. Не вручную же Яндексовские URL в нашу базу копипастить...

авторНу это вам виднее. Физический конечно выгоднее при больших объемах.
https://www.ovh.ie/dedicated_servers/storage/ Ну уж нет. Предпочтительнее на российских серверах...

авторЯ не про VPS в облаке.
https://aws.amazon.com/ru/s3/pricing/ Если останавливаться на таких хранилищах, то лучше в Selectel :
https://selectel.ru/services/cloud-storage/

Касательно таких облачных хранилищ. Проблема в том, что прямые ссылки ссылаются не на наш сайт, а на их сервер. В итоге страдает SEO-рейтинг сайта. Вернее, недополучает той "кармы", которую получил бы, если все эти ссылки ссылались на наш сайт.

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

ИзопропилCyrax_02,


HettО каких объемах идет речь?
?
20

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

авторМогу даже предложить вариант взять несколько не дорогих виртуалок и развернуть там свое облако, например Openstack Swift. Сможете масштабировать потом как захотите. Но это наверное самый сложный, но самый надежный, масштабируемый и дешевый вариант.
Такой вариант будет дороже, чем один VPS с тем же объёмом дисковой памяти. Это если рассматривать объёмы дисковой памяти до 1Тб (которые ещё предоставляют на SSD в рамках одного VPS).

Ещё один компромиссный вариант

В качестве оригиналов хранить на сервере не исходные тяжёлые (10-20 Мп) картинки, а их уменьшенные копии (псевдооригиналы)
Размер этих псевдооригиналов - минимальный, но который сейчас и в будущем обеспечит все запросы сайта. И с этого псевдооригинала в любой момент можно будет генерировать новые превью с новыми водяными знаками.

Размер такого псевдооригинала будет в 5-10 раз меньше оригинала.
На вскидку: размер, не превышающий по горизонтали и вертикали 1280 пикселей. Кто что думает по данному варианту ?

авторЗачем их на ssd хранить?Потому что сайт работает на SSD + код сайта должен иметь свободный доступ к оригиналам (или псевдооригиналам)