Выше был сарказм )
Судя по статьям, на этом примере www.cse.scu.edu/~tschwarz/coen180/LN/DRAM.html
есть сетка, размером 1024 * 4096. На Figure 4 показана схема, однако адресация там показана блоками Row decoder & column decoder.
У нас же НЕ 5000 контактов что бы работать с сеткой напрямую. У нас есть адрес из максимум 32 бит.
1. перепробовал 3 разных вида. Но сам "папа" у всех практически одинаков. А на счет зубочистки конечно попробую, но хотелось бы без колхоза ((( Неужели только у меня одного такая проблема ...?
zhulan0v: поддерживаю. У меня карта VISA Business, весь инет ее принимает без проблем, кроме liqpay и intercass. Oплатить с карты не могу никак (я как покупатель). Приходится ходить через терминалы пополнять
1. Согласен. Но есть raid массивы. Их иногда постигает таже участь. Вероятность выхода сразу одной пары есть, но не настолько велика. На эту тему до сих пор идут дебаты.
2. Да на счет CDN будет класическая схема. И в данном случае, такая архитектура будет выступать в роли стореджа. Но есть преимущество, можно один файл, тянуть паралельно со многих нод, как это например делают распределенные файловые системы.
3. keep alive нету. Старое соединение закрыватся будет. Сервер уже написан собственноручно =)
4. Да, заливку, конвертацию не описывал(с этим я думаю разберусь). А rsync уже не модно?
5. Ну это дело вкуса. Хочу хардкор
Да кстати, если уж заговорили о распределенных фс может подскажете фс которая бы могла работать с одной сетевой картой и не требовала lan сети между нодами?
@TomaZ: Если вы имеете ввиду "риалтайм" = live streaming то конечно же нет. Схема для VOD видео. Что касается про "горячие куски", - это вы имеете ввиду когда все пользователи запрашивают кусок с одного сервера? Ок. Ну придут. Сам сервер физически не сможет отдать более 128мб (1Gbit) в секунду. Он будет ставить в очередь пользователей, обслуживать по 64 пользователя в секунду (файлы по 2МБ) и по 64 человека отправлять их на следующие ноды, таким образом обеспечивать очередь. Да, пользователям в конце очереди надо будет подождать, но только при старте видео. Дальше же, - произойдет самостоятельная балансировка, т.к. на второй нод придет столько пользователей, сколько первый смог отпустить. Надеюсь я правильно изложил мысль...
@TomaZ: Ну предположим есть 200 серверов. Одно видео "мега-поопулярное". Его смотрят тысячи. Разделив видео на кусочки и разложив его по всем серверам можно обеспечить равномерную нагрузку на все сервера. И это при том что каждый сервер дешевый гигабит. А в случае с одним mp4 который нельзя разделить, приходится его отдавать с front-end сервера \одной ноды или строить балансировщики \ кешеры и прочее которые как правило от 10Gbit и больше и влетят в копеечку.
@TomaZ: Я Вам скажу однозначно не самое простое. Т.к. во первых он не решает проблему горячих видео (т.к. видео все равно с одного сервера раздается) Во вторых каждому стриминг серверу надо откуда-то брать оригинал, а для этого нужно внешний NAS или SAN строить и переделывать всю архитектуру проекта.
OMG))) Каждый первый задает этот вопрос. Представте что у вас кучка серверов и видео разбросано по разным сервакам. Тут есть проблема "горячих видео". Прикинем что одно видео смотрят 10 тысяч пользователей в hd. Любой сервер упадет. На счет "покупай оборудование" - не катит. Я не миллионер
Все временные файлы выносятся в /tmp. Так принято, решил сделать так как делают все. Там не только большие временные файлы, еще логи от ffmpeg (двухпроходное кодирование), и так для каждого битрейта, а их -3шт. Так если же по умолчанию /tmp находится в корне, почему рекомендуют врем. файлы хранить в /tmp или /var/tmp ? (На счет очистки /tmp при перезагрузке знаю)
Я то думал в этом есть смысл (например этот каталог специально расположен в противоположной области диска - в самом конце, или наоборот, или же фс его как отдельный раздел принимает)
@L3n1n Ну вот пользователь Петя загрузил файл. Для файла сгенерировался уникальный id (это хеш времени). Он его шарит, пользователи его активно скачивают. Определить по id чей конкретно этот файл невозможно. Зато в базе есть таблица пользователей со ссылками на эти id. И только сделав SELECT "USER" from files WHERE "ID" = $someid можно сказать что файл принадлежит Пете.
В этом и трудность.
В лог можно писать id и размер самого файла.
Итого один файл на каждом сервере.
Предположим таких серверов у нас 10. Нужно с каждого сервера скачивать этот лог, парсить его (а он может быть и большим) а потом составлять таблицу соответствий id => user, суммировать все и только потом говорить что у Пети трафик составил 10 Гб, у Васи -8 и т.д.