👩🏫Объяснение:
Для задачи выборки целого поддерева структура «Вложенные множества» является самой эффективной. Каждая вершина хранит два числа: left и right. Все потомки вершины X имеют left между X.left и X.right. Чтобы выбрать всё поддерево, нужен один простой запрос: SELECT * FROM comments WHERE left >= @root_left AND right <= @root_right ORDER BY left. Это выполняется за один проход по индексу. Поле parent_id (B) потребует рекурсивного запроса (CTE) или множества обращений к БД. Материализованный путь (C) потребует использования LIKE. Closure Table (D) также эффективен, но требует JOIN со служебной таблицей. Nested Sets идеальны для частого чтения поддеревьев, но очень неэффективны для вставки/перемещения узлов.
❤2👍1🔥1
4681. Онлайн викторина. Ключевая сущность — ответ участника на вопрос. В пиковые моменты (например, финальный вопрос) до 100 000 пользователей могут отправить ответ практически одновременно в течение 2-3 секунд. Какая архитектура таблицы для запи
Anonymous Quiz
23%
Одна таблица user_answers с полями: id, user_id, quiz_id, question_id, answer, created_at
39%
Та же таблица user_answers, но с горизонтальным шардингом по user_id.
22%
Использовать временную таблицу с простой структурой и без индексов
17%
Для каждого активного квиза создавать отдельную таблицу, например, quiz_12345_answers.
🤔1
👩🏫Объяснение:
Этот кейс — классический пример «проблемы горячей точки» (hotspot) при массовых одновременных вставках. Хотя варианты A и B кажутся логичными, они имеют критические недостатки в момент пика:
Вариант A (Единая таблица с автоинкрементом): BIGSERIAL создает последовательность, которая становится узким местом, так как все 100 000 вставок будут бороться за следующий ID, создавая блокировки.
Вариант B (Шардинг по user_id): Распределит нагрузку, но сложен в реализации и избыточен, если такая пиковая нагрузка возникает лишь эпизодически.
Вариант D (Таблица на квиз): Устраняет конкуренцию за одну таблицу, но требует динамического DDL (создания таблиц на лету), что усложняет логику и администрирование.
Вариант C — паттерн «Буферной таблицы» — наиболее практичное решение:
Пиковая нагрузка: Данные летят в максимально упрощенную таблицу (минимум индексов, возможно, даже без первичного ключа или с UUID). Это позволяет достичь максимальной скорости вставки.
Фоновая обработка: Отдельный воркер асинхронно вычитывает данные из буфера пачками, проводит валидацию, обогащение и записывает в основную, правильно нормализованную и проиндексированную таблицу user_answers.
Гибкость: Система легко переживает всплески, а основная БД работает в штатном режиме. Этот подход часто используется в системах обработки событий и аналитики (например, через Kafka + потребитель).
Вариант A (Единая таблица с автоинкрементом): BIGSERIAL создает последовательность, которая становится узким местом, так как все 100 000 вставок будут бороться за следующий ID, создавая блокировки.
Вариант B (Шардинг по user_id): Распределит нагрузку, но сложен в реализации и избыточен, если такая пиковая нагрузка возникает лишь эпизодически.
Вариант D (Таблица на квиз): Устраняет конкуренцию за одну таблицу, но требует динамического DDL (создания таблиц на лету), что усложняет логику и администрирование.
Вариант C — паттерн «Буферной таблицы» — наиболее практичное решение:
Пиковая нагрузка: Данные летят в максимально упрощенную таблицу (минимум индексов, возможно, даже без первичного ключа или с UUID). Это позволяет достичь максимальной скорости вставки.
Фоновая обработка: Отдельный воркер асинхронно вычитывает данные из буфера пачками, проводит валидацию, обогащение и записывает в основную, правильно нормализованную и проиндексированную таблицу user_answers.
Гибкость: Система легко переживает всплески, а основная БД работает в штатном режиме. Этот подход часто используется в системах обработки событий и аналитики (например, через Kafka + потребитель).
❤4🔥1💯1
4682. Аналитик завершил спецификацию модуля «Оплата». Какое первое действие сильнее всего повысит эффективность тестирования?
Anonymous Quiz
10%
Писать детальные тест-кейсы
70%
Провести ревью требований с QA
10%
Сгенерировать тестовые данные
10%
Составить план UAT
👩🏫Объяснение:
Наиболее критичный и эффективный вклад аналитика в этап тестирования происходит до написания кода — на стадии верификации самих требований. 🤔
Почему?
Подавляющее большинство дорогих и сложных дефектов возникают не из-за ошибки в коде, а из-за неоднозначных, противоречивых или неполных требований. Разработчик и тестировщик могут по-разному интерпретировать расплывчатую формулировку, что приводит к функционалу, не соответствующему ожиданиям бизнеса.
Ревью требований с QA решает ключевые проблемы:
✅ Тестируемость: Тестировщики помогают убедиться, что каждое требование может быть объективно проверено. Например, требование «система должна работать быстро» → превращается в «время отклика интерфейса при оформлении платежа не должно превышать 2 секунд при нагрузке до 1000 concurrent users». ⏱️
✅ Однозначность: Исключаются формулировки типа «как правило», «может быть», «удобный интерфейс».
✅ Полнота: QA, мысля сценариями, сразу видят «дыры» в логике — что должно происходить при ошибке сети? При повторном нажатии кнопки? При истечении таймаута сессии? 🕳
✅ Раннее вовлечение: Тестировщики начинают погружаться в логику системы с самого начала, что ускоряет последующее проектирование тестов.
Почему?
Подавляющее большинство дорогих и сложных дефектов возникают не из-за ошибки в коде, а из-за неоднозначных, противоречивых или неполных требований. Разработчик и тестировщик могут по-разному интерпретировать расплывчатую формулировку, что приводит к функционалу, не соответствующему ожиданиям бизнеса.
Ревью требований с QA решает ключевые проблемы:
✅ Тестируемость: Тестировщики помогают убедиться, что каждое требование может быть объективно проверено. Например, требование «система должна работать быстро» → превращается в «время отклика интерфейса при оформлении платежа не должно превышать 2 секунд при нагрузке до 1000 concurrent users». ⏱️
✅ Однозначность: Исключаются формулировки типа «как правило», «может быть», «удобный интерфейс».
✅ Полнота: QA, мысля сценариями, сразу видят «дыры» в логике — что должно происходить при ошибке сети? При повторном нажатии кнопки? При истечении таймаута сессии? 🕳
✅ Раннее вовлечение: Тестировщики начинают погружаться в логику системы с самого начала, что ускоряет последующее проектирование тестов.
❤2
4683. Веб-приложению нужно отправлять SMS через внешний сервис. Отправка долгая, но основной процесс не должен ждать. Какой способ интеграции выбрать?
Anonymous Quiz
9%
Синхронный REST API вызов
85%
Асинхронная очередь через брокер сообщений
4%
Фоновая синхронизация по расписанию
2%
Общая база данных для обмена
👩🏫Объяснение:
Выбор асинхронного взаимодействия через брокер сообщений (Kafka, RabbitMQ) — это классический паттерн для связывания слабосвязанных сервисов, где важна надежность и независимая масштабируемость.
✅ Почему B — верно:
Развязка (decoupling): Приложение и сервис работают независимо. Падение или медленная работа сервиса рассылок не «положит» основное приложение.
Гарантированная доставка: Брокер обеспечивает сохранность сообщения до его обработки.
Масштабируемость: Можно легко добавить новых потребителей события (например, сервис email-рассылок или система аналитики) без изменения кода основного приложения.
Асинхронность: Основной поток выполнения не блокируется на время отправки SMS.
❌ Почему другие варианты — хуже:
A (Синхронный REST): Создаст хрупкую прямую зависимость. При недоступности или высокой задержке сервиса SMS пользовательский опыт в основном приложении будет испорчен.
C (Периодическая синхронизация): Вносит задержку (латентность) до минуты, что неприемлемо для многих оперативных уведомлений. Также создает нагрузку на БД.
D (Shared Database): Является антипаттерном в микросервисной архитектуре, так как создает жесткую связь на уровне данных, усложняет эволюцию схемы и нарушает инкапсуляцию сервисов.
Выбор паттерна интеграции напрямую влияет на надежность (reliability), производительность (performance) и поддерживаемость (maintainability) всей системы. Аналитик должен закладывать асинхронные, событийно-ориентированные взаимодействия для фоновых и не критичных ко времени отклика операций.
✅ Почему B — верно:
Развязка (decoupling): Приложение и сервис работают независимо. Падение или медленная работа сервиса рассылок не «положит» основное приложение.
Гарантированная доставка: Брокер обеспечивает сохранность сообщения до его обработки.
Масштабируемость: Можно легко добавить новых потребителей события (например, сервис email-рассылок или система аналитики) без изменения кода основного приложения.
Асинхронность: Основной поток выполнения не блокируется на время отправки SMS.
❌ Почему другие варианты — хуже:
A (Синхронный REST): Создаст хрупкую прямую зависимость. При недоступности или высокой задержке сервиса SMS пользовательский опыт в основном приложении будет испорчен.
C (Периодическая синхронизация): Вносит задержку (латентность) до минуты, что неприемлемо для многих оперативных уведомлений. Также создает нагрузку на БД.
D (Shared Database): Является антипаттерном в микросервисной архитектуре, так как создает жесткую связь на уровне данных, усложняет эволюцию схемы и нарушает инкапсуляцию сервисов.
Выбор паттерна интеграции напрямую влияет на надежность (reliability), производительность (performance) и поддерживаемость (maintainability) всей системы. Аналитик должен закладывать асинхронные, событийно-ориентированные взаимодействия для фоновых и не критичных ко времени отклика операций.
❤1
🎯 ХОЧУ РАССКАЗАТЬ, КАК Я ИЗ БЕЗОПАСНОСТИ ПЕРЕТАЩИЛ 1000+ ЧЕЛОВЕК В СИСТЕМНЫЕ АНАЛИТИКИ
Знакомьтесь, это я — Вадим, Lead System Analyst с 8-летним опытом. Раньше я работал в кибербезопасности и ненавидел документы. Теперь я строю архитектуру FinTech-систем и учу других системному анализу.
Почему стоит послушать меня? Потому что я прошёл путь от:
📄 Требований в стиле «сделайте красиво» → к конкретным user stories с критериями приёмки
🧩 Хаотичных встреч → к управлению backlog’ом по Scrum
😱 Страха UML/BPMN → к их использованию без зубрёжки
И за 3 года я помог более 1000 ученикам сменить профессию, повысить квалификацию или систематизировать знания.
🔥 ЧТО ВЫ ПОЛУЧИТЕ НА КУРСЕ:
✔️ ОТ ТЕОРИИ К ПРАКТИКЕ: Не просто лекции, а работа с реальными ТЗ из моей практики (от e-commerce до банковских систем).
✔️ ИНСТРУМЕНТЫ, КОТОРЫЕ ПРИМЕНЯЮТСЯ В 2024: Figma для прототипов, Jira/Confluence, диаграммы в Miro, ChatGPT для аналитика.
✔️ СОБЕСЕДОВАНИЯ БЕЗ ПАНИКИ: Разбор 20+ реальных кейсов с собесов от Yandex, Tinkoff, VK + симуляция интервью.
✔️ ПОДДЕРЖКА И НЕТВОРКИНГ: Закрытый чат с коллегами, разбор домашних заданий, ответы на вопросы в течение 6 месяцев после курса.
📈 РЕЗУЛЬТАТЫ ВЫПУСКНИКОВ:
«С нуля вышел на зарплату 110к через 4 месяца после курса» (история Максима)
«Смогла перейти с позиции тестировщика на аналитика в одном продуктовой команде» (история Анны)
«Систематизировал хаос в требованиях, теперь говорю с разработчиками на одном языке» (история Дмитрия)
💬 ЧТОБЫ ЗАБРОНИРОВАТЬ МЕСТО ИЛИ УЗНАТЬ ПОДРОБНОСТИ:
Переходи по ссылке👇
https://bitbitgo.by/
Знакомьтесь, это я — Вадим, Lead System Analyst с 8-летним опытом. Раньше я работал в кибербезопасности и ненавидел документы. Теперь я строю архитектуру FinTech-систем и учу других системному анализу.
Почему стоит послушать меня? Потому что я прошёл путь от:
📄 Требований в стиле «сделайте красиво» → к конкретным user stories с критериями приёмки
🧩 Хаотичных встреч → к управлению backlog’ом по Scrum
😱 Страха UML/BPMN → к их использованию без зубрёжки
И за 3 года я помог более 1000 ученикам сменить профессию, повысить квалификацию или систематизировать знания.
🔥 ЧТО ВЫ ПОЛУЧИТЕ НА КУРСЕ:
✔️ ОТ ТЕОРИИ К ПРАКТИКЕ: Не просто лекции, а работа с реальными ТЗ из моей практики (от e-commerce до банковских систем).
✔️ ИНСТРУМЕНТЫ, КОТОРЫЕ ПРИМЕНЯЮТСЯ В 2024: Figma для прототипов, Jira/Confluence, диаграммы в Miro, ChatGPT для аналитика.
✔️ СОБЕСЕДОВАНИЯ БЕЗ ПАНИКИ: Разбор 20+ реальных кейсов с собесов от Yandex, Tinkoff, VK + симуляция интервью.
✔️ ПОДДЕРЖКА И НЕТВОРКИНГ: Закрытый чат с коллегами, разбор домашних заданий, ответы на вопросы в течение 6 месяцев после курса.
📈 РЕЗУЛЬТАТЫ ВЫПУСКНИКОВ:
«С нуля вышел на зарплату 110к через 4 месяца после курса» (история Максима)
«Смогла перейти с позиции тестировщика на аналитика в одном продуктовой команде» (история Анны)
«Систематизировал хаос в требованиях, теперь говорю с разработчиками на одном языке» (история Дмитрия)
💬 ЧТОБЫ ЗАБРОНИРОВАТЬ МЕСТО ИЛИ УЗНАТЬ ПОДРОБНОСТИ:
Переходи по ссылке
https://bitbitgo.by/
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡️ Здравствуйте, Дорогие подписчики!
Представляем вашему вниманию подборку полезных каналов в сфере «Наука и образование» 🔥
Будем очень рады, если вы найдете для себя, что-нибудь полезное.
❗️Ссылка на папку:
https://t.me/addlist/sYIYFfnHbeExZDc6
Представляем вашему вниманию подборку полезных каналов в сфере «Наука и образование» 🔥
Будем очень рады, если вы найдете для себя, что-нибудь полезное.
❗️Ссылка на папку:
https://t.me/addlist/sYIYFfnHbeExZDc6
👍1
4684. Команда разрабатывает мобильное приложение доставки еды. При оформлении заказа нужно:
Создать заказ в БД
Отправить пуш-уведомление курьеру Обновить баланс бонусов клиента Как правильно спроектировать интеграцию?
Создать заказ в БД
Отправить пуш-уведомление курьеру Обновить баланс бонусов клиента Как правильно спроектировать интеграцию?
Anonymous Quiz
52%
Создать заказ → сразу ответить клиенту → асинхронно выполнить пуш и бонусы
13%
Выполнить всё синхронно в одной транзакции: заказ → пуш → бонусы
11%
Сначала отправить пуш, после успеха создать заказ и начислить бонусы
23%
Использовать распределенную транзакцию (2PC) для всех трех операций
👩🏫Объяснение:
Паттерн «Асинхронное завершение фоновых задач» критически важен для пользовательского опыта. Клиент ждет подтверждения заказа мгновенно, а технические детали (уведомление курьера, бонусы) могут быть выполнены после ответа.
Почему B — правильно:
✅ Скорость ответа клиенту — главное требование выполнено
✅ Устойчивость к сбоям — падение сервиса пушек не сорвет оформление заказа
✅ Масштабируемость — фоновые задачи можно обрабатывать в отдельных очередях
✅ Простота реализации — событие «Заказ создан» запускает асинхронные процессы
Почему другие варианты — ошибка:
❌ B — клиент будет ждать все 30 секунд отправки пуша
❌ C — риск потерять заказ, если пуш отправлен, а создание заказа упало
❌ D — избыточная сложность, блокировки, проблемы с производительностью
Ключевой вывод для аналитика: Разделяйте операции на критические для пользователя (требующие немедленного ответа) и фоновые (которые можно выполнить асинхронно). Всегда проектируйте интеграции с учетом реальной производительности внешних систем .
Почему B — правильно:
✅ Скорость ответа клиенту — главное требование выполнено
✅ Устойчивость к сбоям — падение сервиса пушек не сорвет оформление заказа
✅ Масштабируемость — фоновые задачи можно обрабатывать в отдельных очередях
✅ Простота реализации — событие «Заказ создан» запускает асинхронные процессы
Почему другие варианты — ошибка:
❌ B — клиент будет ждать все 30 секунд отправки пуша
❌ C — риск потерять заказ, если пуш отправлен, а создание заказа упало
❌ D — избыточная сложность, блокировки, проблемы с производительностью
Ключевой вывод для аналитика: Разделяйте операции на критические для пользователя (требующие немедленного ответа) и фоновые (которые можно выполнить асинхронно). Всегда проектируйте интеграции с учетом реальной производительности внешних систем
🤔2
4685. Вы проектируете функционал "Черный список" для маркетплейса. Нужно хранить связи "продавец → заблокированный покупатель" и быстро проверять, заблокирован ли конкретный покупатель у конкретного продавца. Какой тип первичного ключа будет оптимальным?
Anonymous Quiz
13%
UUID
6%
BIGINT AUTO_INCREMENT
72%
Составной ключ из ID продавца и ID покупателя (seller_id, buyer_id)
10%
SHA256 хэш от конкатенации ID продавца и покупателя
👩🏫Объяснение:
Данный кейс требует решения двух задач:
1️⃣ Гарантировать уникальность комбинации "продавец-покупатель" (один покупатель не может быть дважды в черном списке у того же продавца).
2️⃣ Обеспечить максимально быструю проверку наличия конкретной пары.
✅ Составной первичный ключ (seller_id, buyer_id) решает обе задачи идеально:
Уникальность обеспечивается на уровне СУБД автоматически.
Скорость поиска: Запрос SELECT 1 FROM blacklist WHERE seller_id = X AND buyer_id = Y будет выполняться по первичному ключу (кластеризованному индексу), что является самой быстрой операцией.
Эффективное использование: Ключ соответствует самому частому сценарию использования — проверка по конкретной паре.
❌ Почему другие варианты хуже:
A (UUID): Случайные значения приводят к сильной фрагментации индексов и неэффективному использованию кэша. Запрос все равно потребует отдельного UNIQUE-ограничения на пару ID.
B (AUTO_INCREMENT): Не гарантирует уникальность логической пары без дополнительного UNIQUE-ограничения. Также при горизонтальном масштабировании (шардинге) могут возникнуть сложности.
D (SHA256): Избыточная вычислительная нагрузка при вставке, те же проблемы с фрагментацией, что и у UUID.
Архитектурный бонус: При таком дизайне легко добавить шардинг по seller_id, если количество продавцов будет огромным. Данные одного продавца будут физически сгруппированы, что улучшит производительность.
1️⃣ Гарантировать уникальность комбинации "продавец-покупатель" (один покупатель не может быть дважды в черном списке у того же продавца).
2️⃣ Обеспечить максимально быструю проверку наличия конкретной пары.
✅ Составной первичный ключ (seller_id, buyer_id) решает обе задачи идеально:
Уникальность обеспечивается на уровне СУБД автоматически.
Скорость поиска: Запрос SELECT 1 FROM blacklist WHERE seller_id = X AND buyer_id = Y будет выполняться по первичному ключу (кластеризованному индексу), что является самой быстрой операцией.
Эффективное использование: Ключ соответствует самому частому сценарию использования — проверка по конкретной паре.
❌ Почему другие варианты хуже:
A (UUID): Случайные значения приводят к сильной фрагментации индексов и неэффективному использованию кэша. Запрос все равно потребует отдельного UNIQUE-ограничения на пару ID.
B (AUTO_INCREMENT): Не гарантирует уникальность логической пары без дополнительного UNIQUE-ограничения. Также при горизонтальном масштабировании (шардинге) могут возникнуть сложности.
D (SHA256): Избыточная вычислительная нагрузка при вставке, те же проблемы с фрагментацией, что и у UUID.
Архитектурный бонус: При таком дизайне легко добавить шардинг по seller_id, если количество продавцов будет огромным. Данные одного продавца будут физически сгруппированы, что улучшит производительность.
4686. При проектировании интеграции CRM и ERP-системы возник спор. Нужно передавать обновлённые данные о клиентах. Какой способ синхронизации оптимален?
Anonymous Quiz
11%
Прямые синхронные API-вызовы при каждом изменении в CRM
72%
Асинхронная передача событий через шину (message broker) с гарантией доставки
6%
Ежечасный batch-экспорт всех данных из CRM и полная перезапись в ERP
12%
Общая база данных, доступная обоим системам
✅ Вариант B решает задачу оптимально:
1. Актуальность в пределах задержки: События обрабатываются почти в реальном времени, укладываясь в 15 минут.
2. Консистентность и надёжность: Шина (Kafka, RabbitMQ) гарантирует доставку каждого сообщения. При сбое ERP данные не теряются, а накапливаются в очереди.
3. Слабая связанность и масштабируемость: Системы не зависят друг от друга напрямую. Можно добавить новых потребителей событий (например, систему аналитики) без изменения CRM.
❌ Почему другие варианты не подходят:
· A (Синхронные вызовы): Создаст хрупкую связь. При недоступности ERP пользователи CRM получат ошибки, а бизнес-процессы встанут. 1000 вызовов в час — значительная нагрузка.
· C (Batch-перезапись): Нарушает требование к актуальности (данные могут устаревать на час). Полная перезапись создает избыточную нагрузку и риск конфликтов при одновременном обновлении.
· D (Общая БД): Антипаттерн интеграции. Нарушает инкапсуляцию систем, создает монолит, усложняет развитие и масштабирование.
💡 Ключевой вывод для аналитика:
При выборе паттерна интеграции оценивайте критичность консистентности vs. допустимую задержку. Асинхронная шина с гарантированной доставкой — золотая середина для сценариев, где допустима небольшая задержка, но недопустима потеря данных или прямая зависимость систем.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2