Комментарии 39
Вчера в комментариях просили рассказать о реальных use-case использования Tarantool.
Вот и один из реальных примеров, правда еще на предыдущей версии Тарантула. Сервис в проде (cloud.mail.ru).
Вот и один из реальных примеров, правда еще на предыдущей версии Тарантула. Сервис в проде (cloud.mail.ru).
Ряд сервисов (например, YouTube, социальные сети и прочие) конвертирует пользовательское видео в пригодные для воспроизведения форматы сразу после загрузки. Только после окончания конвертации ролик становится доступным для просмотра, но оригинал при этом удаляется.
Выделенное неверно. Оригинал доступен для скачивания через google.com/takeout
Понятно, что у облачного файлового хранилища отношение watch qps / corpus size гораздо меньше, чем у специализированного видео-хостинга, но неужели CPU настолько дешевле хранилища, что вы даже уже перекодированные куски видео удаляете?
Мы удаляем лишь те кусочки, к которым не было обращений некоторое время. Если какой-то кусочек не запрашивали скажем сутки, то весьма вероятно, что в следующий раз за ним придут не скоро, или вообще никогда не придут.
Сейчас у нас довольно большой запас по CPU + время конвертации весьма мало, поэтому такая стратегия показывает себя хорошо.
Сейчас у нас довольно большой запас по CPU + время конвертации весьма мало, поэтому такая стратегия показывает себя хорошо.
А у вас перемотка идет не на ключевой кадр, и от этого вся картинка идет зеленым при перемотке.
У нас ключевые кадры сбрасываются строго раз в секунду, и перемотка должна работать тоже с точностью до секунды, известных багов про это мы пока не знаем.
Пожалуйста, напишите мне в личку или на m.andreev@corp.mail.ru подробности: ОC, браузер/версия приложения, email, по возможности — ссылка на файл, с которым наблюдались проблемы.
Пожалуйста, напишите мне в личку или на m.andreev@corp.mail.ru подробности: ОC, браузер/версия приложения, email, по возможности — ссылка на файл, с которым наблюдались проблемы.
Вообще вы бы там лучше биткойны майнили, а не занимались одинаковыми бессмысленными вычислениями каждый день :)
Было б неплохо, если бы вы webdav реализовали
Сделайте лучше статью «Криворукие во всем: как мы повесили две вывески друг перед другом»
так это ж отказоустойчивость
это когда сказать нечего, а «обосрать» хочется?
Отличная техническая статья, а вы вывеску явно не эти люди вешали и даже рядом не стояли (максимум мимо проходили когда ее рабочие вешали, причем скорее всего уткнувшись в телефон).
В обще Mail.ru много всего хорошего про технические аспекты рассказывает и выкладывает, за что им спасибо.
Отличная техническая статья, а вы вывеску явно не эти люди вешали и даже рядом не стояли (максимум мимо проходили когда ее рабочие вешали, причем скорее всего уткнувшись в телефон).
В обще Mail.ru много всего хорошего про технические аспекты рассказывает и выкладывает, за что им спасибо.
Уж не знаю, что хорошего в статьях мэйл.ру, но все их конечные продукты выглядят примерно также, как и эта вывеска.
А мне нравится. Раньше не нравилось, но с тех пор прошло много времени и они изменились.
ну так вы почитайте статьи, они интересные, даже если конкретно этим не занимаешься.
а еще они проводят встречи, за все не знаю, но я был на Встреча по web-разработке. Отличное выступление разработчиков, рассказывали что использовали, как решали проблемы взаимодействия команд и управления кодом — без пафоса и гонора, рассказывали боль и проблемы с которыми сталкивались, какие шишки набивали.
Мы же тут не продукты обсуждаем, а вполне конкретное техническое решение.
Если Вы хотите рассказать какие плохие продукты они делают — напишите статью.
а еще они проводят встречи, за все не знаю, но я был на Встреча по web-разработке. Отличное выступление разработчиков, рассказывали что использовали, как решали проблемы взаимодействия команд и управления кодом — без пафоса и гонора, рассказывали боль и проблемы с которыми сталкивались, какие шишки набивали.
Мы же тут не продукты обсуждаем, а вполне конкретное техническое решение.
Если Вы хотите рассказать какие плохие продукты они делают — напишите статью.
Коллеги, а сколько корова дает молока видео трафика исходящего?
Эх, в лохматом 2008-м, помню, похожее чудо примерно так уже и работало :))) www.kip.ru/realtime/2008/11/smooth-streaming.html Потом так много где стало. Молодцы — хорошо сделали. Работает здорово!
Конвертация просто на CPU идет? Рассматривались ли какие-то специализированные аппаратные варианты?
А что прозойдет, если я загружу какое-нибудь видео, а потом запощу его куда-нибудь в твиттер, где 100к подписчиков и примерно 1000 из них кинется смотреть этот файл одновременно?
Ничего страшного :)
У каждого кусочка есть поминутный счетчик запросов к нему за последние 5 минут, и на основе этих данных принимается решение о популярности кусочка (сейчас критерий это «за последнюю минуту больше N запросов») и в случае если он становится популярным, то происходит его распространение на другие сервера.
Т.е. непопулярные кусочки отдаются только с одного сервера, и если запрос приходит на другой фронт, то он просто переадресуется, а для популярных кусочков любой фронт может отдать его из своего локального кэша.
У каждого кусочка есть поминутный счетчик запросов к нему за последние 5 минут, и на основе этих данных принимается решение о популярности кусочка (сейчас критерий это «за последнюю минуту больше N запросов») и в случае если он становится популярным, то происходит его распространение на другие сервера.
Т.е. непопулярные кусочки отдаются только с одного сервера, и если запрос приходит на другой фронт, то он просто переадресуется, а для популярных кусочков любой фронт может отдать его из своего локального кэша.
А можно Ваш патч к ffmpeg где-то посмотреть?
Вот чес-слово, лучше бы вы облаку дали быть хранилищем, а не видеохостингом — а для этого немалые силы не тратили бы на видео, а допатчили вашу реализацию webdav и выполнили бы свое обещание, дававшееся неоднократно и здесь, и в личных ответах ТП, что webdav скоро-скоро будет-будет.
Не в обиду, и, конечно, обещанного три года ждут, но и облако работает с декабря 2013 (в то время, плюс-минус, WebDav, кстати, работал), так что как раз третий год начинается — как думаете, дождемся ли?
P.S. Догадываюсь, что dav могут открыть только для юзеров платных аккаунтов. Но тут свои грабли: доверие к mail.ru. Не у всех оно есть, как раз из-за таких вот обещаний (а также всяких лимитов http://habrahabr.ru/post/272661/ в безлимитных ящиках).
Не в обиду, и, конечно, обещанного три года ждут, но и облако работает с декабря 2013 (в то время, плюс-минус, WebDav, кстати, работал), так что как раз третий год начинается — как думаете, дождемся ли?
P.S. Догадываюсь, что dav могут открыть только для юзеров платных аккаунтов. Но тут свои грабли: доверие к mail.ru. Не у всех оно есть, как раз из-за таких вот обещаний (а также всяких лимитов http://habrahabr.ru/post/272661/ в безлимитных ящиках).
А им-то самим webdav — зачем?
Ну с той же пользой, что и проигрывание видео )
Я понимаю, что облако позиционируют как хранилку для всей цифровой жизни, а заодно и для работы, и под это пилят просмотр. Но, серьезно, кто-то из нас верит, что оно проживет 100 лет? А 50? А 10? А на год-два копировать туда-сюда — стоит ли оно того? Причем еще не берем во внимание шанс не найти свои файлы, а потом получить ответ от ТП со ссылкой на TOS, а иногда и припиской «попробуйте сейчас».
Это я к тому, что любые фичи кто-то делает, и кто-то заказывает. Мне лично внешний жесткий диск с TLS был бы нужнее, чем чистое «облако» (я тогда сам буду понимать, как и куда синкается; верить же в алгоритмы облачного загружателя я побаиваюсь). Видео же я лучше локально скачаю и потом посмотрю: у меня просто нет супербольших файлов, а небольшие даже на SSD всегда поместятся.
Я понимаю, что облако позиционируют как хранилку для всей цифровой жизни, а заодно и для работы, и под это пилят просмотр. Но, серьезно, кто-то из нас верит, что оно проживет 100 лет? А 50? А 10? А на год-два копировать туда-сюда — стоит ли оно того? Причем еще не берем во внимание шанс не найти свои файлы, а потом получить ответ от ТП со ссылкой на TOS, а иногда и припиской «попробуйте сейчас».
Это я к тому, что любые фичи кто-то делает, и кто-то заказывает. Мне лично внешний жесткий диск с TLS был бы нужнее, чем чистое «облако» (я тогда сам буду понимать, как и куда синкается; верить же в алгоритмы облачного загружателя я побаиваюсь). Видео же я лучше локально скачаю и потом посмотрю: у меня просто нет супербольших файлов, а небольшие даже на SSD всегда поместятся.
Я думаю, они там не рассчитывали на продвинутых гиков, которые принесут к ним свои бэкапы. Поэтому и не делают webdav. Они думали, что у ним придут тихие-спокойные end-user'ы, которые не будут заливать терабайты данных и требовать webdav'ов и прочих красот, тихо перенесут свою почту, будут тихо смотреть рекламу и приносить копеечку, Гики с запросами на webdav, думаю, там не очень нужны. Отсюда и отсутствие какой-либо инициативы в этой области (как подтверждение моей гипотезы). Нужно ли нести к ним свои данные гикам при такой их мотивации? Не знаю. Вряд ли. Есть много других мест, более технологичных. Зачем страдать-то? :)))
Вы наверняка правы. Только вот возьмем облако: хорошо, когда у меня есть пяток устройств с безлимитной памятью, в которые я мечтаю заливать то же, что на них всех лежит. Сферическая синхронизация, да, в вакууме.
В жизни все проще и грустнее. На телефоне памяти/флешки свободно N Мб, на компе — M Мб, на еще одном компе — S Мб. Какие бы эти числа не были, я хочу держать на каждом устройстве только нужные на нем данные. Скажем, на телефоне только в дальнейшем нужные фото, на компе одном — все-все, а на третьем, где SSD, тоже, только нужные, но немного другие, чем на телефоне. В синхронизаторе cloud.mail.ru есть выбор, какие папки синхронизировать, но, если папку сначала добавить в список синхронизации (чтобы она в облако улетела), то потом, при исключении из списка синхронизируемых (чтобы не заниматься синхронизацией ее в дальнейшем) папка/файлы удаляется на локальной машине. И, наоборот, при удалении файла локально, он удалится в облаке. И, обращаю внимание, точность указания — до папки, так что нельзя по одному файлу отправлять в облако, а затем удалять только локально (что было бы для фото полезно).
Т.е. вариант «наснимать снимков на телефоне, загрузил их на комп1, а часть на комп2, а потом на телефоне постирал ненужные» — такое не прокатит. Фактически, есть два рабочих подхода: загружать через веб-морду (но цель-то была сделать seamless работу, нет?), либо создать папку в папочке, из которой беред данные cloud-синхронизатор, положить (скопировать!) в нее контент, дождаться окончания синхронизации, убрать папку из списка синхронизируемых (она локально удалится, в облаке же данные останутся). И то, и то требует сил, и то, и то потенциально ведет к потере данные при неверном движении. Браузером, однако, пользоваться понятнее и проще, потому что там работаешь просто с файлами, а во втором варианте надо еще думать, что из-за чего произойдет, и что можно потенциально потерять.
И это, заметьте, я описываю работу с данными в режиме как раз цифрового дневника — т.е. как раз в сценарии, когда и просмотр видео в браузере актуален, и вроде как в котором синхронизация пригодится.
Просто синхронизация — отличная вещь, но надо понимать, что если в телефоне 16 Гб флешки, а в компе — 1Тб, то юзер должен долго попрыгать, чтобы синхронизация работала. Сделает ли это не гик? Может быть, но не факт.
В жизни все проще и грустнее. На телефоне памяти/флешки свободно N Мб, на компе — M Мб, на еще одном компе — S Мб. Какие бы эти числа не были, я хочу держать на каждом устройстве только нужные на нем данные. Скажем, на телефоне только в дальнейшем нужные фото, на компе одном — все-все, а на третьем, где SSD, тоже, только нужные, но немного другие, чем на телефоне. В синхронизаторе cloud.mail.ru есть выбор, какие папки синхронизировать, но, если папку сначала добавить в список синхронизации (чтобы она в облако улетела), то потом, при исключении из списка синхронизируемых (чтобы не заниматься синхронизацией ее в дальнейшем) папка/файлы удаляется на локальной машине. И, наоборот, при удалении файла локально, он удалится в облаке. И, обращаю внимание, точность указания — до папки, так что нельзя по одному файлу отправлять в облако, а затем удалять только локально (что было бы для фото полезно).
Т.е. вариант «наснимать снимков на телефоне, загрузил их на комп1, а часть на комп2, а потом на телефоне постирал ненужные» — такое не прокатит. Фактически, есть два рабочих подхода: загружать через веб-морду (но цель-то была сделать seamless работу, нет?), либо создать папку в папочке, из которой беред данные cloud-синхронизатор, положить (скопировать!) в нее контент, дождаться окончания синхронизации, убрать папку из списка синхронизируемых (она локально удалится, в облаке же данные останутся). И то, и то требует сил, и то, и то потенциально ведет к потере данные при неверном движении. Браузером, однако, пользоваться понятнее и проще, потому что там работаешь просто с файлами, а во втором варианте надо еще думать, что из-за чего произойдет, и что можно потенциально потерять.
И это, заметьте, я описываю работу с данными в режиме как раз цифрового дневника — т.е. как раз в сценарии, когда и просмотр видео в браузере актуален, и вроде как в котором синхронизация пригодится.
Просто синхронизация — отличная вещь, но надо понимать, что если в телефоне 16 Гб флешки, а в компе — 1Тб, то юзер должен долго попрыгать, чтобы синхронизация работала. Сделает ли это не гик? Может быть, но не факт.
если попросить его сконвертировать тот же файл сначала с 0 по 10 секунду, а потом (отдельным запуском FFmpeg) с 10 по 20 секунду, и сделать правильный плейлист, то при переходе с одного файла на другой (примерно на 10-й секунде) мы услышим заметный звуковой щелчок. Мы потратили не один день на перебор различных параметров запуска FFmpeg, но ни к какому результату не пришли. Пришлось влезть внутрь и написать небольшой патч, который при передаче определенного параметра командной строки исправляет этот недочет, возникающий из-за особенностей кодирования аудио- и видеодорожек.Как в итоге поправили, просто начинаете кодировать аудио чуть раньше и обрезаете его до нужного фрейма, или как-то умнее? Я тоже натыкался на эту проблему, но из-за того, что мне аудиодорожку нужно кодировать целиком, а не по кускам, и кодируется она на порядки быстрее видео, решил, что мне достаточно кодировать аудио отдельно.
Немного не понятен момент:
Если конвертация на тех же машинах, где хранятся файлы, то зачем HTTP-ссылки? Или изоляция подразумевает, что доступ вовне есть только по HTTP, и как раз так исходники и попадают внутрь? (Вариант, что конвертит не тот сервер, который хранит файл, тоже, в принципе, возможен...)
И, выходит, что патчик для «медленного mov» нужен как раз для работы с этими HTTP-ссылками: были б файлы локальными, было бы проще.
конвертеры, готовые получить на вход HTTP-ссылку на файл
…
(конвертация) работает на наших стораджах в специальной изолированной среде
Если конвертация на тех же машинах, где хранятся файлы, то зачем HTTP-ссылки? Или изоляция подразумевает, что доступ вовне есть только по HTTP, и как раз так исходники и попадают внутрь? (Вариант, что конвертит не тот сервер, который хранит файл, тоже, в принципе, возможен...)
И, выходит, что патчик для «медленного mov» нужен как раз для работы с этими HTTP-ссылками: были б файлы локальными, было бы проще.
конвертит не тот сервер, который хранит файл
в первую очередь из-за этого, точнее конвертит не обязательно сервер с файлом (но может так случиться, что это будет и он).
Мы решили сделать такой вариант, т.к. он более универсален и позволяет ставить конвертеры где угодно, где есть CPU (а не исходный файл) — в нашем случае это стораджа.
Это так же позволило не наступить на возможную проблему, когда несколько популярных тяжелых для конвертирования файлов оказались на одном сторадже и их смотрят прямо сейчас.
так исходники и попадают внутрь
и это тоже верно, прямого доступа у изолированного окружения к файлам нету
В системе видеонаблюдения с тысячами камер делали конвертацию на лету без кэширования, т.к. вероятность того, что два оператора будут смотреть одинаковый фрагмент стремится к нулю. При этом тем клиентам, которые способны декодировать оригинальное видео, пересылали именно его, чтобы не занимать ресурсы на конвертацию. От стриминговых решений от Microsoft и Apple отказались, т.к. был необходим мгновенный отклик — видео на клиенте должно идти максимум через 200 мс.
В вашем случае непонятно зачем пережимать в сценариях «снял на телефоне, кинул в облако и удалил». Очевидно, что телефон имеет необходимые декодеры для своего же видео. Могли бы пояснить этот момент?
А еще любопытно узнать как часто случается, что более одного пользователя смотрят один и тот же ролик или даже фрагмент? Кажется, что в большинстве сценариев люди сами смотрят свои же ролики.
В вашем случае непонятно зачем пережимать в сценариях «снял на телефоне, кинул в облако и удалил». Очевидно, что телефон имеет необходимые декодеры для своего же видео. Могли бы пояснить этот момент?
А еще любопытно узнать как часто случается, что более одного пользователя смотрят один и тот же ролик или даже фрагмент? Кажется, что в большинстве сценариев люди сами смотрят свои же ролики.
Очевидно, что телефон имеет необходимые декодеры для своего же видео.
Для своего же видео — да, имеет. Но даже в этом случае возможна ситуация, что сняли тяжелое (по объему) 1080p видео и хотим посмотреть его из облака при подключении к 3G — в нашем случае проблем с этим не будет, видео просто будет отдаваться в 360p или даже 240p — и пользователь все же будет иметь возможность посмотреть его без больших задержек.
Если же сняли на один телефон или на видео-камеру, а хотим посмотреть на другом телефоне, то в довольно существенном проценте случаев без конвертации не обойтись.
как часто случается, что более одного пользователя смотрят один и тот же ролик или даже фрагмент
Запросов, на которые у нас уже есть готовый кусочек (не важно — этим же пользователем созданный или кем-то еще, ведь у нас дедубликация по хэшам файлов) у нас около 30%
Интересно, сколько времени заняла разработка такого функционала и сколько разработчиков было задействовано?
Если не можете ответить, то всё равно спасибо за интересную статью.
Если не можете ответить, то всё равно спасибо за интересную статью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Важнейшее из искусств: как мы реализовали проигрывание видео в Облаке Mail.Ru