Помогите изобрести файлохранилку для картинок

1. Надо ли заморачиваться над разделением картинок по нескольким доменам, или это актуально только для гигантов типа гугля и фейсбука?

на маленьком сайтике только для знакомых делал загрузку фоточек на Picasa. Все ок работало, стоило чота около $20 в год.

Спасибо. Тема очень годная, в т.ч. по деньгам. Хотя есть ограничения:

1. Нельзя заливать НЕ картинки (архивы заливать надо не очень часто, но без этого нельзя) 2. Не сделать приватный доступ по своим правилам

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

1. imagemagic'ом сразу же делать превьюшки и сохранять их вместе с картинкой, внося соответствующие заметки в БД.

3. Решается соответствующими полями в БД.

Первые 3 пункта - это не вопросы :) . Вопросы в конце. И интересует критика спеки.

1. Надо ли заморачиваться над разделением картинок по нескольким доменам, или это актуально только для гигантов типа гугля и фейсбука?

Это актуально для лубого более-менее нагруженного сервиса, но можно ещё файлы на amazon-не хранить (стоит денег). Есть у меня один товарищ, а у него - сервис, который преимущественно картинки показывает, а на сервисе в каждый момент времени сидит ~6000 человек. Так вот ему приходится картинки с 5 серверов раздавать.

Амазон не в тему. Планов переплачивать в 10 раз у меня нет.

Много серверов != разные домены. Никто не мешает на один домен много IP прописать или поставить балансер. Нужно больше деталей, с цифрами, когда отдельные домены становятся актуальными. Траффик, количество запросов и т.п. Юзеры - слишком опосредовано.

Надо ли заморачиваться над разделением картинок по нескольким доменам, или это актуально только для гигантов типа гугля и фейсбука?

Разные домены это не самоцель, а CDN. Ну и не забываем про DNS overhead.

Амазон не в тему.

Правильно.

Если ли у кого-нибудь реальные данные, с какой скоростью ХХХ тысяч юзеров заливают на форумах/блогах YYY терабайт картинок (когда нет ограничений)?

Это зависит не столько от кол-во юзеров, столько от кол-ва сообщений в единицу времени. В каких то случаях, это будет 1pic/10msg, а на каком нибудь дваче аж до 1pic/2msg. (Грубо конечно, но все же...)

Bad requests cause double fs hit. Is it a problem?

Да.

Я бы подумал над тем, чтобы сделать /files/public/ и /files/secure/, во втором случае проверка на право чтения сразу, а не после еще одного запроса к ФС.

If preview not exists, we have to check too many extensions, when resizing via nginx

preview нужен всегда/почти всегда или очень редко? Мне кажется, что вы зачем-то экономите место на жестком диске. Не думали сделать очередь конвертации, чтобы не получилось так, что очень много больших картинок должны ресайзится в один момент?

+ в спеке ничего не говорится про бекап.

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

Про бекап сам пока не знаю. Ориентировочно - rsync на вторую машину, а там снапшоты. Мне сейчас нужен простой вариант, который можно слабать быстро и дешево. Если тема пойдет - можно будет все потом перевести на glusterfs, elliptics и т.п.

Я бы подумал над тем, чтобы сделать /files/public/ и /files/secure/, во втором случае проверка на право чтения сразу, а не после еще одного запроса к ФС.

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

Собственно, это был вопрос - будет ли двойное обращение к FS приводить к дерганью головок или нет. Мне показалось, что не должно, но до конца не уверен.

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

Где побольше, там серверы с DAS, рейды железячные, балансировка. Но это стоит дороже амазона, т.к. сами SAS диски довольно дорогие.

1. Вы можете цифры назвать? Хочу понять, с каких объемов начинается потребность в CDN. Речь именно и разнесении по регионам и датацентрам.

2. А почему пикасса для маленького сайтика? Траффик режут? Там в тарифах ценники до 16 терабайт.

3. У меня «невысокая» нагрузка. Из-за лимитов общий объем файлов ~30 гигабайт. Чистых аттачментов (без превьюшек) 326 тысяч. Картинки принудительно ресайзятся в 800х600.

Нагрузку на IO это не дает. Соответственно, если гайки отвернуть, то объем легко вырастет в 10 раз, а там уже недолго и в размер винта упереться.

1. Вы можете цифры назвать? Хочу понять, с каких объемов начинается потребность в CDN. Речь именно и разнесении по регионам и датацентрам.

Пара десятков Тб, сейчас не могу сказать точно, т.к. помимо хранилищ еще есть вещи для других проектов.

2. А почему пикасса для маленького сайтика? Траффик режут? Там в тарифах ценники до 16 терабайт.

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

И реально нужно разные домены? Масштабировать же можно за балансировщиком, и балансировщик тоже масштабируется, на одном домене.

Можете поподробнее рассказать в чем профит?

Можете поподробнее рассказать в чем профит?

в том, что есть балансировка на DNS, фронтэнда итд. Т.е. основные серверы, которые выдают текст не участвуют в отдаче картинок.

