Forwarded from rizzearch
Transformers for Supervised Online Continual Learning
мы уже когда-то давно писали про continual (reinforcement) learning - здесь, здесь, здесь, и здесь. но есть и супервайзд формулировка этой же задачи - меняется не ревард с течением времени или другие факторы среды, а онлайн поток лейблов (уметь классифицировать новый класс без забывания предыдущих)
в этой статье дипмаинды попытались подогнать трансформер под такой сетап на примере континуал емнист и цифар10. нету привычного батчированного предобучения (разве что используются предобученные картиночные feature extractors), а есть кое-что другое
что же все-таки смогли учудить авторы?
- обновляют модель в онлайн формате, чтобы соответствовать ограничениям задачи
- при этом сохраняют в КВ кэше предыдущие вычисления в sliding window стиле. да и кв кэш не один, а их несколько таких буферов (которые, видимо, рандомно сменяют друг друга, здесь авторы не совсем ясно расписали)
- таким образом и аттеншн утилизируется более стандартным способом, как мы привыкли, так еще и имитирует момент обучения по эпохам ввиду попеременной смены кв кэшей при градиентном обновлении. еще конечно интересно, как они реализовали online gradient шаг в комбинации с кв кэшами, поскольку к этому надо подойти аккуратно (и еще аккуратнее, чтобы достичь минимального оверхеда по обновлению состояний), но этого мы видимо не узнаем
- так же они попробовали 2 подхода по вставке лейблов - просто в контекст (и при next-token prediction задаче моделировать надо только их) или как доп проекция для kv, которые показывают себя примерно одинаково на существующих бенчмарках
кода нет (разве что псевдокод, по которому мало что понятно), толкового описания имплементации тоже. есть только интересные рассуждения, которыми нас кормят авторы, по поводу натуральности применения трансформеров к онлайн континуал задачам, поскольку они хорошо справляются с законом Ципфа) и контекстуальности входящих данных → это больше подходит не к i.i.d данным, а нестационарности
имхо, сухой остаток из этой статьи помимо домена континуал лернинга можно вынести в интересном сочетании in-weights & in-context лернинга, которые дополняют друг друга для такой онлайн задачи. в виде трансформера такое решение выглядит покрасивее, чем надстройка внешней памяти над каким-то нативным классификатором, потому что в архитектуре уже это заложено в тандеме (и другие ресерчеры ни раз уже упоминали об аналогиях между кв кэшем и памятью, в том числе и с линейным аттеншном)
так что да, очередная статья про интересные свойства трансформера
👀LINK
мы уже когда-то давно писали про continual (reinforcement) learning - здесь, здесь, здесь, и здесь. но есть и супервайзд формулировка этой же задачи - меняется не ревард с течением времени или другие факторы среды, а онлайн поток лейблов (уметь классифицировать новый класс без забывания предыдущих)
в этой статье дипмаинды попытались подогнать трансформер под такой сетап на примере континуал емнист и цифар10. нету привычного батчированного предобучения (разве что используются предобученные картиночные feature extractors), а есть кое-что другое
что же все-таки смогли учудить авторы?
- обновляют модель в онлайн формате, чтобы соответствовать ограничениям задачи
- при этом сохраняют в КВ кэше предыдущие вычисления в sliding window стиле. да и кв кэш не один, а их несколько таких буферов (которые, видимо, рандомно сменяют друг друга, здесь авторы не совсем ясно расписали)
- таким образом и аттеншн утилизируется более стандартным способом, как мы привыкли, так еще и имитирует момент обучения по эпохам ввиду попеременной смены кв кэшей при градиентном обновлении. еще конечно интересно, как они реализовали online gradient шаг в комбинации с кв кэшами, поскольку к этому надо подойти аккуратно (и еще аккуратнее, чтобы достичь минимального оверхеда по обновлению состояний), но этого мы видимо не узнаем
- так же они попробовали 2 подхода по вставке лейблов - просто в контекст (и при next-token prediction задаче моделировать надо только их) или как доп проекция для kv, которые показывают себя примерно одинаково на существующих бенчмарках
кода нет (разве что псевдокод, по которому мало что понятно), толкового описания имплементации тоже. есть только интересные рассуждения, которыми нас кормят авторы, по поводу натуральности применения трансформеров к онлайн континуал задачам, поскольку они хорошо справляются с законом Ципфа) и контекстуальности входящих данных → это больше подходит не к i.i.d данным, а нестационарности
имхо, сухой остаток из этой статьи помимо домена континуал лернинга можно вынести в интересном сочетании in-weights & in-context лернинга, которые дополняют друг друга для такой онлайн задачи. в виде трансформера такое решение выглядит покрасивее, чем надстройка внешней памяти над каким-то нативным классификатором, потому что в архитектуре уже это заложено в тандеме (и другие ресерчеры ни раз уже упоминали об аналогиях между кв кэшем и памятью, в том числе и с линейным аттеншном)
так что да, очередная статья про интересные свойства трансформера
👀LINK
Forwarded from rizzearch
Memory Mosaics
хоть недавно и вышла альтернатива трансформеру от саканы, она все равно использует аттеншн как основной механизм и не выглядит как вывод из bitter lesson
здесь же хочется написать про айклировские 2025 мозаики памяти, которые базируются на ассоциативной памяти (да, она мне нравится и я про нее уже писал здесь и здесь + китай тоже что-то пытается с ней делать, разбавляя текст цитатами из goodreads)
вместо селф аттеншна идет же база на основе Надарая-Ватсона [1], [2]
- где моделируют необходимые ключи k и значения v для ассоциаций
- при том ключи вычисляются по токенам вплоть до данного таймстепа, а значения же на один шаг вперед (хотя можно в теории сделать и на большее количество шагов + нам еще так не придется вставлять позиционное кодирование), а на инференсе получается путем интерполяции
- и итоговый аутпут вычисляется через Надарая-Ватсона (который в теории должен сходиться к истинному какому-то там условному мат ожиданию значений v от ключей k)
- и поскольку теоретически один такой модуль сходится, то и интерпретация его (по словам авторов) лучше, чем один модуль селф аттеншна, да и даже эффективнее. так они эмпирически показывают, что inductive bias может появиться уже с одним таким блоком памяти, в то время как аттеншну нужно минимум 2 слоя
- для того, чтобы хендлить длинные последовательности и больше укрепить вопрос о позиционности токенов в архитектуре, авторы добавили нормализацию и leaky average, которую можно реализовать через свертку
- если же наслаивать эти модули друг на друга, каждый в отдельности будет отвечать за свой кусок меморизации, нужный для цельной картины - отсюда и название мозаик памяти (а и еще это наводит на мысли о связи мета-лернинга и градиентного обучения, про которое мы и тут упоминали)
что по экспам?
- супер-пупер маленький скейл (сравнивают с маленькой гпт2)
- игрушечные датасеты (3 луны) + языковое моделирование как BabiStories + in-context learning on RegBench
- обгоняет по перплексии, обгоняет в ин-контекст лернинг сетапе + нужно меньше слоев (в том числе в сравнении и с рнн и ссм)
- добавляют еще аналог FFN в виде Persistent Associative Memory (где количество kv фиксировано и они побольше подходят с теории кернел регрессии)
- но масштабируемо ли?
seems like not. иначе их predictive disentanglement (свойство мозаики) сравнивался с бОльшим скейлом моделек + были бы аблации на чувствительность к гиперам
но материал хорош для повторения всей этой теории и нового взгляда на аттеншн
👀 paper, code
хоть недавно и вышла альтернатива трансформеру от саканы, она все равно использует аттеншн как основной механизм и не выглядит как вывод из bitter lesson
здесь же хочется написать про айклировские 2025 мозаики памяти, которые базируются на ассоциативной памяти (да, она мне нравится и я про нее уже писал здесь и здесь + китай тоже что-то пытается с ней делать, разбавляя текст цитатами из goodreads)
вместо селф аттеншна идет же база на основе Надарая-Ватсона [1], [2]
- где моделируют необходимые ключи k и значения v для ассоциаций
- при том ключи вычисляются по токенам вплоть до данного таймстепа, а значения же на один шаг вперед (хотя можно в теории сделать и на большее количество шагов + нам еще так не придется вставлять позиционное кодирование), а на инференсе получается путем интерполяции
- и итоговый аутпут вычисляется через Надарая-Ватсона (который в теории должен сходиться к истинному какому-то там условному мат ожиданию значений v от ключей k)
- и поскольку теоретически один такой модуль сходится, то и интерпретация его (по словам авторов) лучше, чем один модуль селф аттеншна, да и даже эффективнее. так они эмпирически показывают, что inductive bias может появиться уже с одним таким блоком памяти, в то время как аттеншну нужно минимум 2 слоя
- для того, чтобы хендлить длинные последовательности и больше укрепить вопрос о позиционности токенов в архитектуре, авторы добавили нормализацию и leaky average, которую можно реализовать через свертку
- если же наслаивать эти модули друг на друга, каждый в отдельности будет отвечать за свой кусок меморизации, нужный для цельной картины - отсюда и название мозаик памяти (а и еще это наводит на мысли о связи мета-лернинга и градиентного обучения, про которое мы и тут упоминали)
что по экспам?
- супер-пупер маленький скейл (сравнивают с маленькой гпт2)
- игрушечные датасеты (3 луны) + языковое моделирование как BabiStories + in-context learning on RegBench
- обгоняет по перплексии, обгоняет в ин-контекст лернинг сетапе + нужно меньше слоев (в том числе в сравнении и с рнн и ссм)
- добавляют еще аналог FFN в виде Persistent Associative Memory (где количество kv фиксировано и они побольше подходят с теории кернел регрессии)
- но масштабируемо ли?
seems like not. иначе их predictive disentanglement (свойство мозаики) сравнивался с бОльшим скейлом моделек + были бы аблации на чувствительность к гиперам
но материал хорош для повторения всей этой теории и нового взгляда на аттеншн
👀 paper, code
Forwarded from Дата аналитикс
Обещанный аналитический ноутбук от бигтеха!
Доброе воскресеннее утро!
Здесь приложил ссылку на google colab с реальным кейсом на собес Миддла!
Вот вам отличная возможность поработать с датасетом с собеса + ответить на типовые вопросы на скорость решения (причем такие, которые часто самому надо сделать).
Че думаете по поводу сложности кейса?
По традиции ставим прогрессивного жаба📈 , если ждете больше крутых и удобных материалов, заинтересованного жаба 📃 если было интересно глянуть решение и просто лайк ❤️, чтобы я увидел ваш фидбек
Доброе воскресеннее утро!
Здесь приложил ссылку на google colab с реальным кейсом на собес Миддла!
Как с ним работать?
1. Первое и самое главное - нажимаем на "файл" - "сохранить копию на диске"
2. Выполняем задачи, по возможности засекайте время выполнения таких вещей как: распарсить данные, выполнение 1, 2 и тд задач
3. Если необходимо закидываем общую инфу из датасета в чат GPT и просим придумать еще задания.
* Если же вы еще маленький или сомневаетесь в себе, но очень интересно - там внизу есть мое решение с комментариями того как я мыслю
Вот вам отличная возможность поработать с датасетом с собеса + ответить на типовые вопросы на скорость решения (причем такие, которые часто самому надо сделать).
Че думаете по поводу сложности кейса?
По традиции ставим прогрессивного жаба
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from настенька и графики
This media is not supported in your browser
VIEW IN TELEGRAM
Интерактивный учебник искусству вайб-кодинга от Рика Рубина 🌊
Год назад и представить не могла бы, что такой коллаб возможен. Бесплатная онлайн книжка, в большей степени про искусство создания. В похожем стиле, что и "The Creative Act" -- чтобы остановиться, подумать и вдохновиться. Не бояться критики, не утопать в попытке создать идеальное и конечно же попробовать создать каждую из этих визуализаций в Claude.
Год назад и представить не могла бы, что такой коллаб возможен. Бесплатная онлайн книжка, в большей степени про искусство создания. В похожем стиле, что и "The Creative Act" -- чтобы остановиться, подумать и вдохновиться. Не бояться критики, не утопать в попытке создать идеальное и конечно же попробовать создать каждую из этих визуализаций в Claude.
Forwarded from Refat Talks: Tech & AI
Media is too big
VIEW IN TELEGRAM
🔥 Наконец-то рабочий Telegram MCP!
Из нескольких GitHub-репозиториев только mcp-telegram от dryeab оказался реально рабочим. И работает он просто огонь! Сделал обзорчик специально для вас.
Зацените, на видео показываю уже настроенную версию: поиск по сообщениям, анализ канала (угадайте чей?), суммаризация контента. Все то, что может делать обычный пользователь Telegram - не бот, а именно юзер-аккаунт. Работает неожиданно быстро и стабильно.
Что можно делать через этот MCP:
- Отправлять, редактировать и удалять сообщения
- Искать по истории чатов с фильтрами
- Скачивать медиа из сообщений
- Управлять черновиками
- Получать сообщения по прямым ссылкам
- Искать пользователей, группы и каналы
И все это прямо из Claude, Cursor и т.д.
Важный дисклеймер: я проанализировал репозиторий, проверил зависимости - ничего подозрительного. Но все равно поставил на тестовый тг аккаунт. Вам тоже советую использовать тестовый, безопасность - прежде всего. Плюс нужно соблюдать ToS Telegram и не злоупотреблять.
Настройка не самая очевидная, но для mtproto стандартная: получаете API ID, ключ, hash и тд с my.telegram.org, аутентифицируетесь через CLI, добавляете конфиг в Claude Desktop.
Side note: вся эта возня с JSON-конфигами и CLI-командами поднимает порог входа в MCP для нетехнических людей, надо что-то с этим делать)
Но если вы умеете в терминал - очень рекомендую поиграиться. Это реально расширяет возможности Claude и открывает кучу интересных use case'ов.
Репозиторий: https://github.com/dryeab/mcp-telegram
И это,если этот пост не заслуживает на 🔥 и репост, то даже не знаю какой заслуживает! :)
Из нескольких GitHub-репозиториев только mcp-telegram от dryeab оказался реально рабочим. И работает он просто огонь! Сделал обзорчик специально для вас.
Зацените, на видео показываю уже настроенную версию: поиск по сообщениям, анализ канала (угадайте чей?), суммаризация контента. Все то, что может делать обычный пользователь Telegram - не бот, а именно юзер-аккаунт. Работает неожиданно быстро и стабильно.
Что можно делать через этот MCP:
- Отправлять, редактировать и удалять сообщения
- Искать по истории чатов с фильтрами
- Скачивать медиа из сообщений
- Управлять черновиками
- Получать сообщения по прямым ссылкам
- Искать пользователей, группы и каналы
И все это прямо из Claude, Cursor и т.д.
Важный дисклеймер: я проанализировал репозиторий, проверил зависимости - ничего подозрительного. Но все равно поставил на тестовый тг аккаунт. Вам тоже советую использовать тестовый, безопасность - прежде всего. Плюс нужно соблюдать ToS Telegram и не злоупотреблять.
Настройка не самая очевидная, но для mtproto стандартная: получаете API ID, ключ, hash и тд с my.telegram.org, аутентифицируетесь через CLI, добавляете конфиг в Claude Desktop.
Side note: вся эта возня с JSON-конфигами и CLI-командами поднимает порог входа в MCP для нетехнических людей, надо что-то с этим делать)
Но если вы умеете в терминал - очень рекомендую поиграиться. Это реально расширяет возможности Claude и открывает кучу интересных use case'ов.
Репозиторий: https://github.com/dryeab/mcp-telegram
И это,
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Apps Design (Artemiy Kozyr)
Или как собрать аналитическое приложение за $2 в месяц.
Изучая стек dlt + DuckDB + dbt + Observable (Streamlit), я наткнулся на интересную архитектуру. Оказывается, можно создать функциональное, но в то же время легковесное аналитическое приложение, которое работает почти без серверов.
GitHub Actions (CI) → dlt загружает данные →
dbt трансформирует → DuckDB файл → S3/Object storage →
Observable/Streamlit читает DuckDB-WASM в браузере
— Object storage / S3: $0.015 за GB хранения
— GitHub Actions: 2000 минут бесплатно
— Observable: бесплатно
— Итого: ~$2/месяц для приложения с 10GB данных
✅ Дашборд грузится за 200ms (всё в браузере)
✅ Работает офлайн после первой загрузки
✅ Выдерживает любые нагрузки (статика!)
✅ Автообновление через GitHub Actions
❌ Размер данных ограничен памятью браузера (~2-4GB), но вряд ли нам вообще понадобится больше (ведь хранить мы будем агрегированные витрины)
❌ Сложные real-time обновления проблематичны
❌ Нет серверной логики для сложной авторизации
❌ Ограниченная интерактивность и self-service (для этого нужны BI типа Superset)
— B2B SaaS аналитика для клиентов / Сквозная аналитика / Sales, Markeplace metrics, etc.
— Встраиваемая (Embedded) в web / mobile apps аналитика
— Демонстрационные стенды (showcasing)
— Публичная аналитика (типа COVID дашбордов)
— Дашборды для внутреннего контура компании (до 1000 сотрудников)
— Персональные и pet-проекты с историческими данными
— Собираем данные Я.Метрика, Я.Директ, AmoCRM (Bitrix) с помощью dlt в DuckDB
— Варим эти данные, чистим, нормализуем, объединяем, считаем витрины (dbt + DuckDB)
— Создаем интерактивное приложение на основе Observable с DuckDB-WASM под капотом (т.е. бразуер = сервер, который процессит витрину в DuckDB)
— В приложении видим динамику ключевых метрик Marketing, Sales разрезах: даты, каналы, георгафия, воронки, sales-менеджеры
— Приложение = статический вебсайт, который размещается на любом хостинге (Object storage / S3) и не требует сервера
Где еще можно (нужно) применить такой подход?
Кто пробовал похожие решения?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from BeOps
System Design github repo 🕌
Проходил сис дизайн интервью в прошлый понедельник, а сегодня наткнулся на такой репозиторий: https://github.com/ByteByteGoHq/system-design-101?tab=readme-ov-file. Это просто библия для прохождения сис дизайна. По мне так отличное чтиво в мире сложных архитектурных решений. Здесь есть всё: от сравнений REST API и GraphQL до объяснений, почему Nginx называют reverse proxy. А если хочешь узнать, как работает Google Authenticator или почему Redis такой быстрый, то тут вообще велком.
Что здесь есть? (спойлер: ВСЁ) 🌍
- Архитектурные паттерны: Хочешь понять, что такое MVC, MVP, MVVM или даже VIPER? Легко.
- CI/CD: Хочешь почувствовать себя инженером Netflix? Добро пожаловать.
- Кэширование: Почему Redis так быстр? Как кэшировать данные правильно? Ответы здесь.
- Базы данных: Визуализация SQL-запросов, CAP-теорема и даже "8 структур данных, которые управляют вашими базами".
- Микросервисы: Лучшие практики, Kafka, и типичная архитектура микросервисов.
- Реальные кейсы: Хочешь понять, как Discord хранит триллионы сообщений или как YouTube справляется с потоковым видео? Этот репозиторий расскажет.
Документация понятным языком 😌
Здесь всё объясняется простыми словами, а визуализации помогут понять даже самые сложные концепции. Например, диаграммы HTTP-протоколов или сравнение Webhook и polling — это просто шедевры.
Что мне еще понравилось,это то что многие репозитории и статьи сосредотачиваются на одной теме — типа БД, DevOps или микросервисы. Но "System Design 101" — это будто шведский стол для инженеров: тут есть всё и сразу, причём подано так, что хочется взять добавки. Конечно, есть и другие хорошие источники (например, книги Фаулера или блоги Google), но этот репозиторий выигрывает своей компактностью и доступностью.
Добавляй в закладки и начни своё путешествие к званию мастера системного дизайна. Кароче, с таким багажом получаешь +10 к харизме на собеседованиях и +20 к навыкам архитектуры. Проверить это можно только одним способом — скачал, отсобесился, забрал офер на 500к.
Проходил сис дизайн интервью в прошлый понедельник, а сегодня наткнулся на такой репозиторий: https://github.com/ByteByteGoHq/system-design-101?tab=readme-ov-file. Это просто библия для прохождения сис дизайна. По мне так отличное чтиво в мире сложных архитектурных решений. Здесь есть всё: от сравнений REST API и GraphQL до объяснений, почему Nginx называют reverse proxy. А если хочешь узнать, как работает Google Authenticator или почему Redis такой быстрый, то тут вообще велком.
Что здесь есть? (спойлер: ВСЁ) 🌍
- Архитектурные паттерны: Хочешь понять, что такое MVC, MVP, MVVM или даже VIPER? Легко.
- CI/CD: Хочешь почувствовать себя инженером Netflix? Добро пожаловать.
- Кэширование: Почему Redis так быстр? Как кэшировать данные правильно? Ответы здесь.
- Базы данных: Визуализация SQL-запросов, CAP-теорема и даже "8 структур данных, которые управляют вашими базами".
- Микросервисы: Лучшие практики, Kafka, и типичная архитектура микросервисов.
- Реальные кейсы: Хочешь понять, как Discord хранит триллионы сообщений или как YouTube справляется с потоковым видео? Этот репозиторий расскажет.
Документация понятным языком 😌
Здесь всё объясняется простыми словами, а визуализации помогут понять даже самые сложные концепции. Например, диаграммы HTTP-протоколов или сравнение Webhook и polling — это просто шедевры.
Что мне еще понравилось,это то что многие репозитории и статьи сосредотачиваются на одной теме — типа БД, DevOps или микросервисы. Но "System Design 101" — это будто шведский стол для инженеров: тут есть всё и сразу, причём подано так, что хочется взять добавки. Конечно, есть и другие хорошие источники (например, книги Фаулера или блоги Google), но этот репозиторий выигрывает своей компактностью и доступностью.
Добавляй в закладки и начни своё путешествие к званию мастера системного дизайна. Кароче, с таким багажом получаешь +10 к харизме на собеседованиях и +20 к навыкам архитектуры. Проверить это можно только одним способом — скачал, отсобесился, забрал офер на 500к.
GitHub
GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design…
Explain complex systems using visuals and simple terms. Help you prepare for system design interviews. - ByteByteGoHq/system-design-101
Forwarded from Анализ, коты, цветы и Катя (Катерина)
🐰 Самый простой способ понять работу RabbitMQ 🐰
В сообществе аналитиков довольно известен этот визуализатор работы Kafka. Я узнала о нём из блога Системный сдвиг, а затем оценила классную рекомендацию по работе с ним от Yet Another Analyst.
Но поскольку я провожу уроки именно по RabbitMQ, стало интересно: А есть ли похожая визуализация RabbitMQ для тех, хочет быстро просто “увидеть”, как оно работает?
Оказывается, есть! И даже несколько:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer
Я советую первый. Как с ним работать? Часть 1.
🚦 0. Добавьте producer и queue. Попробуйте соединить их напрямую. Добавьте exchange, соедините всё по схеме: producer → exchange → queue. Что то должно начинать получаться, потому что еxchange — обязательный этап маршрута в RabbitMQ. У связи exchange и queue появился binding — ключевой элемент понимания маршрутизации. Добавьте consumer. Попробуйте соединить consumer с exchange. Что-то снова будет не хватать. Но правильный порядок близок: producer → exchange → queue → consumer.
💥 1. Выберите для exchange тип fanout. Создайте еще 2 очереди и 2 потребителя и привяжите их к exchange. Отправьте сообщение без routing key. Куда оно ушло? Установите разные binding key и отправьте сообщения со случайными с routing key. Что происходит? Удалите один binding. Получает ли эта очередь сообщение? Здесь можно еще поэкспериментировать с ключами, Но основную особенность обменника типа fanout вы уже должны нащупать.
Это первые важные шаги для знакомства с базовой схемой кролика и типом обменника Fanout. Сохраняйте, пробуйте.
В следующем посте расскажу про упражнения для схем с Direct и Topic exchange — не пропустите!
#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst
В сообществе аналитиков довольно известен этот визуализатор работы Kafka. Я узнала о нём из блога Системный сдвиг, а затем оценила классную рекомендацию по работе с ним от Yet Another Analyst.
Но поскольку я провожу уроки именно по RabbitMQ, стало интересно: А есть ли похожая визуализация RabbitMQ для тех, хочет быстро просто “увидеть”, как оно работает?
Оказывается, есть! И даже несколько:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer
Я советую первый. Как с ним работать? Часть 1.
🚦 0. Добавьте producer и queue. Попробуйте соединить их напрямую. Добавьте exchange, соедините всё по схеме: producer → exchange → queue. Что то должно начинать получаться, потому что еxchange — обязательный этап маршрута в RabbitMQ. У связи exchange и queue появился binding — ключевой элемент понимания маршрутизации. Добавьте consumer. Попробуйте соединить consumer с exchange. Что-то снова будет не хватать. Но правильный порядок близок: producer → exchange → queue → consumer.
💥 1. Выберите для exchange тип fanout. Создайте еще 2 очереди и 2 потребителя и привяжите их к exchange. Отправьте сообщение без routing key. Куда оно ушло? Установите разные binding key и отправьте сообщения со случайными с routing key. Что происходит? Удалите один binding. Получает ли эта очередь сообщение? Здесь можно еще поэкспериментировать с ключами, Но основную особенность обменника типа fanout вы уже должны нащупать.
Это первые важные шаги для знакомства с базовой схемой кролика и типом обменника Fanout. Сохраняйте, пробуйте.
В следующем посте расскажу про упражнения для схем с Direct и Topic exchange — не пропустите!
#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst
Forwarded from Анализ, коты, цветы и Катя (Катерина)
🐰 Самый простой способ понять работу RabbitMQ — Часть 2 🐰
🧵 Первая часть
В первой части я поделилась двумя визуализаторами для RabbitMQ:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer
И простыми упражнениями, чтобы разобраться с типом обменника fanout.
Теперь давайте посмотрим на обменники типа Direct и Topic.
1) Очистим поле и снова создадим схему: producer → exchange → 3 очереди → 3 consumer'а. Тип обменника — direct. Для binding key укажем key1, key2, key3. Теперь отправим сообщение с routing key = key. Куда попало сообщение? Затем поочерёдно отправим сообщения с ключами key1, key2, key3. Попробуйте также: key1_1, key1.*, key1.#. Если всё сделали правильно — должны появиться мысли про "полное соответствие".
2) Меняем тип обменника на topic. Для binding key задаём: *.low.* , #.spb , *.high.#
Сразу подсказка: . — разделяет ключи, * — заменяет ровно одно слово, # — заменяет 0 и более слов. Пробуем отправлять: key1.low.smr, key1.middle.spb, key2.high.krd, low.smr, key, high и другие. Для полноты картины можно поэкспериментировать с регистром и пробелами.
3) RabbitMQ для практиков: создаём схему с несколькими exchange'ами, соединяем их как на картинке. Пробуем задавать разные типы для обменников, подбирать ключи и очереди, отправлять сообщения с разными routing key. И просто наблюдать, как идёт сообщение. На этом этапе особенно важен подход "А что если?.." и ваша фантазия.
💡 Еще в TryRabbitMQ можно поэкспериментировать с периодичностью отправки и анонимными очередями. Но, на мой взгляд, в визуализаторе эти функции реализованы довольно скучно и не слишком информативно.
📌 В последней части (на следующей неделе) расскажу, что нельзя увидеть в визуализаторе, куда копать тем, кто хочет больше.
#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst
🧵 Первая часть
В первой части я поделилась двумя визуализаторами для RabbitMQ:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer
И простыми упражнениями, чтобы разобраться с типом обменника fanout.
Теперь давайте посмотрим на обменники типа Direct и Topic.
1) Очистим поле и снова создадим схему: producer → exchange → 3 очереди → 3 consumer'а. Тип обменника — direct. Для binding key укажем key1, key2, key3. Теперь отправим сообщение с routing key = key. Куда попало сообщение? Затем поочерёдно отправим сообщения с ключами key1, key2, key3. Попробуйте также: key1_1, key1.*, key1.#. Если всё сделали правильно — должны появиться мысли про "полное соответствие".
2) Меняем тип обменника на topic. Для binding key задаём: *.low.* , #.spb , *.high.#
Сразу подсказка: . — разделяет ключи, * — заменяет ровно одно слово, # — заменяет 0 и более слов. Пробуем отправлять: key1.low.smr, key1.middle.spb, key2.high.krd, low.smr, key, high и другие. Для полноты картины можно поэкспериментировать с регистром и пробелами.
3) RabbitMQ для практиков: создаём схему с несколькими exchange'ами, соединяем их как на картинке. Пробуем задавать разные типы для обменников, подбирать ключи и очереди, отправлять сообщения с разными routing key. И просто наблюдать, как идёт сообщение. На этом этапе особенно важен подход "А что если?.." и ваша фантазия.
💡 Еще в TryRabbitMQ можно поэкспериментировать с периодичностью отправки и анонимными очередями. Но, на мой взгляд, в визуализаторе эти функции реализованы довольно скучно и не слишком информативно.
📌 В последней части (на следующей неделе) расскажу, что нельзя увидеть в визуализаторе, куда копать тем, кто хочет больше.
#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst