PS: о сегментах видео Видео представляет собой цельный файл, сегменты видео можно получить с помощью метаданных файла Такую работу поддерживают, например, HLS и MP4

Круто, про архитектуру мало таких видосов!

Именно таких разборов и видосов не хватает на ютубе, а то сплошные питонисты с тестировщиками. Отлично, что субъективно, это даже интереснее кто как делает и какие подходы применяет. Наконец-то в рекомендациях 🎉

@arwichok_

Ай бұрын

щось цих "архітекторів" дохера розвелось

@hsqlk

Ай бұрын

Искать надо уметь

@slashfast

Ай бұрын

​@@hsqlk ну не все ищут, а тут рекомендацию ютуб подкинул.

@bluesdemon1

Ай бұрын

Именно таких разборов, с такой же степенью непрофессионализма, полно на ютубе

Про балансировку на клиенте - есть решение лучше с балансированием на уровне dns сервера. Так url один, но его можно распределить на несколько ip адресов.

Интересная тема. С кайфом посмотрел.

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

очень интересное видео!

Привет! Спасибо за редкий контент. Еще добавить бы оркестратор контейнеров. На моменте масштабирования Processing Video Server не понятно за счет чего будет достигаться партиционирование. Наверное имелось ввиду партиции кафки и множество консюмеров Processing Video Server (Не про БД партиции:) )Тут как раз скелинг подов от kubernetes зайдет) Ждем новых видео!

Спасибо за видео. Подписался)

Мне понравилось. Было и интересно, и полезно. Спасибо за труды!

Очень интересно! Спасибо!

Интересно было бы послушать про всякие архитектурные штуки по типу гейтвеев и подобной архитектуры. Пришёл из рекомендаций кстати

Здорово, очень приятный контент, планируется ли что-то более базовое по архитектуре? О его подходах в реализации на практике? А содержательно очень, хотелось бы больше примеров и подобного контента, подписался на Вас в ТГ и в ютубе.

Интересно

это очень круто, жди прилива аудитории, подобного мало

Ну с таким контентом набрать первых 10 тысяч подписчиков не составит труда)

Я восхищён, и уверен многие тоже Подумай над тем, чтобы прикрепить реквизиты куда можно было бы задонатить

Интересный ролик

Класс

Мне кажется Кафка здесь не походит: Мы упремся в то что количество воркеров == кол-во партиций. А администрирование сотни партиций в Кафке плохо устроено Ну или делать разные топики в Кафке, но тогда и расходы на поддержание кода инфраструктуры возрастают. Лучше использовать само-писано-украденную очередь поверх любой key value distributed db. Типо scylla

топовый контент

Спасибо за видео, можешь объяснить как пропускную способность расcчитал?

Расскажи в следующем видео про Twitch. И мб было бы интересно если бы звучала информация, о том какой мощности под это всё нужны выделенные машины, сколько и примерные затраты на поддержку данной архитектуры условно в мес/год. А так видос бомба)

Отличная работа, спасибо за видео

Спасибо за контент!

Отличное видео! Спасибо. Пожалуйста, не останавливайся)

Крутой видос! Само видео в кафку загружается или только его идентификатор во временном хранилище?

@user-28492b

Ай бұрын

Конечно только id

Такой проект и без кеширования хотя бы запросов?

Отличное видео, спасибо большое. Подписался, буду ждать новых роликов.

Видео хорошее. Кстати, в рекомендациях :)

Идея огонь! Советую разделять гигабайты и гигабиты, как ГБ и Гбит соответственно.

@SofronovMaxim

Ай бұрын

ГБ и Гб в видео

@slashfast

Ай бұрын

@@SofronovMaxim Есть: GB/ГБ (Gb/Гб) - Гигабайт Gbit/Гбит - Гигабит GiB/ГиБ - Гибибайт и по аналогии с другими основаниями

спасибо за шикарный контент!

Интересно, хоть кто-то смог до какого-то адекватного уровня нагрузки затюнить коробочную версию шардированной монги? Чтобы например это было надежнее выгоднее и быстрее , чем скажем делать свою реализацию шардирования на постгре ?

