Форум успешных вебмастеров - GoFuckBiz.com

  Форум успешных вебмастеров - GoFuckBiz.com > Бизнес-решения > Скрипты, программы и технические решения
Дата
USD/RUB58.7570
BTC/USD0.0000
Скрипты, программы и технические решения Обсуждаем скрипты, программы и новые технологии.

Закрытая тема
Опции темы Опции просмотра
Старый 23.11.2011, 00:19   #1
chesser
автоматизирую интернеты
 
Аватар для chesser
 
Регистрация: 05.07.2009
Адрес: chesser.ru
Сообщений: 3,382
Бабло: $470735
По умолчанию свой дата-сторадж под картинки

надо хранить много картинок, примерно по 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 будет весьма удобным, но этот вариант наверно тормознее первого

посоветуйте что-нибудь
__________________
USA и NL серверы и VPS | wiki | блог | Drupal | NginxТДС
Ave, Google, morituri te salutant! © chesser
chesser вне форума  
Старый 23.11.2011, 04:17   #2
Yes!Host
Размещаю проекты
 
Аватар для Yes!Host
 
Регистрация: 19.12.2008
Сообщений: 88
Бабло: $12690
Отправить сообщение для Yes!Host с помощью Skype™
По умолчанию

Цитата:
Сообщение от 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х).
Второй вариант я бы не делал, вдруг база крешнется - восстанавливать долго будет.
Можно первый совместить с базой, в базе пути к картинкам, у каждой уникальное имя. Кешировать в память самые частоиспользуемые картинки.
Мы много раз делали первый вариант с разными вариациями, работает. Каши не просит.
Что-то новое тут врядли можно придумать.
__________________
Аренда выделенного сервера от 69евро VDS серверы от 7.95 евро виртуальный хостинг от 0.95евро
Yes!Host вне форума  
Старый 23.11.2011, 06:22   #3
chesser
автоматизирую интернеты
 
Аватар для chesser
 
Регистрация: 05.07.2009
Адрес: chesser.ru
Сообщений: 3,382
Бабло: $470735
ТС -->
автор темы ТС По умолчанию

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

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

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

еще заинтресовался HDFS - но это уже более специфичная ФС, но возможно мой случай в будущем.
__________________
USA и NL серверы и VPS | wiki | блог | Drupal | NginxТДС
Ave, Google, morituri te salutant! © chesser
chesser вне форума  
Старый 23.11.2011, 14:05   #4
JMen
учу php
 
Регистрация: 04.04.2008
Сообщений: 1,163
Бабло: $68290
По умолчанию

Цитата:
Сообщение от 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

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

А как ты будешь знать какие картинки у тебя есть, а какие нет? Или запросы будут только на выдачу конкретной картинки?
__________________
Подпись??? Не продам!
JMen вне форума  
Старый 23.11.2011, 14:09   #5
1een
Senior Member
 
Аватар для 1een
 
Регистрация: 28.05.2009
Сообщений: 1,304
Бабло: $161695
По умолчанию

Предложу пережать картинки, если это jpg - один мегабайт это очень дофига вообще-то. Если у тебя не картографический сервис. Сэкономишь сразу половину
1een вне форума  
Старый 23.11.2011, 14:10   #6
Drunk Monk
Je suis moine ivre
 
Аватар для Drunk Monk
 
Регистрация: 03.03.2009
Сообщений: 15,217
Бабло: $797160072
По умолчанию

Тут наверное проблема больше в количестве
__________________
EssayPartner.com. Партнерка по эссе трафу.
Drunk Monk вне форума  
Старый 23.11.2011, 15:52   #7
dveredel
Читатель
 
Аватар для dveredel
 
Регистрация: 23.11.2007
Сообщений: 422
Бабло: $48745
По умолчанию

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

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

Объем диска на серваке должен коррелировать с прогнозируемым объемом популярных (!) файлов и оперативой, чтобы рационально использовался системный файловый кеш (виртуальная страшилка -- на серваке с "мульенами" постоянно используемых файлов и 1 гигом оперативки кеш забьется сразу, диск сойдет с ума, открытые хандлеры начнут плодится с огромной скоростью и все умрет нафиг)
dveredel вне форума  
Старый 23.11.2011, 17:43   #8
chesser
автоматизирую интернеты
 
Аватар для chesser
 
Регистрация: 05.07.2009
Адрес: chesser.ru
Сообщений: 3,382
Бабло: $470735
ТС -->
автор темы ТС По умолчанию

Цитата:
Сообщение от 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 немного обрабатывает картинки перед отдачей, например, убирает лишний фон.
__________________
USA и NL серверы и VPS | wiki | блог | Drupal | NginxТДС
Ave, Google, morituri te salutant! © chesser
chesser вне форума  
Старый 23.11.2011, 17:55   #9
chesser
автоматизирую интернеты
 
Аватар для chesser
 
Регистрация: 05.07.2009
Адрес: chesser.ru
Сообщений: 3,382
Бабло: $470735
ТС -->
автор темы ТС По умолчанию

Цитата:
Сообщение от dveredel Посмотреть сообщение
На проекте, где была необходима распределенная система под хранение отдачу и конвертацию медиафайлов с относительно большой нагрузкой, после рассмотрения всех возможных вариантов в итоге был выбран самый простой -- физическое хранение "в лоб" безо всяких распределенных файловых систем и \ или навороченных дисковых кластеров, с дуплицированием одного файла на два сервера (получается одновременно и балансировка нагрузки и бэкап). Эта схема предусматривает превентивное добавление новых серваков в систему (а не когда уже везде место закончилось) для сохранения равномерного распределения.
rsync'ом ?
блин, идея работать с прослойкой в виде облачной ФС очень заманчива

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

Цитата:
Сообщение от dveredel Посмотреть сообщение
Объем диска на серваке должен коррелировать с прогнозируемым объемом популярных (!) файлов и оперативой, чтобы рационально использовался системный файловый кеш (виртуальная страшилка -- на серваке с "мульенами" постоянно используемых файлов и 1 гигом оперативки кеш забьется сразу, диск сойдет с ума, открытые хандлеры начнут плодится с огромной скоростью и все умрет нафиг)
hot data set'ов у меня нет, и если вдруг и будут, то распределение вероятности в их сторону не сильно выраженное. Т.к. это тупо база(сервис/фид) с продукт контентом для b2b, возможно будут какие-то продукты популярные, но это не клиентский шоп с прямой отдачей картинок.
__________________
USA и NL серверы и VPS | wiki | блог | Drupal | NginxТДС
Ave, Google, morituri te salutant! © chesser
chesser вне форума  
Старый 23.11.2011, 19:22   #10
ar4ibas
Senior Member
 
Регистрация: 11.11.2009
Сообщений: 362
Бабло: $71310
По умолчанию

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

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



Опции темы
Опции просмотра