Вопрос по архитектуре фотосайтов

Прочитал всё могу повторить, пишите нам, разработаем, оптимизируем, перепишем, допишем, и ваш фото-хостинг будет иметь право на жизнь =)

Андрей, меня ценник смущает 🍿 это сколько десятков серверов надо будет купить?

А что, для тебя десяток серверов это уже непомерно много?

Ну давай на чистоту. Ты как расчет делаешь? У меня формулы простые - есть I/O и кол-во операций. Откидываем все кэши и считаем голый I/O в переводе на кол-во дисков и контроллеров. Конкретно про операции речь идёт. Потом гипотетически навинчиваем кэши на разные уровни и в зависимости от предполагаемой эффективности рисуем графики с оптимизацией. Далее добавляем ко всему этому предполагаемый рост системы, а точнее увеличение объема данных со временем.... и получаем, что массштабировать кэш надо примерно пропорционально... таки хегня выходит полная. Если хочешь полную линейность на больших объемах, то кэш при расчетах нужно тупо не учитывать. В твоем случае эффективность кэша зависит от того кто "рисует" свежее файло на мордах... т.е. кол-во файлов в ТОП-е определяется не чем-то случайным, а задается конкретным алгоритмом ранжирования контента. Если с другой стороны, то кол-во ТОПовых файлов регулируется фиксированным кол-вом мест для превью и интересами аудитории.

Я делаю по методике Амазона, аналогично S3. Есть картинка, и есть цена ее показа для N посетителей, которая растет линейно. Все остальное тебя заботить не должно.

а если будет DDOS? 🍿

ps. в моем солюшене косты снижаются с объемом... почему они растут у тебя?

А если будет DDOS, то ты платишь за его фильтрацию или за показ картинок ботам, на выбор.

В твоем слюшены косты изначально замаркечены.

Андрей, в моём солюшене я сразу интегрирую защиту от ботов... а в твоем надо платить ☝

Еще один маркетинговый ход.

2:0 в мою пользу.

ты математическую модель непредоставил ☝ и это ставит всё твоё судейство под вопрос.

kostich добавил 04.06.2011 в 00:37

тут 5:0 в мою. в моем случае с NFS кэш смещен в сторону I/O, что на больших объемах в любом случае будет задействовано с максимальной эффективность... а в твоем случае кэш смещен в сторону раздачи. если за современные инструменты и системные вызовы, то высокоуровневый кэш имеет свойство дублироваться. я прекрасно помню как лет пять назад пытались раздавать файлы с большого SATA диска. при небольшом объеме оперативы выше производительность диска, а именно random-а, прыгнуть никак не получалось. с корзины умудрялись раздавать 500-600 мегабит одним сервером.... но это всё большие файлы были. сейчас рандом у sata подрос и раздавать 500-600 мегабит с одной железяки вполне возможно... а далее самое интересное, т.к. встаёт вопрос на сколько сессий раздавать этот рандом. с увеличением кол-ва сессий производительность решения стремительно уходить в ноль и узким местом становится дисковая подсистема. идеальное решение в данном случае сводится к дублированию инфы по стораджам. 10 гигов в пике, ну как у тебя, можно раздавать с нескольких NFS-ов. с увеличением кол-ва файлов надо увеличивать кол-во NFS-ов. пальцем тыкать не буду, но можешь зайти на netapp и почитай кто их юзает.

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