Media is too big
VIEW IN TELEGRAM
🚩Кейс: Партиционирование при проведении A/B-тестирования.
ℹ️ Для удобной оценки эффективности новых алгоритмов лучше всего создавать партиции по сегментам пользователей. Тех пользователей, которые работают со старыми алгоритмами, относим в сегмент А. Тех, кто работает с новыми, относим в сегмент Б.
Таким образом получим:
✅ Быстрые выборки при агрегации метрик внутри сегмента (исследуемого алгоритма);
✅ Моментальное удаление тестовых данных после завершения тестирования.
Системный анализ | Дмитрий Помаскин
ℹ️ Для удобной оценки эффективности новых алгоритмов лучше всего создавать партиции по сегментам пользователей. Тех пользователей, которые работают со старыми алгоритмами, относим в сегмент А. Тех, кто работает с новыми, относим в сегмент Б.
Таким образом получим:
✅ Быстрые выборки при агрегации метрик внутри сегмента (исследуемого алгоритма);
✅ Моментальное удаление тестовых данных после завершения тестирования.
Системный анализ | Дмитрий Помаскин
👍6🔥5
🔸Что такое партиционирование в БД?
🔸Очистка устаревших данных в БД.
🔸Построение отчетов по регионам.
🔸Партиционирование при проведении A/B-тестирования.
P.S. Если вам было бы интересно в таком же формате послушать про шардирование, то ставьте 👍.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥9
Так как голоса о днях проведения разделились, запускаю 2 группы:
🔸Воскресенье 20.07 12:00 МСК;
🔸Понедельник 21.07 19:00 МСК.
Тема: Базы данных.
Уровень: С нуля.
Кол-во участников: до 4.
Программа:
✅ Типы баз данных;
✅ Проектирование БД;
✅ Описание БД с помощью ER-диаграммы;
✅ Нормализация;
✅ Базовый SQL для аналитиков.
Практика:
✅ Самостоятельное проектирование БД для сервиса;
✅ Описание этой БД с помощью ER-диаграммы;
✅ Написание SQL-запросов.
Так как обе группы пилотные, цену участия поставил максимально низкую. В будущем цена будет выше.
Для тех, кто не понимает, о каких интенсивах речь, подробности тут.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍4
Дату и время проведения следующих интенсивов объявлю позже.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🤯4
Media is too big
VIEW IN TELEGRAM
❓Что такое шардирование в БД?
ℹ️ Шардирование — это метод распределения данных в базе данных между несколькими серверами (шардами) для повышения производительности и масштабируемости системы.
Основные типы шардирования:
✅ Горизонтальное шардирование — данные разделяются по диапазону значений (аналогично партиционированию);
✅ Вертикальное шардирование — разные таблицы или столбцы в них размещаются на разных серверах;
✅ Хэш-шардирование — используется хэш-функция от ключа шардирования для определения места хранения.
⚠️Отличие шардирования от партиционирования — при шардировании данные разделены по серверам, при партиционировании остаются на одном сервере.
⚠️Отличие шардирования от классического кластера — при шардировании данные не реплицируются, а просто распределяются по шардам. В кластере данные реплицируются между нодами.
P.S. В следующих видео на примерах расскажу, какие преимущества можно получить от внедрения шардирования.
Системный анализ | Дмитрий Помаскин
ℹ️ Шардирование — это метод распределения данных в базе данных между несколькими серверами (шардами) для повышения производительности и масштабируемости системы.
Основные типы шардирования:
✅ Горизонтальное шардирование — данные разделяются по диапазону значений (аналогично партиционированию);
✅ Вертикальное шардирование — разные таблицы или столбцы в них размещаются на разных серверах;
✅ Хэш-шардирование — используется хэш-функция от ключа шардирования для определения места хранения.
⚠️Отличие шардирования от партиционирования — при шардировании данные разделены по серверам, при партиционировании остаются на одном сервере.
⚠️Отличие шардирования от классического кластера — при шардировании данные не реплицируются, а просто распределяются по шардам. В кластере данные реплицируются между нодами.
P.S. В следующих видео на примерах расскажу, какие преимущества можно получить от внедрения шардирования.
Системный анализ | Дмитрий Помаскин
👍8🔥6👏1
Media is too big
VIEW IN TELEGRAM
🚩Кейс: Применение шардирования по регионам.
ℹ️ Если делить данные между шардами в разрезе регионов, это даст вам прирост производительности при выборке данных из нескольких регионов:
1️⃣ Запрос разделится на несколько шардов, в зависимости от того, по скольким регионам выполняется запрос.
2️⃣ Каждый шард выполнит запрос на своих ресурсах, так как является отдельным сервером.
3️⃣ БД объединит данные, полученные с каждого шарда, и вернёт вам общий результат запроса.
P.S. Кто пропустил пост про шардирование, он тут.
Системный анализ | Дмитрий Помаскин
ℹ️ Если делить данные между шардами в разрезе регионов, это даст вам прирост производительности при выборке данных из нескольких регионов:
1️⃣ Запрос разделится на несколько шардов, в зависимости от того, по скольким регионам выполняется запрос.
2️⃣ Каждый шард выполнит запрос на своих ресурсах, так как является отдельным сервером.
3️⃣ БД объединит данные, полученные с каждого шарда, и вернёт вам общий результат запроса.
P.S. Кто пропустил пост про шардирование, он тут.
Системный анализ | Дмитрий Помаскин
4👍6🔥5
Media is too big
VIEW IN TELEGRAM
🚩Кейс: поиск проблемного участка в распределенной системе.
Вспомните, как иногда тяжело найти тот самый микросервис, который вернул вам неверный результат.
Долгие выяснения "кто виноват" между командами разработки и часы поиска нужного сообщения в логах.🤬
На выходных заканчивал подготовку модулей для тарифа "Senior" по системным интеграциям и решил поделиться с вами фрагментом из модуля по observability.
❗️ В нем рассказываю, как повысить observability системы и упростить поиск багов в больших распределенных системах с помощью трассировки между сервисами.
Системный анализ | Дмитрий Помаскин
Вспомните, как иногда тяжело найти тот самый микросервис, который вернул вам неверный результат.
Долгие выяснения "кто виноват" между командами разработки и часы поиска нужного сообщения в логах.
На выходных заканчивал подготовку модулей для тарифа "Senior" по системным интеграциям и решил поделиться с вами фрагментом из модуля по observability.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍2👏1🙏1
Немного позже, чем я планировал, но курс по интеграциям, наконец-то, готов полностью.
Напомню, что на нём вместо классических тарифов я предлагаю три гибких варианта, которые открывают доступ к модулям поэтапно.
Junior (12 890 ₽)
✅ Введение в системные интеграции;
✅ Форматы данных в интеграциях;
✅ REST / SOAP / GraphQL;
✅ Интеграционные шины.
Middle (22 480 ₽)
✅ Все модули из тарифа Junior;
✅ Брокеры сообщений;
✅ RPC (Remote Procedure Call);
✅ Real-time взаимодействие (WS, Long Polling, SSE).
Senior (38 790 ₽)
✅ Все модули из тарифов Junior и Middle;
✅ Интеграция на уровне БД;
✅ Безопасность в интеграциях;
✅ Паттерн Circuit Breaker;
✅ Observability (Наблюдаемость) интеграций;
✅ API-first подход, Swagger и AsyncApi.
Записаться можно тут :)
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥4😁1
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥2
Media is too big
VIEW IN TELEGRAM
ℹ️ Состояние (state) — это любые данные, которые компонент должен запомнить между запросами или операциями, чтобы обеспечить корректную работу системы.
✅ Stateless — любой компонент системы, который не сохраняет состояние.
Пример: сервис подготовки печатных форм, который формирует документ по полученным на вход параметрам и шаблону.
✅ Statefull — любой компонент системы, который сохраняет состояние.
Пример: база данных.
Всё кажется очень просто, но давайте проверим, правильно ли вы понимаете разницу на примере.
Опрос ниже
P.S. Гуглить или пользоваться нейросетями — мышиный поступок :)
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍2
Сервис имеет REST API (базовые CRUD-операции) и базу данных PostgreSQL, в которой хранит информацию о своих объектах.
Такой сервис будет Stateless или Statefull?😓
Такой сервис будет Stateless или Statefull?
Final Results
45%
Statefull
55%
Stateless
🤔4
This media is not supported in your browser
VIEW IN TELEGRAM
Сервис будет stateless, так как он сам не хранит никакого состояния, при этом база данных под ним будет statefull.
Усложним задачу:
Теперь сервис помимо REST API имеет web-socket соединение со всеми клиентами для отправки им уведомлений. Соединение устанавливается один раз и держится, пока клиент находится в системе.
Останется ли такой сервис stateless или он станет statefull?
Опрос ниже
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍8🔥5
Каким будет сервис после добавления web-socket?
Final Results
53%
Останется stateless
47%
Станет statefull
🤔5
This media is not supported in your browser
VIEW IN TELEGRAM
Сервис станет statefull. Для того, чтобы отправлять уведомления пользователям, ему необходимо хранить состояния открытых web-socket соединений.
Проще говоря, ему нужно помнить всех пользователей, которые в данный момент находятся в системе, чтобы отправлять им уведомления.
P.S. Дальше усложнять не будем, потому что пятница. Всем хороших выходных :)
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🔥6
Media is too big
VIEW IN TELEGRAM
Вначале вспомним немного теории, а в последних видео расскажу кейсы, в которых я обжигался при неправильном использовании этого подхода.
1️⃣ Сервис решает несколько связанных задач в одной бизнес-области, а микросервис выполняет только одну бизнес-задачу.
2️⃣ В service-oriented подходе часто встречается использование общей базы данных на несколько сервисов. В микросервисах принято придерживаться подхода database-per-service, то есть у каждого микросервиса своя база данных.
Действительно, в service-oriented часто использовались шины данных, но если вы своему сервису сделаете REST API и начнёте взаимодействовать с ним через него вместо шины данных, то он не станет микросервисом. Поэтому это отличие достаточно спорное.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥8
Провели первую волну практических интенсивов. 😎
В основном всё прошло по плану😃
У участников был боевой настрой, задавали много дополнительных вопросов, предлагали нестандартные решения практических задач.
Все большие молодцы!💪
Под этим постом можете поделиться своим впечатлением :)
P.S. Уже завтра в 18:00 по МСК будет доступна запись на все интенсивы августа, об открытии сообщу отдельным постом.
Системный анализ | Дмитрий Помаскин
В основном всё прошло по плану
У участников был боевой настрой, задавали много дополнительных вопросов, предлагали нестандартные решения практических задач.
Все большие молодцы!
Под этим постом можете поделиться своим впечатлением :)
P.S. Уже завтра в 18:00 по МСК будет доступна запись на все интенсивы августа, об открытии сообщу отдельным постом.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥5
Тема: Базы данных.
Уровень: С нуля.
Кол-во участников: до 5.
Длительность: ~4 часа.
Программа:
✅ Типы баз данных;
✅ Проектирование БД;
✅ Описание БД с помощью ER-диаграммы;
✅ Нормализация;
✅ Базовый SQL для аналитиков.
Практика:
✅ Самостоятельное проектирование БД для сервиса;
✅ Описание этой БД с помощью ER-диаграммы;
✅ Написание SQL-запросов.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9
Тема: Проектирование REST API.
Уровень: junior.
Требуемые навыки: Умение читать ER-диаграмму.
Кол-во участников: до 4.
Длительность: ~3.5 часа.
Программа:
✅ Форматы данных;
✅ HTTP-методы и их свойства;
✅ REST и RESTfull;
✅ Обработка ошибок в синхронных интеграциях.
Практика:
✅ Проектирование REST API для нового сервиса;
✅ Внедрение пагинации и фильтрации;
✅ Swagger;
✅ Postman.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍2
Тема: Брокеры сообщений.
Уровень: Middle.
Требуемые навыки: Понимание принципов работы распределённых систем.
Кол-во участников: до 4.
Длительность: ~3.5 часа.
Программа:
✅ Типы брокеров (модель обмена, гарантия доставки, умные/глупые брокеры);
✅ RabbitMQ;
✅ ApacheKafka;
✅ Transaсtional outbox;
✅ Обработка ошибок в асинхронных интеграциях.
Практика:
✅ Внедрение брокеров в распределенную систему;
✅ Описание формата взаимодействия.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7
🔸03.08 12:00 МСК (Воскресенье) — Проектирование REST API;
🔸04.08 19:00 МСК (Понедельник) — Базы данных;
🔸11.08 19:00 МСК (Понедельник) — Проектирование REST API;
🔸24.08 12:00 МСК (Воскресенье) — Брокеры сообщений;
🔸25.08 19:00 МСК (Понедельник) — Брокеры сообщений.
Подробная информация о программах в постах выше
Для тех, кто не понимает, о каких интенсивах речь, подробности тут.
Системный анализ | Дмитрий Помаскин
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍3