Xpoint
   [напомнить пароль]

видео портал

Метки: [без меток]
2008-02-07 14:02:10 [обр] Николай[досье]
Здравствуйте, возник вопрос как сайты на подобии рутуби или ютуби справляются с конверацией видео ?
причем имеется ввиду именно "планировщик". в сети есть конечно много статей о том как конвертировать в flv и вставлять мету информацию...
но вот о практике никто естественно не пишет))
Так вот если даже 100 человек запустит на конвертацию одновременно 100 файлов я думаю никакой сервер не выдержит!
значит стоит писать некий планировщик, мало того хочется вынести это на отдельный сервер... может кто что осоветует ?
Всем спасибо
спустя 52 минуты [обр] Дмитрий Попов(6/509)[досье]

А что отсоветовать-то?

Да, надо выносить конвертацию отдельно. И не на один сервер в случае с ютубом.
По "Планировщику" - Вы очень узко мыслите, но то что это делается отдельными механзмами опять же однозначно.
По конвертации - в режиме низкого приоритета вполне себе средний сервер выдержит много больше конвертации 100 файлов одновременно.

Что еще?

спустя 26 минут [обр] Алексей Севрюков(0/1292)[досье]
Планировщик вообще может быть не нужен. Достаточно просто ставить файлы в очередь на конвертацию и делать по одному или несколько штук за раз.
спустя 5 минут [обр] Дмитрий Попов(6/509)[досье]
Я об этом и написал в общем-то... Тут все равно ведь явно бесполезно - при таком уровне вопросов ему надо либо стостраничный доклад по технологиям предъявить, либо все-равно не поймет, либо таки поймет что еще учиться и учиться...
спустя 1 час 26 минут [обр] Николай[досье]
спасибо Дмитрий :) за ваш уровень !! радует что есть такие люди )))) без в сети было бы скучно
вам Алексей скажите а то что вы написали это не планировщик ?
всем спасибо
спустя 1 час 43 минуты [обр] GRAy(0/259)[досье]
Николай[досье] Не планировщик - т.к. он подразумевает выполнение каких-до заданий в определённое время или через определённые промежутки времени. Очередь будет просто брать из некоего хранилища N-ное кол-во файлов и начинать их конвертить, по окончанию - брать следующую порцию и так пока в хранилище ничего не останется. Это проще, и в данном случае как раз то что нужно и даже лучше масштабируется - т.к. то что наполняет хранилище элементами, то что реализует это хранилище и то что в итоге достаёт оттуда файлы и обрабатывает их может жить на совершенно разных серверах и даже задействовать несколько на каждый из этапов.
спустя 13 часов [обр] Dennis F. Latypoff aka funky_dennis(0/84)[досье]
MapReduce
спустя 12 минут [обр] Прокаев2(0/35)[досье]
S3, SQS , EC2
спустя 1 час 51 минуту [обр] GRAy(0/259)[досье]
Dennis F. Latypoff aka funky_dennis[досье] Интересно где в этой задаче map а где reduce ;)
спустя 1 час 35 минут [обр] Dennis F. Latypoff aka funky_dennis(0/84)[досье]
Map    : "то что наполняет хранилище элементами, то что реализует это хранилище"
Shuffle: "то что в итоге достаёт оттуда файлы"
Reduce : "и обрабатывает их"

"может жить на совершенно разных серверах и даже задействовать несколько на каждый из этапов"
спустя 4 часа 46 минут [обр] GRAy(0/259)[досье]

Dennis F. Latypoff aka funky_dennis[досье] ИМХО, Вы неверно понимаете идеологию MapReduce. Позволю себе (не)большой оффтопик:
Функция map - на вход получает пару ключ1-значение1 а на выходе выдаёт спискок пар ключ2-значение2, после этого формируются коллекции из значение2 по одинаковым ключ2 (shuffle), эти коллекции передаются в функцию reduce как пара ключ2-коллекция(значения2). Результатом работы reduce будет одно значение3 для каждого ключа2.
Пример использования этого алгоритма для подсчёта кол-ва вхождений всех слов в большом наборе документов будет выглядеть так:

map(String key, String value):
  // key: Имя документа
  // value: содержимое документа
  for each word w in value:
    EmitIntermediate(w, 1); // результат "скармливается" по мере нахождения, но это уже специфика реализации.
reduce(String key, Iterator values):
  // key: слово
  // values: список "единичек" накопленных для данного слова на этапе map
  int result = 0;
  for each v in values:
    result += v;
  Emit(result);

И честно говоря я не вижу как данная система может быть эффективно применена для задачи обработки очереди файлов. Когда пользователь заливает файл, он(файл) просто буфферезуется в некое хранилище и в один прекрасный момент (когда у одного из серверов для конвертации дойдут до него руки) из очереди достаётся и конвертируется после чего выкладывается уже на сам видео портал. Схема эта отлично масштабируется - т.к. серверов для конвертации может быть сколько угодно, буфферное хранилище может быть реализовано как распределённая файловая система, ну и сам видео портал (как хранилище уже отконвертированных файлов) тоже может быть кластером. В начальной и дешёвой конфигурации все функции может выполнять одна машина, и даже тут есть возможность для масштабирования например несколько процессов серверов-конверторов (для более эффективного использования многопроцессорности-ядерности).

спустя 15 часов [обр] Dennis F. Latypoff aka funky_dennis(0/84)[досье]

Map на вход получает не пару ключ-значение, а все, что угодно, например, текст как в вашем примере.

Гугл привел как пример подсчет слов в документе, и весь интернет судорожно стал думать, как же им тоже применить MapReduce и никак не могут придумать применение этой схеме, на самом деле этой схемой можно перелопачивать абсолютно все, нужно лишь только правильно выбрать, что же будет ключом и значением для shuffle и reduce ;-)

спустя 11 часов [обр] GRAy(0/259)[досье]
Dennis F. Latypoff aka funky_dennis[досье] Слова "ключ" и "значение" ни к чему не обязывают - я употребил их в самом общем смысле. Вы всё-таки ушли от прямого ответа - как схема MapReduce может быть использована применительно к данной задаче? Ясно, что при желании, можно извратиться - но это не значит что теперь это каждой бочке затычка.
спустя 12 часов [обр] Dennis F. Latypoff aka funky_dennis(0/84)[досье]
GRAy[досье] Все, я сдаюсь :)
Powered by POEM™ Engine Copyright © 2002-2005