PS: о сегментах видео Видео представляет собой цельный файл, сегменты видео можно получить с помощью метаданных файла Такую работу поддерживают, например, HLS и MP4
Именно таких разборов и видосов не хватает на ютубе, а то сплошные питонисты с тестировщиками. Отлично, что субъективно, это даже интереснее кто как делает и какие подходы применяет. Наконец-то в рекомендациях 🎉
Про балансировку на клиенте - есть решение лучше с балансированием на уровне dns сервера. Так url один, но его можно распределить на несколько ip адресов.
Спасибо за видео, полезно! Было бы круто ещё показать на примере как подбирать необходимое железо для подобных сервисов хотя бы для одного сервера. В работе столкнулся с задачей полного развертывания высоконагруженного приложения, с необходимости подбора железа (процессор, оперативная) для виртуальных машин.
Привет! Спасибо за редкий контент. Еще добавить бы оркестратор контейнеров. На моменте масштабирования Processing Video Server не понятно за счет чего будет достигаться партиционирование. Наверное имелось ввиду партиции кафки и множество консюмеров Processing Video Server (Не про БД партиции:) )Тут как раз скелинг подов от kubernetes зайдет) Ждем новых видео!
>>Проектирование выполняется на основе моего личного опыта Ты бы рассказал о своем личном опыте, где ты проектировал (и по этому проекту был запущен сервис) нечто, приближающееся по масштабу к ютубчику.. А то както очень похоже как школьник из бочки решил подводную лодку или ракету сделать..
Материалы видео носят больше академический характер Может сложиться некорректное ожидание - обновил описание видео, спасибо за уточнение На данный момент у меня опыт коммерческой разработки в веб 5 лет, общий в разработке ~9 лет, ютубчик пока не запускал
Мне кажется Кафка здесь не походит: Мы упремся в то что количество воркеров == кол-во партиций. А администрирование сотни партиций в Кафке плохо устроено Ну или делать разные топики в Кафке, но тогда и расходы на поддержание кода инфраструктуры возрастают. Лучше использовать само-писано-украденную очередь поверх любой key value distributed db. Типо scylla
Здорово, очень приятный контент, планируется ли что-то более базовое по архитектуре? О его подходах в реализации на практике? А содержательно очень, хотелось бы больше примеров и подобного контента, подписался на Вас в ТГ и в ютубе.
Расскажи в следующем видео про Twitch. И мб было бы интересно если бы звучала информация, о том какой мощности под это всё нужны выделенные машины, сколько и примерные затраты на поддержку данной архитектуры условно в мес/год. А так видос бомба)
@@RisenCode а какие вам нужны аргументы, если вы думаете, что можно сделать ютуб взяв хромую монгу и одну кафку ;) как бы архитекторы и получают деньги за то, что знают какую базу можно использовать, а какую нет (въедливо изучая и тестируя разные продукты вместо того, чтобы закрывать тикеты), а обычный разраб возьмут монгу, потому что лет 10 назад было модно и ему главное что nosql.
Видос пришёл в рекомендациях. Достойно! Но не хватает части про архитектурно-грамотную социальную составляющую/сообщество - как хранилище видосов таки сделали рутубу (интерфейс их мы щас не пинаем уж...), но вот в большинстве своём храждане остаются на уютном ютубчике и это даже при наличии наикошернейшего плейера на "одноглазсиках" 🤪🤪 Держу палцы крестиком за продолжение!
Уже после слов про запись на 60РПС могу смело говорить о фейле данной архитектуры. ИБо термин РПС применим к быстроработающим запросам, а не загрузке контента на гигабайты. Видос 1 грузиться около 10-30мин + обработка еще гдето столько же. А тут у нас это все равно 1рпс) Так не работает. Для загрузки выделяют отдельные физические каналы и меряется оно не рпс а пропускной способотность. Например 10ТБ/с.
@@Humanzerg все грузиться чанками это называются пакеты. О того как грузиться видос не меняется сам смысл. Во вторых грузя чанками чего именно вы достигаете и зачем? Нагрузку это не снимает + дает возможность что у всех клиентов видос веь не догрузиться. ибо достаточно сбоя в одном чанке и все. Например вы начали грузить новый чанк а места уже нету куда грузить и вы отпали по таймауту. и чем больше юзеров тем более вероятен такой исход.
@@MiiDosvid рпс имеется в виду в рамках хттп реквестов, а не пакетов. ф12 на ютубе откройте и посмотрите в нетворке как контент ютуб грузит, с загрузкой на сервер, думаю, то же самое. В видео есть ответ что мы этим решаем.
Интересно, хоть кто-то смог до какого-то адекватного уровня нагрузки затюнить коробочную версию шардированной монги? Чтобы например это было надежнее выгоднее и быстрее , чем скажем делать свою реализацию шардирования на постгре ?
CDN - суть кэш, причем распределенный. Мало того, в данном случае имеет огромное влияние локация. Данное рускоязычное видео, к примеру, вряд ли где-то кроме России и некоторых других экс-СССР стран будут смотреть. Т.е. в околороссийском сегменте CDN это видео будет к месту (при соответствующем количестве просмотров), а в северо- и южноамериканском оно ни к чему.
@@IlyaSilchenkov но это все очень сильно зависит от данных метрики, фловов потребления контента, гео шардинга и прочего. это мега сложная тема на нее можно весь год в видео выделить. сделать на коленке такое не выйдет
Всего навсего 750000 каналов. А давайте посчитаем ... толщину! Возьмём для прокладки внутри здания кабель ИКВ-Т2, можно и буржуйский аналог, не суть, диаметр его 6 миллиметра то есть 0,006 метра, соответственно площадь его сечения 0,000028 метра квадратных, нам нужно 750000 таких верёвок, их суммарная площадь составит 21 метр квадратный. Но это не совсем правильнй расчёт, потому как верёвка круглая, а не квадратная, значит между верёвками будут пустоты. Считаем чуть более правильно, как корень квадратный из 750000 умноженный на 0,006 метра и всё это в степени 2 и получаем: 27 метров квадратных. Но и это не правильный расчёт, потому как мы же не будем класить на вершину вершину и тут для расчёта нам нужно обратиться к упаковкам кругов ("Circle packing in a square") а это уже совсем другая история, которую в максимальную длину комментария не уложить :)
Объяснение выбора между tcp и udp вообще не в тему. Какой-то бред сказан, а потом "поэтому используем tcp". Как ты вообще udp собрался в браузере использовать, с этого надо начинать
слишком поверхностно и очевидно. а тот факт, что автор разбил файлы на кусочки, выдает в нем ллошка (поди посмотрел в две тулах браузера, что запрашивается по кускам и сделал невереные выводы). вопервых, разбивать файлы чтоб получить рандомный доступ к видео потоку не надо - сам формат мпег дает такую возможность - для этого достаточно знать метаданные видео, во вторых если ты разобьешь файл на куски - ты нагнешь файловою систему, любая файловая система начнет загинаться когда в одном каталоге 10к файлов и более - а теперь подумай как у тебя дерево каталогов с таким подходом будет выглядеть.
Спасибо - меня этот вопрос держал на всем протяжении просмотра видео. Такие обрезки я видел на сайтах фильмов, в которых 1х бэт рекламмируется, видимо для защиты от прямого скачивания)
с чего вы решили что файловой системе есть какая-то разница от того сколько у вас там файлов в каталоге? вот только что проверил для ext4 в виртуалке, ls отрабатывает пропорционально количеству файлов (взял 10 к и 1 млн для сравнения), а не квадратично или еще как. чтение случайного файла похоже что совпадает (а чего ему не совпадать то?). понятие каталога полностью абстрактно, это запись в какой-то структуре и любая работа с файлами и папками - это обращение к этой структуре, сложность чтения из нее наверняка будет n*logn от всех файлов на диске, а не конкретной папки. если вы не собираетесь делать файлы по 4кб и заполнять ими все 20 тб своего диска, то об этом можно не беспокоиться. Даже 4кб для диска в 4тб еще ок - это рекомендованное значение блока при форматировании, а законы и математика там примерно такие же.
@@yuryburkouski а с чего ей не должно быть разницы? "запись в какойто структуре" - каждая "какаята" структура имеет свои ограничения и плохие сценарии использования. овердохера файлов в каталоге это всегда плохой сценарий, в ext3 было бинарное дерево под капотом (так же как щас например у btrfs) - несколько тысяч ставит раком на раз, в ext4 - htree, для имен файлов в каталогах используется хеш таблица. все хорошо и приколько когда она закеширована в память - только вот создание файлов в таком кталаоге, а так же откртыие файла при первом (список инодов не грузился, либо был вытеснен из кеша) обращении будет иметь непредсказуемую задрежку (можеш сам эксперименты попроводить, а заодно сравнить полученые значениея с кейсом когда эти файлы разложены по подкаталогам). а теперь посмотри на этот факт с т.з. сервиса, который должен гарантировать +/- одинаковое время отклика на каждый запрос.
Что-то я не понял почему почему нужер 4.5 миллиона сетевых каналов по 10ГБ/с, чтобы хватило пропустить 6ПБ/c. Используя простую арифметику получаем 4.5 * 10^6 * 10 = 45 * 10^6 = 45ПБ/c, что в 7.5 раз больше, чем нужно. Выглядит так, что нужно 600 тыс сетевых каналов по 10ГБ/с.