Я о другом стпрашивал. То что нужен отдельный img.myserver.com - вопросов не вызывает.

Вопрос был, надо ли делать img1.myserver.com, img2.myserver.com и т.д. И есть ли понятный пример из реальной жизни, когда от этого будет профит.

Вопрос был, надо ли делать img1.myserver.com, img2.myserver.com и т.д. И есть ли понятный пример из реальной жизни, когда от этого будет профит.

все зависит от того как ты будешь строить свое хранилище. Например, в сервисе одном у нас есть разделение по серверам, там просто пользователи разбрасываются на www/www1/www2/etc, но это выросло из-за того что изначально так было сделано. Человеку так удобнее было сделать, а сейчас это будет сложно переделать, т.к. там нагрузки большие и все написано на Си. Дешевле взять еще один сервер, чем переписать все заново.

Я с нуля делаю. Сейчас надо «чтобы просто, дешево и сердито», потом (очень потом) надеюсь добавить glusterfs/elliptics, но так чтобы снаружи пути не изменились.

img1/img2/... стремно тем, что при добавлении сервера могут ссылки поехать, и будут тонны 302 редиректов. Поэтому данную фичу хочется выпилить, если есть уверенность, что это не выйдет мне боком. Но рассмотреть и оценить саму такую возможность на этапе проектирования надо.

nodejs
glusterfs/elliptics

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

Профит будет, но в до определенного момента

---

Splitting components allows you to maximize parallel downloads. Make sure you're using not more than 2-4 domains because of the DNS lookup penalty. For example, you can host your HTML and dynamic content on http://www.example.org and split static components between static1.example.org and static2.example.org

For more information check «Maximizing Parallel Downloads in the Carpool Lane» by Tenni Theurer and Patty Chi. http://yuiblog.com/blog/2007/04/11/performance-research-part-4/

---

img1/img2/... стремно тем, что при добавлении сервера могут ссылки поехать, и будут тонны 302 редиректов.

А зачем она они поедут? На новом сервере - новые изображения, url старых не поменялся. У нас, например, в мемкэше хранится соответствие 'image_id' => 'server', при выдаче генерится ссылки вида http://i${server}.example.com/r/${image_id} Естественно, вся карта дублируется в mysql, по историческим причинам, сейчас в планах отказаться от мемкэша и всю инфу об изображениях запихнуть в redis/mongodb

По-возможности стараемся, что бы все изображения, которые будут на одной странице - были разнесены не более чем на 2 сервера

Не-не, параллельная скачка - это совсем другая тема. Для этого делается 1 запись вида *.img.myserver.com и рандомайзятся имена. Дешево и сердито. Но с точки зрения сервера ничего не меняется - точка входа одна.

А зачем она они поедут? На новом сервере - новые изображения, url старых не поменялся. У нас, например, в мемкэше хранится соответствие 'image_id' => 'server', при выдаче генерится ссылки вида http://i${server}.example.com/r/${image_id} Естественно, вся карта дублируется в mysql, по историческим причинам, сейчас в планах отказаться от мемкэша и всю инфу об изображениях запихнуть в redis/mongodb

Обычно делают хеш-функцию для разброса локейшенов. Это дает равномерную нагрузку. Но при расширении кластера у такого хеша плывет распределение -> надо перетаскивать картинки (и это нормально, если бы пути не плыли). Если же локейшены приколотить намертво картой - получится что при расширении кластера нагрузка всегда будет уплывать на последний сервер. А если последний сервер в 1 экземпляре всегда справляется, и дело только в размере диска - то нафига мудрить? Технически проще все через единый балансировщик на фронтенде прогонять, а по сервакам разруливать уже внутри - это намного проще конфигурировать, и упрощает код.

Короче, смысл в том, чтобы понять, какую практическую задачу мы решаем, и есть ли вообще потребность в ее решении :) . Наверное, много доменов могут разрулить региональный CDN без anycast. Но я не настолько крут, чтобы даже задумываться о таких потребностях. Теоретически, еще можно внутренний траффик кластера сократить, но что-то есть большие сомнения.

Поэтому кастую истории успеха по использованию кучи доменов для раздачи небольших файлов (не видео). Либо если кто-то скажет, что до 100 терабайт подобные трюки нафик не уперлись, это тоже будет очень годным ответом. Думаю, что больше 10 теребайт в ближайшие 5 лет у меня не предвидится.

Вот еще нашел, можно NAS купить за разумные деньги http://www.ovh.co.uk/nas/nas_HA_1tb_technical_sheet.xml . Если покупать через францию, то цена в еврах. До 3.6 тегабайт есть в наличии.

Получаются сравнимые деньги, что HA самопальное лепить. Кто-нибудь пользовался такими штуками? Какие там особенности?

Послушай, наркоман, у тебя детские объемы данных, а ты хочешь инфраструктуру гугла замутить. Знаешь, можешь сделать еще оригинальнее - для каждого файла сделай свой собственный домен!!!

На чем пишешь? Я сейчас для CMS тоже хранилку делаю. Только я в FS ничего не храню.

На жабаскрипте.