4644. Вы делаете систему для агрегации данных о транспорте. Десятки тысяч устройств шлют координаты каждые 10 секунд. Нужно сохранять их, строить маршруты и считать метрики в реальном времени. Какую технологию выберете для приема потока данных?
Anonymous Quiz
4%
Классическая реляционная БД (PostgreSQL) с REST API.
61%
Потоковая платформа (Apache Kafka, Apache Pulsar).
20%
Хранилище файлов (S3) с загрузкой пакетов по протоколу SFTP.
15%
Очередь сообщений (RabbitMQ) в режиме «очередь задач».
👩🏫Объяснение:
Это типичный use case для high-throughput потоковых данных. Kafka создана для приема, буферизации и распределения огромных потоков событий с малой задержкой. REST + PG не справятся с нагрузкой и частотой записей. RabbitMQ — хорошая очередь, но не оптимизирована для long-running потоковой обработки и хранения логов. Пакетная загрузка в S3 не соответствует требованию «реального времени».
4645. При обновлении заказа в системе «Заказы» нужно уведомить систему «Доставка». Очень важно не потерять ни одного события, даже если «Доставка» легла на техобслуживание. Какой паттерн гарантирует доставку?
Anonymous Quiz
1%
HTTP-колбэк с 3 ретраями.
11%
Периодический опрос «Доставки» на наличие новых заказов.
11%
Запись события в локальный лог-файл системы «Заказы».
76%
Подтвержденное получение через persistent очередь сообщений.
👩🏫Объяснение:
Ключ — гарантия доставки при нестабильности получателя. Очередь (брокер) надежно хранит сообщение, пока система-получатель не обработает его и не подтвердит (ACK). Без подтверждения сообщение возвращается в очередь. HTTP-ретраи не помогут, если получатель недоступен долго. Лог-файл не является механизмом интеграции. Опрос неэффективен и создает задержки. Только очередь обеспечивает надежный асинхронный обмен.
4646. Вы проектируете схему БД для интернет-магазина. Товар может принадлежать нескольким категориям, и каждая категория может содержать множество товаров. Как правильно смоделировать связь «многие ко многим»?
Anonymous Quiz
1%
Добавить поле category_id в таблицу products.
8%
Добавить поле product_id в таблицу categories.
88%
Создать отдельную таблицу-связку product_categories с внешними ключами.
3%
Хранить список ID категорий в текстовом поле товара.
👩🏫Объяснение:
Связь «многие ко многим» не может быть реализована через одно внешнее ключевое поле в одной из таблиц. Это нарушит нормализацию и приведет к проблемам с целостностью и обновлением данных. Отдельная таблица product_categories хранит пары (product_id, category_id), что позволяет гибко добавлять и удалять связи. Хранение списков в текстовом поле (вариант 4) — это антипаттерн, делающий выборку и агрегацию крайне неэффективной.
4647. В системе участились жалобы на медленную выборку пользователей по email. Поле email уже проиндексировано. В чем может быть причина, если запрос ищет по полному совпадению (WHERE email = 'user@domain.com')?
Anonymous Quiz
10%
Индексы не работают для текстовых полей
62%
В таблице накопилось большое количество «мертвых» записей (bloat) из-за частых обновлений и удалений
5%
Необходимо сменить тип поля с VARCHAR на TEXT
22%
Следует создать дополнительный индекс по полю id
👩🏫Объяснение:
Индексы по текстовым полям прекрасно работают для операций равенства. Однако, если в таблице интенсивно происходит UPDATE или DELETE, физические страницы индекса и таблицы фрагментируются. Это заставляет СУБД читать много пустых или полупустых страниц, чтобы найти нужные строки. Решением является периодическая процедура обслуживания (например, VACUUM FULL в PostgreSQL или перестройка индекса). Смена типа данных или лишний индекс не решат эту проблему производительности.
4648. Для нового функционала аналитики необходимо хранить иерархическую структуру отделов компании с неограниченным уровнем вложенности. Какая модель хранения будет наиболее эффективной для частых запросов «найти всех потомков отдела X»?
Anonymous Quiz
56%
Использовать рекурсивные запросы (CTE) с таблицей, где есть поля id и parent_id.
7%
Хранить полный путь в текстовом поле (например, 1.5.12.34).
20%
Создать отдельную таблицу связей для каждого уровня вложенности.
17%
Использовать документоориентированную NoSQL БД, отказавшись от иерархии.
👩🏫Объяснение:
Это классический и гибкий подход для работы с иерархиями в реляционных БД. Поле parent_id формирует связь, а рекурсивный запрос позволяет обходить дерево в глубину или ширину. Хранение пути (вариант 2) уязвимо к изменениям и сложно поддерживается. Создание таблиц под каждый уровень (3) не подходит для неограниченной вложенности. Выбор NoSQL (4) должен быть обоснован другими требованиями, а не только иерархией. CTE — стандартное и поддерживаемое решение.
4649. Вы анализируете требования к системе кэширования сессий пользователей. Данные: простые ключ-значение, время жизни — 15 минут, объем данных огромен, доступ должен быть мгновенным. Какую технологию предпочтете?
Anonymous Quiz
82%
Использовать специализированное in-memory хранилище, такое как Redis.
8%
Создать таблицу в основной реляционной PostgreSQL БД.
3%
Запись сессий в файлы на диске.
7%
Использовать докуменную БД MongoDB.
👩🏫Объяснение:
Ключевые слова здесь: «время жизни», «ключ-значение», «мгновенный доступ». Redis создан именно для таких сценариев: это резидентная (in-memory) БД, что обеспечивает микросекундную скорость отклика. Она имеет встроенные механизмы TTL (время жизни данных). Основная реляционная БД (2) будет излишне нагружена и медленна для этой задачи. Файлы (3) и MongoDB (4) не обеспечат требуемой скорости и удобства управления TTL.
4650. При проектировании БД для системы заказов вы столкнулись с требованием: «Стоимость заказа должна всегда равняться сумме стоимостей его позиций». Где должна быть реализована эта бизнес-логика?
Anonymous Quiz
19%
В отдельном микросервисе, который валидирует заказы.
11%
В логике фронтенда, перед отправкой данных.
9%
Только в коде backend-приложения.
61%
На уровне БД, с помощью триггера, который пересчитывает и обновляет итог.
👩🏫Объяснение:
Это требование относится к целостности данных (consistency). Если логика находится только в backend-коде (2), то прямой доступ к БД в обход приложения (например, для исправлений) нарушит это правило. Триггер гарантирует, что правило выполняется всегда, при любом изменении данных. Это самый надежный уровень защиты бизнес-инварианта. Хотя дублирование проверок в коде приложения — это good practice, основная гарантия должна быть со стороны хранилища данных.