# ramzes (11.11.2016 / 16:34)
все там так. мультимедиа. вагон аудио-видео файлов.
Не имея нескольких собственных серверов в каком-нибудь Colocation у своих знакомых (которые разместят твои железяки почти нахаляву), или если ты не сын директора бензоколонки на оживленном проспекте, о подобном думать несерьезно.
# Simba (11.11.2016 / 16:36)
Угу) Пользователи файлы загружать не могут с мобильного интернета) Пол России на мобильном интернете, как бы не больше)
Ну покажи где лучше
Да и вроде пока только двое жаловались?
# AlkatraZ (11.11.2016 / 16:35)
С Youtube или Xvideos собираешься конкурировать?
отучаю от контактика
товарищи хотят соцсеть. вероятно и с ххх-уклоном, или без,
или гигабайты музыки, или террабайты видео. на их вкус, мое дело организовать бюджетное хранение этого добра с технической стороны, при этом не вынудить их брать что то сложнее и больше обысного сервера. (логический сервер у нас оочень мощный, но и не дешевый, хранить на нем файлы не выгодно ни с какой стороны)
с выбором сервера проблем не ожидается, т.к. товарищи напрямую занимаются продажей соответствующих услуг, а это будет хобби для души, ну и может вторичный заработок
# AlkatraZ (11.11.2016 / 16:37)
Ну покажи где лучше
Ну у него проект как раз на аплоад юзерами, я не думаю что для него будет важно количество места с невозможностью ничё загрузить)
Ну, а по цене конечно, неплохо, только это всё равно что тачку купить и не ездить на ней)
# ramzes (11.11.2016 / 16:39)
мое дело организовать бюджетное хранение этого добра с технической стороны
Вот тут как раз и проблема.
Если как ты сказал, в среднем 20 гигов на человека. а этих человеков тыща, тебе надо диск от 20 терабайт и выше.
Тут уже или облако, или держать на нескольких серверах.
Перебрасывать с сервера на сервер нет смысла. Тут нужен другой алгоритм:
1) Ты в скрипте регистрируешь несколько (число не ограничено) серверов, хранилищ файлов.
2) В базе данных к конкретному файлу прописано, на каком сервере он (файл) хранится, и URI доступа
3) При выгрузке файла скрипт поочередно равномерно заливает файлы на все зарегистрированные серверы. Если предыдущий файл выгружался к примеру на 4-й, щас грузим на 5-й.
4) При выгрузке учитывать загруженность сервера (лимит ставится при регистрации данного сервера), если там слишком много, оно в очереди выгрузки пропускается до тех пор, пока остальные сервера не догрузятся до его уровня.
Ну где то так...
AlkatraZ, да, это хорошее решение, но я бы советовал избавить роутер нод (та логика, которая говорит на какой сервер грузить очередной файл) от проверки загруженности целевой ноды перед загрузкой. Роутер нод должен быть максимально компактным, потому что он очень активно используется (наподобие DNS сервера). Лучше грузить поочередно и мониторить загруженность автоматически или глазами, а после распределять нагрузку.
И да, еще нужно думать о RAID, ибо железо будет падать от нагрузок "только в путь"
AlkatraZ, как я уже сказал, с сервером-донором проблем не ожидается.
да и не моя это задача. а лезть с советами по серверам к человеку который в этом на порядок опытнее меня.... ну это как он мне по коду советовать начнет - мешаться и раздражать)
мое дело только логика.
размножить доноры тоже не проблема, просто вынести апи выдачи на отдельный сервер, чекающий по всем донорам, это не сложно по сути.
мне главное максимально безотказно и быстро выполнить пересылку, при этом не обосраться с защитой
Проще говоря, отдачу я уже решил, добавлю некоторые мысли из этой темы и выйдет хорошо и надежно.
Частично и пересылка решена, отдам ее донору, а после с перым запросом к файлу и ответом от донора что файл был импортирован, удалю изначальный на логическом сервере.
Остается метод импорта, и его реализация.
Получается скорость перетягивания не критична, главное надежность и отказоустойчивость