А куда донатить для поддержки канала?(((

Все выглядит правильно, есть только вопрос по выбору message broker, на мой взгляд Kafka тут не оправдана, какие доводы в её пользу?

@kitsunofflmao9980

Ай бұрын

пропускная способность большая кролик не факт что выдержит

Видос пришёл в рекомендациях. Достойно! Но не хватает части про архитектурно-грамотную социальную составляющую/сообщество - как хранилище видосов таки сделали рутубу (интерфейс их мы щас не пинаем уж...), но вот в большинстве своём храждане остаются на уютном ютубчике и это даже при наличии наикошернейшего плейера на "одноглазсиках" 🤪🤪 Держу палцы крестиком за продолжение!

@d0lka397

Ай бұрын

Ты не по адресу с такими комментариями.

@michaelsopunov

Ай бұрын

@@d0lka397 развернёте свою мысль или это был чисто "вброс мимокрокодила"?))

>>Проектирование выполняется на основе моего личного опыта Ты бы рассказал о своем личном опыте, где ты проектировал (и по этому проекту был запущен сервис) нечто, приближающееся по масштабу к ютубчику.. А то както очень похоже как школьник из бочки решил подводную лодку или ракету сделать..

@system-design-notes

Ай бұрын

Материалы видео носят больше академический характер Может сложиться некорректное ожидание - обновил описание видео, спасибо за уточнение На данный момент у меня опыт коммерческой разработки в веб 5 лет, общий в разработке ~9 лет, ютубчик пока не запускал

Всегда было интересно какую максимальную нагрузку выдержат сервера KZread 100Пбт/с или больше 🔥

@ivanjermakov

Ай бұрын

Любую, серверов же много

@AvitoB0T

Ай бұрын

@@ivanjermakov но они же не безграничны

Респект!

Ух тыыы, давай ютуб мути, код

идея для видео гениальна

!

CDN - суть кэш, причем распределенный. Мало того, в данном случае имеет огромное влияние локация. Данное рускоязычное видео, к примеру, вряд ли где-то кроме России и некоторых других экс-СССР стран будут смотреть. Т.е. в околороссийском сегменте CDN это видео будет к месту (при соответствующем количестве просмотров), а в северо- и южноамериканском оно ни к чему.

S3 не подойдет) Открываем доки по нему и смотрим ограничения которые и близко не сопоставимы.

@IlyaSilchenkov

Ай бұрын

Подскажешь куда копать тогда?

@MiiDosvid

Ай бұрын

@@IlyaSilchenkov p2p, torrent protocol, chunk storages, udp streaming

@MiiDosvid

Ай бұрын

@@IlyaSilchenkov но это все очень сильно зависит от данных метрики, фловов потребления контента, гео шардинга и прочего. это мега сложная тема на нее можно весь год в видео выделить. сделать на коленке такое не выйдет

Уже после слов про запись на 60РПС могу смело говорить о фейле данной архитектуры. ИБо термин РПС применим к быстроработающим запросам, а не загрузке контента на гигабайты. Видос 1 грузиться около 10-30мин + обработка еще гдето столько же. А тут у нас это все равно 1рпс) Так не работает. Для загрузки выделяют отдельные физические каналы и меряется оно не рпс а пропускной способотность. Например 10ТБ/с.

@Humanzerg

Ай бұрын

С чего вы взяли, что видос грузится не чанками?

@MiiDosvid

Ай бұрын

@@Humanzerg все грузиться чанками это называются пакеты. О того как грузиться видос не меняется сам смысл. Во вторых грузя чанками чего именно вы достигаете и зачем? Нагрузку это не снимает + дает возможность что у всех клиентов видос веь не догрузиться. ибо достаточно сбоя в одном чанке и все. Например вы начали грузить новый чанк а места уже нету куда грузить и вы отпали по таймауту. и чем больше юзеров тем более вероятен такой исход.

@MiiDosvid

Ай бұрын

@@Humanzerg Сначала идет проблема а потом ее решение. какую проблему решаете вы этим?

@MiiDosvid

Ай бұрын

@@Humanzerg я вот сча прям возьму и гляну как он грузит)

@Humanzerg

Ай бұрын

​@@MiiDosvid рпс имеется в виду в рамках хттп реквестов, а не пакетов. ф12 на ютубе откройте и посмотрите в нетворке как контент ютуб грузит, с загрузкой на сервер, думаю, то же самое. В видео есть ответ что мы этим решаем.

Видео очень познавательное, спасибо за такой контент. Кстати, для небольшого разбавления неплохо было бы добавить ненавязчивую музыку на фон )

@adilzhanuteniyazov7109

Ай бұрын

Вот этого не надо! И так интересно

@edgull_tlt

Ай бұрын

Ни какой музыки не надо!

