свой дата-сторадж под картинки

[chesser]

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

Варианты: внешнее решение или свое.
Из внешних, посмотрел цены на амазоновский s3 и стало грустно.
Поэтому склоняюсь к своему решению на базе хецнеровских дешевых серверов с 2*3тб в комплекте.

Вот мои варианты:
1)
img01.domain.com/md5/1.jpg
img02.domain.com/md5/2.jpg
img99.domain.com/md5/3.jpg
суффикс в сабдомене может быть первые две буквы md5 хеша картинки. Сабдомены заруливать на разные серверы, балансирую нагрузку и равномерно распределяя объем

2) redis/memcached распределенное хранилище, картинку хранить прям в БД. scale out будет весьма удобным, но этот вариант наверно тормознее первого

посоветуйте что-нибудь

[Yes!Host]

Сообщение от chesser

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

Варианты: внешнее решение или свое.
Из внешних, посмотрел цены на амазоновский s3 и стало грустно.
Поэтому склоняюсь к своему решению на базе хецнеровских дешевых серверов с 2*3тб в комплекте.

Вот мои варианты:
1)
img01.domain.com/md5/1.jpg
img02.domain.com/md5/2.jpg
img99.domain.com/md5/3.jpg
суффикс в сабдомене может быть первые две буквы md5 хеша картинки. Сабдомены заруливать на разные серверы, балансирую нагрузку и равномерно распределяя объем

2) redis/memcached распределенное хранилище, картинку хранить прям в БД. scale out будет весьма удобным, но этот вариант наверно тормознее первого

посоветуйте что-нибудь

Ход мыслей верный.
Первый вариант можно расширить, используя паралельные фс(glusterfs например). Сервера становятся в кучу, общая фс, отдача со всех одновременно, резервирование какое угодно(2х 3х 4х).
Второй вариант я бы не делал, вдруг база крешнется - восстанавливать долго будет.
Можно первый совместить с базой, в базе пути к картинкам, у каждой уникальное имя. Кешировать в память самые частоиспользуемые картинки.
Мы много раз делали первый вариант с разными вариациями, работает. Каши не просит.
Что-то новое тут врядли можно придумать.

[chesser]

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

спасибо за совет

индекс объектов у меня внешний, а хранить в файл-сторадже адрес объекта в базе не эфективно, т.к. при удалении адреса надо удалять объект, и наоборот. Т.е. получаем излишний геморой в виде поддержки целостности объектов сущности.

еще заинтресовался HDFS - но это уже более специфичная ФС, но возможно мой случай в будущем.

[JMen]

Сообщение от chesser

....
img01.domain.com/md5/1.jpg
img02.domain.com/md5/2.jpg
img99.domain.com/md5/3.jpg
...

img01.domain.com/m/d/5/md5/1.jpg

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

А как ты будешь знать какие картинки у тебя есть, а какие нет? Или запросы будут только на выдачу конкретной картинки?

[1een]

Предложу пережать картинки, если это jpg - один мегабайт это очень дофига вообще-то. Если у тебя не картографический сервис. Сэкономишь сразу половину

[Drunk Monk]

Тут наверное проблема больше в количестве

[dveredel]

На проекте, где была необходима распределенная система под хранение отдачу и конвертацию медиафайлов с относительно большой нагрузкой, после рассмотрения всех возможных вариантов в итоге был выбран самый простой -- физическое хранение "в лоб" безо всяких распределенных файловых систем и \ или навороченных дисковых кластеров, с дуплицированием одного файла на два сервера (получается одновременно и балансировка нагрузки и бэкап). Эта схема предусматривает превентивное добавление новых серваков в систему (а не когда уже везде место закончилось) для сохранения равномерного распределения.

Насчет "папок" верно подметили, необходима вложенная структура в N уровней, количество уровней зависит от прогнозируемого количества файлов в директории (10-20к уже дофига для одной диры). А уж как выбирать имена, тут как кому удобно тот так и делает, вариант "первые буквы хеша" самый распространенный, в случае когда новому файлу задается имя в виде этого самого рандомного (или не очень) хеша.

Объем диска на серваке должен коррелировать с прогнозируемым объемом популярных (!) файлов и оперативой, чтобы рационально использовался системный файловый кеш (виртуальная страшилка -- на серваке с "мульенами" постоянно используемых файлов и 1 гигом оперативки кеш забьется сразу, диск сойдет с ума, открытые хандлеры начнут плодится с огромной скоростью и все умрет нафиг)

[chesser]

Сообщение от JMen

img01.domain.com/m/d/5/md5/1.jpg

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

А как ты будешь знать какие картинки у тебя есть, а какие нет? Или запросы будут только на выдачу конкретной картинки?

многое зависит от файловой системы, я как-то проводил тесты по кол-ву файлов в папке. если менее 100к - можно вообще не парится
но я создаю папку вида /substr(md5,0,3)/md5 - т.е. разбиваю по префиксу из 3х первых символов хеша

запросы будут по типу CRUD, т.е. листинг мне не нужен. Индекс(списки) этих объектов лежат в отдельной БД, внешней по отношению к хранилищу.

Сообщение от 1een

Предложу пережать картинки, если это jpg - один мегабайт это очень дофига вообще-то. Если у тебя не картографический сервис. Сэкономишь сразу половину

ага, jpg по 1мб и более. Это фотографии товаров в разном ракурсе, разных опций и тд, т.н. Product Detailed Images. Ну там бывают меньше, бывают больше.
Пережимать не нужно, точнее нужно, но оригиналы хочется оставить, вот думаю как. Сейчас уже работает выдача картинок по параметрам: размеры, тип, наличие лого, плюс imagemagick немного обрабатывает картинки перед отдачей, например, убирает лишний фон.

[chesser]

Сообщение от dveredel

На проекте, где была необходима распределенная система под хранение отдачу и конвертацию медиафайлов с относительно большой нагрузкой, после рассмотрения всех возможных вариантов в итоге был выбран самый простой -- физическое хранение "в лоб" безо всяких распределенных файловых систем и \ или навороченных дисковых кластеров, с дуплицированием одного файла на два сервера (получается одновременно и балансировка нагрузки и бэкап). Эта схема предусматривает превентивное добавление новых серваков в систему (а не когда уже везде место закончилось) для сохранения равномерного распределения.

rsync'ом ?
блин, идея работать с прослойкой в виде облачной ФС очень заманчива

Сообщение от dveredel

Насчет "папок" верно подметили, необходима вложенная структура в N уровней, количество уровней зависит от прогнозируемого количества файлов в директории (10-20к уже дофига для одной диры). А уж как выбирать имена, тут как кому удобно тот так и делает, вариант "первые буквы хеша" самый распространенный, в случае когда новому файлу задается имя в виде этого самого рандомного (или не очень) хеша.

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

Сообщение от dveredel

Объем диска на серваке должен коррелировать с прогнозируемым объемом популярных (!) файлов и оперативой, чтобы рационально использовался системный файловый кеш (виртуальная страшилка -- на серваке с "мульенами" постоянно используемых файлов и 1 гигом оперативки кеш забьется сразу, диск сойдет с ума, открытые хандлеры начнут плодится с огромной скоростью и все умрет нафиг)

hot data set'ов у меня нет, и если вдруг и будут, то распределение вероятности в их сторону не сильно выраженное. Т.к. это тупо база(сервис/фид) с продукт контентом для b2b, возможно будут какие-то продукты популярные, но это не клиентский шоп с прямой отдачей картинок.

[ar4ibas]

Сообщение от chesser

как влияет количество файлов в директории на скорость

-основываясь на твоих тестах я пришел к выводу что все же лучше не допускать ситуации когда в директории будут 100к файлов, остановись на 10к

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