Проектируем YouTube - Введение в System Design
ฝัง
- เผยแพร่เมื่อ 19 มิ.ย. 2024
- Обзор и применение методик System Design Видеохостинга наподобие TH-cam
Таймкоды:
00:00 ➝ Интро
00:13 ➝ Введение
00:45 ➝ Функциональные требования
01:06 ➝ Нефункциональные требования
02:10 ➝ Загрузка видео: верхний уровень
03:13 ➝ Просмотр видео: верхний уровень
04:55 ➝ Загрузка видео: подробное проектирование
09:27 ➝ Просмотр видео: подробное проектирование
12:24 ➝ Заключение
В данном выпуске выполняется проектирование видеохостинга на основе обширных нефункциональных требований из открытых источников:
- MAU 2.5 млрд
- DAU 50 млн
- 5 млн новых видео в день
- 5 млрд просмотров видео в день
Проектирование основано на личном опыте, включая изучение технической литературы
Ваши ценные комментарии помогают сделать контент еще более интересным и полезным!
Не бывает правильной архитектуры, буду рад обратной связи
Ссылка на телеграм-канал: t.me/system_design_notes
Поддержать канал:
Яндекс Деньги: yoomoney.ru/to/410015646575581
#systemdesign #highload
PS: о сегментах видео
Видео представляет собой цельный файл, сегменты видео можно получить с помощью метаданных файла
Такую работу поддерживают, например, HLS и MP4
Круто, про архитектуру мало таких видосов!
Именно таких разборов и видосов не хватает на ютубе, а то сплошные питонисты с тестировщиками. Отлично, что субъективно, это даже интереснее кто как делает и какие подходы применяет. Наконец-то в рекомендациях 🎉
щось цих "архітекторів" дохера розвелось
Искать надо уметь
@@hsqlk ну не все ищут, а тут рекомендацию ютуб подкинул.
Именно таких разборов, с такой же степенью непрофессионализма, полно на ютубе
Про балансировку на клиенте - есть решение лучше с балансированием на уровне dns сервера. Так url один, но его можно распределить на несколько ip адресов.
Интересная тема. С кайфом посмотрел.
Спасибо за видео. Подписался)
очень интересное видео!
Очень интересно! Спасибо!
Интересно
Класс
Мне понравилось. Было и интересно, и полезно. Спасибо за труды!
Интересно было бы послушать про всякие архитектурные штуки по типу гейтвеев и подобной архитектуры. Пришёл из рекомендаций кстати
Интересный ролик
Мне кажется Кафка здесь не походит:
Мы упремся в то что количество воркеров == кол-во партиций. А администрирование сотни партиций в Кафке плохо устроено
Ну или делать разные топики в Кафке, но тогда и расходы на поддержание кода инфраструктуры возрастают.
Лучше использовать само-писано-украденную очередь поверх любой key value distributed db. Типо scylla
Спасибо за видео, полезно!
Было бы круто ещё показать на примере как подбирать необходимое железо для подобных сервисов хотя бы для одного сервера. В работе столкнулся с задачей полного развертывания высоконагруженного приложения, с необходимости подбора железа (процессор, оперативная) для виртуальных машин.
Спасибо за контент!
Привет! Спасибо за редкий контент. Еще добавить бы оркестратор контейнеров. На моменте масштабирования Processing Video Server не понятно за счет чего будет достигаться партиционирование. Наверное имелось ввиду партиции кафки и множество консюмеров Processing Video Server (Не про БД партиции:) )Тут как раз скелинг подов от kubernetes зайдет) Ждем новых видео!
топовый контент
это очень круто, жди прилива аудитории, подобного мало
Я восхищён, и уверен многие тоже
Подумай над тем, чтобы прикрепить реквизиты куда можно было бы задонатить
Ну с таким контентом набрать первых 10 тысяч подписчиков не составит труда)
Здорово, очень приятный контент, планируется ли что-то более базовое по архитектуре? О его подходах в реализации на практике? А содержательно очень, хотелось бы больше примеров и подобного контента, подписался на Вас в ТГ и в ютубе.
Крутой видос!
Само видео в кафку загружается или только его идентификатор во временном хранилище?
Конечно только id
Расскажи в следующем видео про Twitch. И мб было бы интересно если бы звучала информация, о том какой мощности под это всё нужны выделенные машины, сколько и примерные затраты на поддержку данной архитектуры условно в мес/год. А так видос бомба)
Идея огонь!
Советую разделять гигабайты и гигабиты, как ГБ и Гбит соответственно.
ГБ и Гб в видео
@@SofronovMaxim Есть:
GB/ГБ (Gb/Гб) - Гигабайт
Gbit/Гбит - Гигабит
GiB/ГиБ - Гибибайт
и по аналогии с другими основаниями
Видео хорошее. Кстати, в рекомендациях :)
Спасибо за видео, можешь объяснить как пропускную способность расcчитал?
Интересно, хоть кто-то смог до какого-то адекватного уровня нагрузки затюнить коробочную версию шардированной монги?
Чтобы например это было надежнее выгоднее и быстрее , чем скажем делать свою реализацию шардирования на постгре ?
Респект!
Отличная работа, спасибо за видео
Отличное видео! Спасибо. Пожалуйста, не останавливайся)
спасибо за шикарный контент!
Такой проект и без кеширования хотя бы запросов?
Видос пришёл в рекомендациях. Достойно! Но не хватает части про архитектурно-грамотную социальную составляющую/сообщество - как хранилище видосов таки сделали рутубу (интерфейс их мы щас не пинаем уж...), но вот в большинстве своём храждане остаются на уютном ютубчике и это даже при наличии наикошернейшего плейера на "одноглазсиках" 🤪🤪
Держу палцы крестиком за продолжение!
Ты не по адресу с такими комментариями.
@@d0lka397 развернёте свою мысль или это был чисто "вброс мимокрокодила"?))
Все выглядит правильно, есть только вопрос по выбору message broker, на мой взгляд Kafka тут не оправдана, какие доводы в её пользу?
пропускная способность большая
кролик не факт что выдержит
Отличное видео, спасибо большое. Подписался, буду ждать новых роликов.
Всегда было интересно какую максимальную нагрузку выдержат сервера TH-cam
100Пбт/с или больше 🔥
Любую, серверов же много
@@ivanjermakov но они же не безграничны
идея для видео гениальна
А куда донатить для поддержки канала?(((
Ух тыыы, давай ютуб мути, код
!
CDN - суть кэш, причем распределенный. Мало того, в данном случае имеет огромное влияние локация. Данное рускоязычное видео, к примеру, вряд ли где-то кроме России и некоторых других экс-СССР стран будут смотреть. Т.е. в околороссийском сегменте CDN это видео будет к месту (при соответствующем количестве просмотров), а в северо- и южноамериканском оно ни к чему.
>>Проектирование выполняется на основе моего личного опыта
Ты бы рассказал о своем личном опыте, где ты проектировал (и по этому проекту был запущен сервис) нечто, приближающееся по масштабу к ютубчику.. А то както очень похоже как школьник из бочки решил подводную лодку или ракету сделать..
Материалы видео носят больше академический характер
Может сложиться некорректное ожидание - обновил описание видео, спасибо за уточнение
На данный момент у меня опыт коммерческой разработки в веб 5 лет, общий в разработке ~9 лет, ютубчик пока не запускал
S3 не подойдет) Открываем доки по нему и смотрим ограничения которые и близко не сопоставимы.
Подскажешь куда копать тогда?
@@IlyaSilchenkov p2p, torrent protocol, chunk storages, udp streaming
@@IlyaSilchenkov но это все очень сильно зависит от данных метрики, фловов потребления контента, гео шардинга и прочего. это мега сложная тема на нее можно весь год в видео выделить.
сделать на коленке такое не выйдет
Уже после слов про запись на 60РПС могу смело говорить о фейле данной архитектуры. ИБо термин РПС применим к быстроработающим запросам, а не загрузке контента на гигабайты. Видос 1 грузиться около 10-30мин + обработка еще гдето столько же. А тут у нас это все равно 1рпс) Так не работает.
Для загрузки выделяют отдельные физические каналы и меряется оно не рпс а пропускной способотность. Например 10ТБ/с.
С чего вы взяли, что видос грузится не чанками?
@@Humanzerg все грузиться чанками это называются пакеты.
О того как грузиться видос не меняется сам смысл.
Во вторых грузя чанками чего именно вы достигаете и зачем? Нагрузку это не снимает + дает возможность что у всех клиентов видос веь не догрузиться. ибо достаточно сбоя в одном чанке и все. Например вы начали грузить новый чанк а места уже нету куда грузить и вы отпали по таймауту. и чем больше юзеров тем более вероятен такой исход.
@@Humanzerg Сначала идет проблема а потом ее решение. какую проблему решаете вы этим?
@@Humanzerg я вот сча прям возьму и гляну как он грузит)
@@MiiDosvid рпс имеется в виду в рамках хттп реквестов, а не пакетов. ф12 на ютубе откройте и посмотрите в нетворке как контент ютуб грузит, с загрузкой на сервер, думаю, то же самое.
В видео есть ответ что мы этим решаем.
Посмотрел видео - почитал комменты - примерно 7-8 класники проектируют инфраструктуру ютуба :)
Конечно же аргументов не будет :)
@@RisenCode а что ? 8-9ти классики?
Напоминает как бы сказать - "отсюда заходит Вася со снайперской - а тут юрок с пулеметом - и тратататата"
@@aeforeve1234 понятно, клоун линуксоид)
@@RisenCode а какие вам нужны аргументы, если вы думаете, что можно сделать ютуб взяв хромую монгу и одну кафку ;) как бы архитекторы и получают деньги за то, что знают какую базу можно использовать, а какую нет (въедливо изучая и тестируя разные продукты вместо того, чтобы закрывать тикеты), а обычный разраб возьмут монгу, потому что лет 10 назад было модно и ему главное что nosql.
Если добавишь конкретики будет ценно для всех 👍
Всего навсего 750000 каналов. А давайте посчитаем ... толщину!
Возьмём для прокладки внутри здания кабель ИКВ-Т2, можно и буржуйский аналог, не суть, диаметр его 6 миллиметра то есть 0,006 метра, соответственно площадь его сечения 0,000028 метра квадратных, нам нужно 750000 таких верёвок, их суммарная площадь составит 21 метр квадратный.
Но это не совсем правильнй расчёт, потому как верёвка круглая, а не квадратная, значит между верёвками будут пустоты.
Считаем чуть более правильно, как корень квадратный из 750000 умноженный на 0,006 метра и всё это в степени 2 и получаем: 27 метров квадратных.
Но и это не правильный расчёт, потому как мы же не будем класить на вершину вершину и тут для расчёта нам нужно обратиться к упаковкам кругов ("Circle packing in a square") а это уже совсем другая история, которую в максимальную длину комментария не уложить :)
в год же 30, не?
Видео очень познавательное, спасибо за такой контент. Кстати, для небольшого разбавления неплохо было бы добавить ненавязчивую музыку на фон )
Вот этого не надо! И так интересно
Ни какой музыки не надо!
слишком поверхностно и очевидно. а тот факт, что автор разбил файлы на кусочки, выдает в нем ллошка (поди посмотрел в две тулах браузера, что запрашивается по кускам и сделал невереные выводы). вопервых, разбивать файлы чтоб получить рандомный доступ к видео потоку не надо - сам формат мпег дает такую возможность - для этого достаточно знать метаданные видео, во вторых если ты разобьешь файл на куски - ты нагнешь файловою систему, любая файловая система начнет загинаться когда в одном каталоге 10к файлов и более - а теперь подумай как у тебя дерево каталогов с таким подходом будет выглядеть.
Спасибо - меня этот вопрос держал на всем протяжении просмотра видео. Такие обрезки я видел на сайтах фильмов, в которых 1х бэт рекламмируется, видимо для защиты от прямого скачивания)
@@ilgizilgiz с ютуба кстати можно без проблем видео скачать целиком по прямой ссылке. в сети полно сервисов, которые эту ссылку сформируют.
Спасибо большое за уточнение
Этот важный тезис был упущен в контенте
Уточнение сохранено пока в комментарии
с чего вы решили что файловой системе есть какая-то разница от того сколько у вас там файлов в каталоге? вот только что проверил для ext4 в виртуалке, ls отрабатывает пропорционально количеству файлов (взял 10 к и 1 млн для сравнения), а не квадратично или еще как. чтение случайного файла похоже что совпадает (а чего ему не совпадать то?). понятие каталога полностью абстрактно, это запись в какой-то структуре и любая работа с файлами и папками - это обращение к этой структуре, сложность чтения из нее наверняка будет n*logn от всех файлов на диске, а не конкретной папки. если вы не собираетесь делать файлы по 4кб и заполнять ими все 20 тб своего диска, то об этом можно не беспокоиться. Даже 4кб для диска в 4тб еще ок - это рекомендованное значение блока при форматировании, а законы и математика там примерно такие же.
@@user-md2fk3jj1e а с чего ей не должно быть разницы? "запись в какойто структуре" - каждая "какаята" структура имеет свои ограничения и плохие сценарии использования. овердохера файлов в каталоге это всегда плохой сценарий, в ext3 было бинарное дерево под капотом (так же как щас например у btrfs) - несколько тысяч ставит раком на раз, в ext4 - htree, для имен файлов в каталогах используется хеш таблица. все хорошо и приколько когда она закеширована в память - только вот создание файлов в таком кталаоге, а так же откртыие файла при первом (список инодов не грузился, либо был вытеснен из кеша) обращении будет иметь непредсказуемую задрежку (можеш сам эксперименты попроводить, а заодно сравнить полученые значениея с кейсом когда эти файлы разложены по подкаталогам). а теперь посмотри на этот факт с т.з. сервиса, который должен гарантировать +/- одинаковое время отклика на каждый запрос.
Что-то я не понял почему почему нужер 4.5 миллиона сетевых каналов по 10ГБ/с, чтобы хватило пропустить 6ПБ/c. Используя простую арифметику получаем 4.5 * 10^6 * 10 = 45 * 10^6 = 45ПБ/c, что в 7.5 раз больше, чем нужно. Выглядит так, что нужно 600 тыс сетевых каналов по 10ГБ/с.
В видео используются Гб (Гбит)
@@system-design-notes тогда лучше пишите Гбит, это очевидное понятие, а Гб вообще не встречал, как сокращение Гигабит
Монго? Серьезно ? Это тормозное решение для пит проекта пойдет, ты через сутки положишь хост. Лучше коучбаз брать тогда.
афтер, ты архитектор и об етом канал?
Разработчик ПО, проектирование архитектуры присутствует в практике
Канал про System Design, актуальная информация поддерживается в описании канала
Объяснение выбора между tcp и udp вообще не в тему. Какой-то бред сказан, а потом "поэтому используем tcp". Как ты вообще udp собрался в браузере использовать, с этого надо начинать
HTTP/3 работает поверх UDP, а вообще да, совсем не в тему.