Всего навсего 750000 каналов. А давайте посчитаем ... толщину! Возьмём для прокладки внутри здания кабель ИКВ-Т2, можно и буржуйский аналог, не суть, диаметр его 6 миллиметра то есть 0,006 метра, соответственно площадь его сечения 0,000028 метра квадратных, нам нужно 750000 таких верёвок, их суммарная площадь составит 21 метр квадратный. Но это не совсем правильнй расчёт, потому как верёвка круглая, а не квадратная, значит между верёвками будут пустоты. Считаем чуть более правильно, как корень квадратный из 750000 умноженный на 0,006 метра и всё это в степени 2 и получаем: 27 метров квадратных. Но и это не правильный расчёт, потому как мы же не будем класить на вершину вершину и тут для расчёта нам нужно обратиться к упаковкам кругов ("Circle packing in a square") а это уже совсем другая история, которую в максимальную длину комментария не уложить :)

Посмотрел видео - почитал комменты - примерно 7-8 класники проектируют инфраструктуру ютуба :)

@RisenCode

Ай бұрын

Конечно же аргументов не будет :)

@aeforeve1234

Ай бұрын

@@RisenCode а что ? 8-9ти классики? Напоминает как бы сказать - "отсюда заходит Вася со снайперской - а тут юрок с пулеметом - и тратататата"

@RisenCode

Ай бұрын

@@aeforeve1234 понятно, клоун линуксоид)

@user-md2fk3jj1e

Ай бұрын

@@RisenCode а какие вам нужны аргументы, если вы думаете, что можно сделать ютуб взяв хромую монгу и одну кафку ;) как бы архитекторы и получают деньги за то, что знают какую базу можно использовать, а какую нет (въедливо изучая и тестируя разные продукты вместо того, чтобы закрывать тикеты), а обычный разраб возьмут монгу, потому что лет 10 назад было модно и ему главное что nosql.

@IlyaSilchenkov

Ай бұрын

Если добавишь конкретики будет ценно для всех 👍

в год же 30, не?

слишком поверхностно и очевидно. а тот факт, что автор разбил файлы на кусочки, выдает в нем ллошка (поди посмотрел в две тулах браузера, что запрашивается по кускам и сделал невереные выводы). вопервых, разбивать файлы чтоб получить рандомный доступ к видео потоку не надо - сам формат мпег дает такую возможность - для этого достаточно знать метаданные видео, во вторых если ты разобьешь файл на куски - ты нагнешь файловою систему, любая файловая система начнет загинаться когда в одном каталоге 10к файлов и более - а теперь подумай как у тебя дерево каталогов с таким подходом будет выглядеть.

@ilgizilgiz

Ай бұрын

Спасибо - меня этот вопрос держал на всем протяжении просмотра видео. Такие обрезки я видел на сайтах фильмов, в которых 1х бэт рекламмируется, видимо для защиты от прямого скачивания)

@mihax56

Ай бұрын

@@ilgizilgiz с ютуба кстати можно без проблем видео скачать целиком по прямой ссылке. в сети полно сервисов, которые эту ссылку сформируют.

@system-design-notes

Ай бұрын

Спасибо большое за уточнение Этот важный тезис был упущен в контенте Уточнение сохранено пока в комментарии

@user-md2fk3jj1e

Ай бұрын

с чего вы решили что файловой системе есть какая-то разница от того сколько у вас там файлов в каталоге? вот только что проверил для ext4 в виртуалке, ls отрабатывает пропорционально количеству файлов (взял 10 к и 1 млн для сравнения), а не квадратично или еще как. чтение случайного файла похоже что совпадает (а чего ему не совпадать то?). понятие каталога полностью абстрактно, это запись в какой-то структуре и любая работа с файлами и папками - это обращение к этой структуре, сложность чтения из нее наверняка будет n*logn от всех файлов на диске, а не конкретной папки. если вы не собираетесь делать файлы по 4кб и заполнять ими все 20 тб своего диска, то об этом можно не беспокоиться. Даже 4кб для диска в 4тб еще ок - это рекомендованное значение блока при форматировании, а законы и математика там примерно такие же.

@mihax56

Ай бұрын

@@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

Ай бұрын

В видео используются Гб (Гбит)

@slashfast

Ай бұрын

@@system-design-notes тогда лучше пишите Гбит, это очевидное понятие, а Гб вообще не встречал, как сокращение Гигабит

афтер, ты архитектор и об етом канал?

@system-design-notes

Ай бұрын

Разработчик ПО, проектирование архитектуры присутствует в практике Канал про System Design, актуальная информация поддерживается в описании канала

Монго? Серьезно ? Это тормозное решение для пит проекта пойдет, ты через сутки положишь хост. Лучше коучбаз брать тогда.

Объяснение выбора между tcp и udp вообще не в тему. Какой-то бред сказан, а потом "поэтому используем tcp". Как ты вообще udp собрался в браузере использовать, с этого надо начинать

@ivanjermakov

Ай бұрын

HTTP/3 работает поверх UDP, а вообще да, совсем не в тему.