Очень круто, харизматично и доступно) Удобный формат, когда нужно просто иметь представление о технологии. И лучше получить это представление от человека, который работал с данными технологиями, нежели пытаться составить самому, тратя много времени.
Великолепное видео. Автор выделил основные моменты всех систем так что можно сразу понять что это за технология, а дальше просто углубляться в мануалы. Огромное спасибо!
Все и правда понятно! Год назад, как только заходил в сферу айти ничего не понимал, а сейчас сталкиваюсь с тестированием на проекте, где два приложения обмениваются сообщениями с помощью брокера (RabbitMQ) и нужно было протестировать в web-интерфейсе корректный роутинг, payload и header, теперь стало все понятно и корректно закрыл задачу =) Благодарю!
Спасибо за отклик) Более того, по ним можно строить запросы :) В скором времени по JSONB отдельно можно рассказать, так как будет опыт применения в production.
Спасибо за ролик очень познавательно и интересно, но только на сколько я помню, Kafka позволяет одному консьюмеру читать данные с разных партиций и офсет не принадлежит определенной партиции, каждый офсет определяется для отдельной консьюмер группы
Хорошая подача материала, немного не хватает описания примеров использования данных сервисов, типа вот это збс будет в такой задаче и тд. Пс. Лайк и подписка
Есть такие как я которые заходят каждые три месяца чтобы вспомнить что нибудь про брокеры, из за того что вообще по работе не связанны с ними ,но хотят хоть что то о них знать))) Такладчик ты супер ))
6:19 плюет на routing key - верно, плюет на binding - тут оговорка, как раз то не плюет потому что именно binding определяет в какие очереди положить. Во все, которые прилинкованы к обменнику.
На 12:10 сказано что в Кафке одна партиция один консьюмер. В том смысле в котором имеет в виду автор это не так. В Кафке у топика может быть множество консьюмер групп, что по-сути и означает множество консьюмеров на одном топике, каждый из которых со своим офсетом
Вопрос по постгресу и его возможности использовать json атрибуты. Вот у меня есть таблица неких сущностей, которые хочется видеть в одном списке, но этих сущностей очень большое кол-во категорий со своими уникальными полями. Например, пусть будут товары. Мы продаём видеокарты и мониторы. У них совершенно разные параметры. Искать и сортировать по ним не обязательно, важно их только читать и редактировать. Категории постоянно добавляются новые, товары нельзя перемещать из одной категории в другую, у них немного отличаются интерфейсы. К тому же, бывают уникальные товары, которые существуют в единичном экземпляре для отдельной категории. Например, вертолёт. Вот он есть только у одного юзера и всё. Городить отдельные таблицы под каждую категорию не очень хочется. Джойнить их потом... фу, очень сложно. Я уже отчаялся и думаю использовать монгу под это дело. Но заводить монгу для одной-единственной таблицы как-то не хочется тоже, странновато. А вот json возможно выход. Типа назвать поле, скажем, category_attrs и складывать туда уникальные поля? 🤨
Если вам нет необходимости сортировать и фильтровать продукты (назовем их так) по этим уникальным полям, то хранить их можно как вам заблагорассудится (да хоть как текст через запятую в одном текстовом поле), так как работу по сериализации / десериализации данных можно переложить на ваше приложение. Если же вам необходимо фильтровать / сортировать данные то варианта сейчас по-сути два (если оставаться в рамках PostgreSQL): 1. EAV (ознакомьтесь с этим методом поподробнее) 2. JSONB - как мы и упоминали в видео, это мощный инструмент, который позволяет строить не просто запросы с применением данных из JSON-поля, но даже формировать по ним индексы, что существенно скажется на производительности запроса. Лоб в лоб оба метода мы не сравнивали, но применяем оба в работе над своими проектами.
В целом познавательно, но про Kafka что-то совсем поверхностно рассказано. Соотношение Consumer и Partition 1:1 это, конечно, правда. Но только в рамках одной ConsumerGroup! Ничто не мешает подключить несколько групп Consumer'ов к одному топику. И это как раз классная фишка Kafka - гранулярность может быть настроена очень тонко. Интересно также отметить, что Kafka гарантирует направление сообщений с одним и тем же ключом в конкретный Partition, чем самым гарантируется очередность (если она нужна)
Вопрос. Я задеплоил мемкеш на кубернетес кластер в aws. Он ранится в неймспейсе мемкеш. Под ранится также. И в кластере ранятся апликейшны. Вопрос как их связать аппликейшн и мемкеш под чтоб он оттуда брал информацию перед ДБ. ДБ у меня постгрес так же на aws. Нужно связать бакенды.
Подскажите - как при использовании Редиса для Кеша использовать горизонтальное масштабирования - если можешь пойти на сервер где нет твоих данных сессий?
Господа, а подскажите, большие ли будут накладные расходы если использовать redis, rabbit или kafka для общения между различными частями монолит приложения? Например если я хочу внутри приложения сделать сервисы которые должны взаимодействовать друг с другом только посредством чтения и генерации событий через шину сообщений.
Накладных расходов особо не будет - вопрос лишь целесообразности. Если вам это действительно нужно - используйте на здоровье. А монолит там у вас или мэш из микросервисов - не так уж важно)
03:00 - Что значит "RabbitMQ сам дёргает получателя?" Получатель не как в redis, в желаемый им момент НЕ может обратиться к сервису и по ключу и данные получить? Надо держать его в режиме слушания постоянно? А если слушатель занят? RabbitMq дождётся, когда тот освободится и снова пошлёт?
на сколько я понимаю в кафеке оффсет не у партиции, а у партиции и консъюмер группы, а консъюмер групп может быть несколько, и они могут параллельно по разному читать партиции, внутри консъюмер группы да, партиций должно хватать на каждого консъюмера в консъюмер группе
Крутецкий доклад, хорошо и быстро прошёлся по технологиям, удобно выбирать Я бы ещё Cassandra добавил, ну и немножко Camel, хоть это и несколько другого плана вещь, но тоже для обмена данными
Биндинг обменников и очередей в RabbitMQ - это не всегда строка как заявлено. Есть еще тип обменника Consistent-Hash, который вообще не рассмотрен, у него как раз биндинг - число.
0:40 RabbitMQ
9:34 Apache Kafka
15:10 Redis
19:30 Memcached
21:19 NuxtJS
25:55 MongoDB
30:33 PostgreSQL
Спасибо, в закреп :)
Eeeeeeeeeeeeee eeeeee eeeeeeetteeeeeee eeeeeee
Очень смешно получилось когда докладчик постиг дзен и стал невидимым на 20:43 секунде 😂
Это новая технология! :)
Закэшировался)))
Немного испугался
особенно смешно то, что он в этот момент как раз говорил про время жизни объекта))
@@user-np3bv8bw1o garbage collector в действии)
Классно, что редис работает пиздец как быстро) спасибо за видео
Докладчик заработал мою подписку на этот канал. Красавчик!
Стараемся :)
Аналогично
А я свою подписку не считаю чем то что можно заслужить, просто дикое спасибо за техничность,наглядность и понятность!
+
Спасибо докладчику, стояла задача понять отличие RabbitMQ от Kafka - это лучшее русскоязычное видео, поверьте.
Cпасибо :) Стараемся для вас ^_^
Так и есть! Согласен с комментом - тоже считаю одним из лучшх обзорных видео!
Очень круто, харизматично и доступно) Удобный формат, когда нужно просто иметь представление о технологии. И лучше получить это представление от человека, который работал с данными технологиями, нежели пытаться составить самому, тратя много времени.
Спасибо за доверие :)
Великолепное видео. Автор выделил основные моменты всех систем так что можно сразу понять что это за технология, а дальше просто углубляться в мануалы. Огромное спасибо!
Спасибо за отзыв, мы старались :)
Докладчик очень хорошо рассказывает и без воды! Прямо топ! Подписка однозначно!
Спасибо :)
Быстро, понятно, без лишней информации! Спасибо за видо!
Спасибо за отклик :)
Вот прямо классно рассказал! Нужно больше материала:))
Спасибо, стараемся ^_^
Все и правда понятно! Год назад, как только заходил в сферу айти ничего не понимал, а сейчас сталкиваюсь с тестированием на проекте, где два приложения обмениваются сообщениями с помощью брокера (RabbitMQ) и нужно было протестировать в web-интерфейсе корректный роутинг, payload и header, теперь стало все понятно и корректно закрыл задачу =) Благодарю!
Ура! Рады, что помогли :) Спасибо за отклик :)
Отличная подача материала, коротко и ясно! Спасибо!)
Спасибо, стараемся ^_^
Спасибо, для знакомства аналитикам и техническим менеджерам - отличный формат.
Спасибо, мы старались :)
Отлично, без пафоса и воды. Четко и понятно!
Спасибо, мы старались :)
Интересно было узнать про PostgreSQL. Спасибо!
Спасибо за отклик, мы старались ^_^
Отличный видос! Все кратко и понятно. Подписка!
Спасибо, мы старались! :)
Четко и по делу, без лишней воды. Вообще красава.
Спасибо, мы старались ^_^
Прямо выжимка ценного! Огромное спасибо за такие видео!
Спасибо, стараемся для вас :)
Это именно тот способ изложения инфы, который я хотел услышать!
Спасибо, мы старались :)
Отличное обзорное видео! Спасибо! Не знал, что в Postgres можно хранить массивы)
Спасибо за отклик) Более того, по ним можно строить запросы :) В скором времени по JSONB отдельно можно рассказать, так как будет опыт применения в production.
Крутой обзор! И канал топчик. Лайк, подписка!
Спасибо, мы старались ^_^
Чисто отдельная подписка за презентацию:)
Ай спасибо! :)
Считаю, что это лучшая реклама кофе якобс монарх. Большое спасибо, было очень интересно
Спасибо)
Классный обзор
Отличный докладчик👍🏻👍🏻👍🏻
Спасибо! :)
Спасибо, очень интересный доклад!
Благодарим вас :)
Ахеренный видос, спасибо
Стараемся ^_^
Отличнейший обзор, ничего лишнего!
Мы рады что вам понравилось :)
на пальцах и по делу!
Спасибо большое за это прекрасное видео! 👍
Спасибо, что смотрите)
Отличное видео! Большое спасибо!
Спасибо, мы старались
Лектор очень крут, спасибо за презентацию
Спасибо, стараемся для вас :)
Наконец кто-то объяснил человеческим языком как всё это работает, а не миллионом технических терминов. Спасибо!!
Спасибо, мы старались :)
"Отдай свежатину!". Сердечно благодарю за ролик)
Спасибо большое :)
Спасибо за доклад! В Nuxt при создании SPA понятно, что проблемы с SEO, но при SSR ведь не должно быть проблем
SSR и решает (как одну из) проблему с SEO :)
испугался, когда лектор сказал "истекло время жизни" и исчез
Спецэффекты которые мы заслужили ))))
Класс! Очень хороший обзор, спасибо!
Спасибо, мы старались :)
Господи, как найти работу, чтобы начальник был вот таким грамотным и весёлым дядькой?
Да это не так сложно как вам кажется)
А вообще можно самому стать вот таким "веселым дядькой")
Оч крутое видео. Спасибо)
Спасибо, что вы с нами)
Спасибо, спасибо, спасибо! Наконец-то я что-то знаю про брокеры сообщений
Всегда пожалуйста :)
Спасибо за ролик очень познавательно и интересно, но только на сколько я помню, Kafka позволяет одному консьюмеру читать данные с разных партиций и офсет не принадлежит определенной партиции, каждый офсет определяется для отдельной консьюмер группы
Спасибо что смотрите :) Да, ранее уже сообщали :)
очень крутой выпуск для понимания баз данных неожидал тут Nuxt увидеть) сам пишу на нем
Тут не только о базах, тут в целом по технологиям и решениям)
Нахватался бэкендерских словечек ))
Спасибо, подписался 🔥
Это только начало) Можете начинать собирать словарь)))
@@Rclass Буду выходить с этим словарем в курилку и обсуждать всякие редИсы со взрослыми дядями бэкендерами )
Хорошо получилось
Хорошая подача материала, немного не хватает описания примеров использования данных сервисов, типа вот это збс будет в такой задаче и тд.
Пс. Лайк и подписка
Интересная идея. Давайте я подумаю над этим. Возможно, сформирую список задач и расскажу например как бы я их решал :)
@@OkulovAnton вот это было бы супер!
Спасибо! Видео ТОП!!
Спасибо, мы старались :)
Класс, спасибо!)
Спасибо, мы старались :)
Вот смотрю я ролик и понимаю, не Монго бд...
Видео потрясающе, спасибо большое!
Спасибо, мы старались :)
Годный видос
Спасибо)
Бро, спасибо!
Вам спасибо за отклик :) Стараемся ^_^
спасибо, понятно и ёмко
Спасибо, мы старались!
Шикарно
Спасибо, мы старались!
Лови подписку брат!
Спасибо, мы старались :)
@@Rclass ну тогда ловите подписку братья)
Отлично, спасибо!
Спасибо, мы старались ^_^
Хороший обзор... Хотелось бы подробнее о RabbitMQ (В частности в Kubernetes, как все работает...)
Спасибо, мы старались! К сожалению, про работу в Kubernetes нам нечего рассказать (
Спасибо большое, все очень понятно объясняете. Отдельный лайк за оптимизм 🤣
Спасибо, мы старались :)
Есть такие как я которые заходят каждые три месяца чтобы вспомнить что нибудь про брокеры, из за того что вообще по работе не связанны с ними ,но хотят хоть что то о них знать))) Такладчик ты супер ))
День добрый! Не совсем поняли что вы имеете ввиду, но полностью с вами согласны)))
Безумно классный рассказчик)) прям хоть под пиво сиди смотри))
Спасибо, мы старались :)
Докладчик пиздатый чел)
Аееее, спасибо)
Здорово ведёте урок, спасибо!
Спасибо, мы старались ^_^
6:19 плюет на routing key - верно, плюет на binding - тут оговорка, как раз то не плюет потому что именно binding определяет в какие очереди положить. Во все, которые прилинкованы к обменнику.
Спасибо за уточнение :)
На 12:10 сказано что в Кафке одна партиция один консьюмер. В том смысле в котором имеет в виду автор это не так. В Кафке у топика может быть множество консьюмер групп, что по-сути и означает множество консьюмеров на одном топике, каждый из которых со своим офсетом
Отличное замечание, учту.
и оффсет это не байтовое смещение
Как ты научился исчезать? 2:41 Сделай следующее видео про это. Типо "невероятно, но факт..." ))))))
ой на 20:41
Отвлекли в середине доклада) пришлось пропасть)
+ respect
Thx for watching :)
Докладчик отличный
Спасибо, мы старались ^_^
Спасибо
Спасибо, мы старались :)
40 минут смотрел рекламу Якобс. Чет кофейку захотелось
Сработало! Там еще скотч сантехнический, лейбл только потерялся)
Блин..Тоже что то захотелось...А был в завяске от кофе ((
@@user-yo7mw6oj4p так давайте к нам на кофе? У нас кофемашина неплохая и кофе свежий, мы вам такой капучино сварим, ууух!
@@Rclass Classое предложение))))
@@Rclass )))))
вот это я понимаю экспресс обучение
Быстрее только список ссылок дать)
за Раббит и Редис спасибооу, также и за Монгу (за инфо, что в ней можно вставлять жабоскрипт-код).
Мы рады, что вам зашло :)
Класс...
Спасибо, мы старались ^_^
Истекло время жизни🤣🤣🤣
Так бывает)))
Вопрос по постгресу и его возможности использовать json атрибуты.
Вот у меня есть таблица неких сущностей, которые хочется видеть в одном списке, но этих сущностей очень большое кол-во категорий со своими уникальными полями.
Например, пусть будут товары. Мы продаём видеокарты и мониторы. У них совершенно разные параметры. Искать и сортировать по ним не обязательно, важно их только читать и редактировать. Категории постоянно добавляются новые, товары нельзя перемещать из одной категории в другую, у них немного отличаются интерфейсы. К тому же, бывают уникальные товары, которые существуют в единичном экземпляре для отдельной категории. Например, вертолёт. Вот он есть только у одного юзера и всё.
Городить отдельные таблицы под каждую категорию не очень хочется. Джойнить их потом... фу, очень сложно.
Я уже отчаялся и думаю использовать монгу под это дело. Но заводить монгу для одной-единственной таблицы как-то не хочется тоже, странновато.
А вот json возможно выход. Типа назвать поле, скажем, category_attrs и складывать туда уникальные поля? 🤨
Если вам нет необходимости сортировать и фильтровать продукты (назовем их так) по этим уникальным полям, то хранить их можно как вам заблагорассудится (да хоть как текст через запятую в одном текстовом поле), так как работу по сериализации / десериализации данных можно переложить на ваше приложение. Если же вам необходимо фильтровать / сортировать данные то варианта сейчас по-сути два (если оставаться в рамках PostgreSQL):
1. EAV (ознакомьтесь с этим методом поподробнее)
2. JSONB - как мы и упоминали в видео, это мощный инструмент, который позволяет строить не просто запросы с применением данных из JSON-поля, но даже формировать по ним индексы, что существенно скажется на производительности запроса.
Лоб в лоб оба метода мы не сравнивали, но применяем оба в работе над своими проектами.
@@Rclass почитаю подробнее, спасибо!)
истекло время жизни...жестоко, очень 20:39
12:27 - как связаны Partition и очередь?
Это одно и то же или нет?
Один Partition = 1 COnsumer. А что с очередями? 1 Queue = 1 Consumer????
А кофе у вас на полке растворимый или зерновой?
Откроем страшный секрет: там не кофе :) А кофе у нас в целом зерновой и очень неплохой, приходите при случае, мы вас угостим :)
в MongoDB есть aggregation framework, и аналог join можно сделать, в монго это называется Lookup
Да, действительно. Правда стоит помнить что с распределенными БД этот вариант не работает :)
Godlike
Thx)
В целом познавательно, но про Kafka что-то совсем поверхностно рассказано. Соотношение Consumer и Partition 1:1 это, конечно, правда. Но только в рамках одной ConsumerGroup! Ничто не мешает подключить несколько групп Consumer'ов к одному топику. И это как раз классная фишка Kafka - гранулярность может быть настроена очень тонко. Интересно также отметить, что Kafka гарантирует направление сообщений с одним и тем же ключом в конкретный Partition, чем самым гарантируется очередность (если она нужна)
Ага, отмечали уже в комментах) В целом надо было примерно прикинуть что это за зверь и чем принципиально от других брокеров отличается.
Вопрос. Я задеплоил мемкеш на кубернетес кластер в aws. Он ранится в неймспейсе мемкеш. Под ранится также. И в кластере ранятся апликейшны. Вопрос как их связать аппликейшн и мемкеш под чтоб он оттуда брал информацию перед ДБ. ДБ у меня постгрес так же на aws. Нужно связать бакенды.
Писать руками кеширование в мемкеш внутри приложения. Если всё правильно поняли.
@@Rclass я понял. Но я не разработчик, эти жава аппликейшны не я писал.
@@kazakman7772 тогда вряд ли что-нибудь получится(
Может всё-таки 1 партишн = 1 консьюмер группа? У нас вроде овер 50 консьюмеров читают из топиков с партиционированием 3
Да-да, всё так, поправили уже раньше :) Спасибо что смотрите :)
Подскажите - как при использовании Редиса для Кеша использовать горизонтальное масштабирования - если можешь пойти на сервер где нет твоих данных сессий?
Не очень понятно как связаны кеш и сессии?
@@Rclass извиняюсь, вопрос про сессии только
JSON = Головастик, ибо: J=Жаба , SON=сын, а сын жабы = головастик. ЧТД
Интересное мнение, запомним)
Господа, а подскажите, большие ли будут накладные расходы если использовать redis, rabbit или kafka для общения между различными частями монолит приложения? Например если я хочу внутри приложения сделать сервисы которые должны взаимодействовать друг с другом только посредством чтения и генерации событий через шину сообщений.
Накладных расходов особо не будет - вопрос лишь целесообразности. Если вам это действительно нужно - используйте на здоровье. А монолит там у вас или мэш из микросервисов - не так уж важно)
@@Rclass ну если мне нужен брокер сообщений хороший, неужели самому писать
@@maksimsergeevich5939 тогда используйте конечно)
03:00 - Что значит "RabbitMQ сам дёргает получателя?"
Получатель не как в redis, в желаемый им момент НЕ может обратиться к сервису и по ключу и данные получить?
Надо держать его в режиме слушания постоянно? А если слушатель занят? RabbitMq дождётся, когда тот освободится и снова пошлёт?
Да, слушатель поднимается и работает рядом с producer. Да, если слушатель один и он занят - то сообщения обработаются по очереди, одно за другим)
на сколько я понимаю в кафеке оффсет не у партиции, а у партиции и консъюмер группы, а консъюмер групп может быть несколько, и они могут параллельно по разному читать партиции, внутри консъюмер группы да, партиций должно хватать на каждого консъюмера в консъюмер группе
6:13 Funout ??? Maybe "fanout" ?
:facepalm: fanout естессно)
kurz und sehr klar
vielen dank
Ай спасибо, добрый человек :)
Забавное совпадение когда лектор исчез рассказывая про TTL для memcached
Магия, не иначе :)
Столько всего придумано, что вроде не чего не надо, но продолжают и продолжают что то изобретать :-)
Что-то устаревает, что-то становится более востребованным... Не стоит на месте отрасль)
Как брокер сообщений , очереди на redis сделать?
Добрый день! Подключаете редис и используете)
Что за фокус с исчезнлвением произошел на 21.10-21.16 ?
Это неназванная технология)
@@Rclass а на кого вы учите свою группу ? Админис раторы базы данных ?
На 20:43 изчезновение. Это какая технология?)
Мы проверяем пока, обкатываем и тестируем. Как только будет готово в прод - обязательно сообщим! :)
у ведущего истекло время жизни
Крутецкий доклад, хорошо и быстро прошёлся по технологиям, удобно выбирать
Я бы ещё Cassandra добавил, ну и немножко Camel, хоть это и несколько другого плана вещь, но тоже для обмена данными
Спасибо, мы старались :)
Биндинг обменников и очередей в RabbitMQ - это не всегда строка как заявлено. Есть еще тип обменника Consistent-Hash, который вообще не рассмотрен, у него как раз биндинг - число.
Учтем, обычно работали со строками)
20:44 - докладчик исчез, надеюсь, он закешировался.
Ахаха) Лучшая шутка про исчезновение, жаль два закрепа нельзя) Спасибо что смотрите)
Бля, да вы волшебник 😆 20:41
А то, практикуем новые технологии!
По пацански)
Именно)
Можно попробовать сделать пару таких обзоров) Можете ещё посмотреть видео про нормализацию БД, там есть такой персонаж как Гена)
@@OkulovAnton Как только дойду до оптимизации БД, сразу же посмотрю)
20:40 Антон, если так по фану использовать кольцо, Назгулы на тебя выйдут быстрее
Ужас! Я буду осторожен! Только никому!
Непонятно зачем в этот список Nuxt попал)
Там половина не понятно зачем) Дикий компот :) Но вот так попросили осветить)