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