4658. Вы анализируете проблему: в системе бронирования после оплаты иногда создается билет, но статус заказа не обновляется с «Ожидает оплаты» на «Оплачен». Какой механизм БД должен был гарантировать целостность этой операции?
Anonymous Quiz
5%
FOREIGN KEY
25%
TRIGGER
70%
TRANSACTION
0%
VIEW
👩🏫Объяснение:
Это прямая иллюстрация принципа атомарности из ACID. Операция «списать деньги + создать билет + обновить статус заказа» должна выполняться как единая транзакция. Если любой шаг fails, ROLLBACK откатывает всё. Без транзакции при сбое после создания билета возникает рассогласование. FOREIGN KEY (A) гарантирует целостность связей, TRIGGER (B) — автоматизацию действий, VIEW (D) — виртуальное представление, но ничто из этого не обеспечивает атомарность группы запросов.
4659. При слиянии двух компаний необходимо объединить данных о клиентах из двух независимых БД. В обеих есть таблицы users. Поля частично совпадают (email, phone), но ID-шники разные. Какой процесс НЕ является частью решения этой задачи?
Anonymous Quiz
16%
ETL (Extract, Transform, Load)
8%
Дедупликация записей
64%
Репликация Master-Slave
12%
Сопоставление (Matching) сущностей
👩🏫Объяснение:
Миграция и консолидация данных — сложный практический кейс. Ключевые этапы: извлечение данных из источников, трансформация (приведение к общей схеме), сопоставление (определение, что записи из разных БД относятся к одному клиенту), дедупликация (устранение дублей) и, наконец, загрузка в целевую систему. Это и есть ETL-процесс. Репликация Master-Slave — это механизм копирования данных из основной БД в резервную для отказоустойчивости или чтения, но не для слияния двух разных схем. Она не решает проблему консолидации.
4660. В системе управления складом есть таблица StockMovements с миллионами записей о перемещениях товаров. Для формирования отчета нужно часто вычислять сумму приходов и расходов. Что будет самым эффективным решением для ускорения таких отчетов?
Anonymous Quiz
33%
Создать материализованное представление (materialized view), которое ежедневно пересчитывает остатки
15%
Каждый раз выполнять агрегирующий запрос с SUM() и GROUP BY, добавив индекс на product_id и date
37%
Завести таблицу CurrentStock, которую обновлять триггером при каждой операции движения.
15%
Перейти на колоночную СУБД (например, ClickHouse) для хранения исторических движений.
❤1
👩🏫Объяснение:
Это классическая задача баланса между оперативными транзакциями и аналитическими запросами. Материализованное представление — это «снимок» результата запроса, физически сохраненный в БД, который можно периодически обновлять (например, ночью). Это идеально подходит для ежедневных отчетов, где не нужны данные в реальном времени. Вариант B неэффективен при большом объеме данных, вариант C усложнит транзакции и может стать узким местом, а вариант D — слишком радикальное архитектурное изменение для одной задачи.
4661. При проектировании высоконагруженного чата вы решили хранить сообщения в реляционной БД.. Какой подход к первичному ключу таблицы Messages наиболее оптимален?
Anonymous Quiz
18%
INT AUTO_INCREMENT (последовательный числовой)
23%
UUID (случайный универсальный идентификатор)
34%
BIGINT, генерируемый распределенной Snowflake-алгоритмом
25%
Составной ключ (dialog_id, created_at)
👩🏫Объяснение:
Для высоконагруженных систем с горизонтальным масштабированием (шардингом) важны распределенные и временно-упорядоченные идентификаторы. AUTO_INCREMENT (A) создает горячую точку (hotspot) на одном сервере и не подходит для шардинга. UUID (B) случайный, что убивает локальность данных и приводит к фрагментации индексов, ухудшая производительность вставки и выборки. Snowflake-алгоритм (C) генерирует монотонно возрастающие ID, которые упорядочены по времени и уникальны в распределенной среде — это оптимально для шардинга и кластеризованных индексов. Составной ключ (D) усложняет связи и не является глобально уникальным.
4662. В legacy-системе обнаружилась критическая проблема: из-за ошибки в коде в таблицу Transactions были внесены некорректные данные за последние 3 часа. Как можно восстановить целостность данных с минимальными потерями?
Anonymous Quiz
5%
Восстановить всю БД из утреннего бэкапа.
71%
Использовать Point-in-Time Recovery (PITR), если включено ведение журнала транзакций (WAL).
9%
Вручную откатить некорректные изменения, написав обратные UPDATE-запросы.
15%
Запустить процедуру логического восстановления из бинарного лога (binary log).
👩🏫Объяснение:
Этот кейс проверяет знание механизмов восстановления. Point-in-Time Recovery (PITR) — единственный способ откатить изменения до определенного момента без потери всех данных, накопленных после бэкапа. Он требует, чтобы был включен журнал транзакций (WAL в PostgreSQL, бинарный лог в MySQL). Восстановление из полного бэкапа (A) откатит и все валидные данные за день. Ручные правки (C) рискованны и ненадежны. Вариант D близок к B, но бинарный лог — это именно механизм PITR в MySQL, однако формулировка B общая и покрывает разные СУБД.
4663. Вы проектируете систему сбора телеметрии с IoT-устройств. Устройства отправляют 100 000 событий в секунду. Нужно писать события с минимальной задержкой и раз в час строить агрегационные отчеты. Какую стратегию хранения выбрать на первом этапе?
Anonymous Quiz
15%
Писать сразу в колоночную БД (ClickHouse) с высокой степенью сжатия.
11%
Писать в реляционную БД (PostgreSQL) в таблицу с партиционированием по часам.
55%
Писать в шину событий (Kafka), а оттуда batch-ами загружать в хранилище данных.
19%
Писать в документную БД (MongoDB), используя TTL-индексы для автоматического удаления старых данных.
👩🏫Объяснение:
При таком объеме и требовании к минимальной задержке записи, прямая запись в аналитическое или транзакционное хранилище (A, B) создаст чрезмерную нагрузку. Правильный паттерн — буферизация через шину событий (Kafka). Она гарантирует прием высокого потока, обеспечивает отказоустойчивость и позволяет затем гибко направлять данные в разные системы (в холодное хранилище, в real-time агрегатор и т.д.). Вариант D не решает проблему аналитической обработки и может стать дорогим из-за объема.
4664. В финансовом приложении есть строгое требование: нельзя удалять данные об операциях. При этом пользователь может отозвать согласие на обработку персональных данных (GDPR). Как технически реализовать «забывание» пользователя?
Anonymous Quiz
4%
Физически удалить строки с данными пользователя, предварительно сделав экспорт для регулятора.
36%
Помечать записи как удаленные (is_deleted = true), скрывая их из интерфейса.
48%
Провести криптографическое обезличивание (шифрование) персональных полей с уничтожением ключа.
12%
Перенести все записи пользователя в отдельный архивный сервис с ограниченным доступом.
👩🏫Объяснение:
Этот кейс на стыке compliance и архитектуры. Требования: 1) Неизменяемость операций (нужны для аудита), 2) Право на забвение. Физическое удаление (A) нарушает первое. Soft-delete (B) не соответствует GDPR, так как данные остаются в исходном виде. Архивация (D) не решает проблему обезличивания. Криптографическое удаление (crypto-shredding) — отраслевой best practice: чувствительные поля (ФИО, email) шифруются отдельным ключом на пользователя; при удалении ключ уничтожается, делая данные нечитаемыми, при этом неизменяемые метаданные операции (сумма, время) остаются.
👍2