4649. Вы анализируете требования к системе кэширования сессий пользователей. Данные: простые ключ-значение, время жизни — 15 минут, объем данных огромен, доступ должен быть мгновенным. Какую технологию предпочтете?
Anonymous Quiz
79%
Использовать специализированное in-memory хранилище, такое как Redis.
10%
Создать таблицу в основной реляционной PostgreSQL БД.
2%
Запись сессий в файлы на диске.
9%
Использовать докуменную БД MongoDB.
👩🏫Объяснение:
Ключевые слова здесь: «время жизни», «ключ-значение», «мгновенный доступ». Redis создан именно для таких сценариев: это резидентная (in-memory) БД, что обеспечивает микросекундную скорость отклика. Она имеет встроенные механизмы TTL (время жизни данных). Основная реляционная БД (2) будет излишне нагружена и медленна для этой задачи. Файлы (3) и MongoDB (4) не обеспечат требуемой скорости и удобства управления TTL.
4650. При проектировании БД для системы заказов вы столкнулись с требованием: «Стоимость заказа должна всегда равняться сумме стоимостей его позиций». Где должна быть реализована эта бизнес-логика?
Anonymous Quiz
18%
В отдельном микросервисе, который валидирует заказы.
12%
В логике фронтенда, перед отправкой данных.
11%
Только в коде backend-приложения.
59%
На уровне БД, с помощью триггера, который пересчитывает и обновляет итог.
👩🏫Объяснение:
Это требование относится к целостности данных (consistency). Если логика находится только в backend-коде (2), то прямой доступ к БД в обход приложения (например, для исправлений) нарушит это правило. Триггер гарантирует, что правило выполняется всегда, при любом изменении данных. Это самый надежный уровень защиты бизнес-инварианта. Хотя дублирование проверок в коде приложения — это good practice, основная гарантия должна быть со стороны хранилища данных.
4651. Для хранения и сложного поиска по полуструктурированным логам действий пользователей (JSON с разными наборами полей) лучше всего подходит:
Anonymous Quiz
13%
Реляционная БД с заранее определенными колонками.
74%
Документоориентированная NoSQL БД, такая как MongoDB или Elasticsearch.
7%
Классическая SQL БД с хранением JSON в текстовом поле.
6%
Графовая база данных.
👩🏫Объяснение:
Полуструктурированные данные с меняющейся схемой — их родная стихия. Такие БД позволяют хранить каждый документ (лог) с его уникальным набором полей и эффективно индексировать и искать по вложенным атрибутам. Elasticsearch дополнительно дает мощные полнотекстовые и аналитические возможности. Реляционная БД (1) будет требовать сложных миграций при изменении структуры логов, а хранение JSON в текстовом поле (3) резко снизит возможности поиска. Графовая БД (4) предназначена для других задач.
4652. При частых операциях JOIN между очень большими таблицами Orders и Customers производительность падает. Какая оптимизация будет наиболее эффективной?
Anonymous Quiz
0%
Увеличить объем оперативной памяти на сервере БД.
7%
Отказаться от использования JOIN и делать два последовательных запроса.
54%
Денормализовать данные: добавить часто запрашиваемые поля из Customers прямо в таблицу Orders.
40%
Создать материализованное представление (Materialized View) с уже объединенными данными.
👩🏫Объяснение:
Денормализация — это сознательное нарушение нормальных форм для увеличения скорости чтения, путем исключения дорогостоящего JOIN. Материализованное представление — это «снимок» результата JOIN, который периодически обновляется. Это классический trade-off между скоростью чтения и актуальностью данных. Увеличение памяти может помочь, но не решит проблему кардинально. Два последовательных запроса (3) часто работают еще медленнее.
4653. Вы аналитик в стартапе по доставке еды. При проектировании БД для сущности «Заказ» выяснилось, что один заказ может содержать несколько блюд, а одно блюдо может фигурировать в разных заказах. Как правильно смоделировать эту связь?
Anonymous Quiz
2%
Добавить в таблицу Order повторяющиеся столбцы Dish_1, Dish_2 и т.д.
13%
В таблицу Order добавить столбец Dish_ID, который будет ссылаться на блюдо.
74%
Создать две таблицы: Order и Dish, и связующую таблицу Order_Dish с order_id и dish_id.
11%
Хранить список ID блюд в виде JSON-массива в одном столбце dishes таблицы Order.
❤1
👩🏫Объяснение:
Это классический пример связи «многие ко многим» (many-to-many). Один заказ содержит много блюд, одно блюдо входит в многие заказы. Корректная и нормализованная модель в реляционной БД — создание связующей (junction) таблицы. Вариант A нарушает 1НФ (повторяющиеся группы), B — подразумевает связь «один ко многим» (одно блюдо в заказе), а D (хранение массива) хоть и используется в NoSQL, в реляционной БД усложнит агрегацию, отчетность и целостность данных на уровне СУБД.
4654. В системе электронных билетов пользователи жалуются на медленную загрузку «Истории заказов». Страница формируется запросом с JOIN 4-х таблиц и сортировкой по дате. Индексы расставлены на первичные ключи. Что, скорее всего, ускорит выборку данных?
Anonymous Quiz
36%
Добавить составной индекс на поля, используемые в условиях WHERE и ORDER BY.
4%
Увеличить размер оперативной памяти на сервере БД.
55%
Денормализовать данные, создав таблицу User_Order_History, которая обновляется триггерами.
5%
Разделить (shard) базу данных по первым буквам email пользователей.
👩🏫Объяснение:
Частая причина медленных запросов — отсутствие правильных индексов под конкретную нагрузку. Индексы на PK ускоряют поиск по ID, но не по условиям WHERE или сортировке. Составной индекс, покрывающий фильтрацию и сортировку, кардинально ускорит запрос. Варианты B, C, D — это более тяжелые архитектурные изменения, которые уместны, если оптимизация индексов и запросов уже не помогает. Начинать всегда нужно с анализа плана запроса (EXPLAIN) и индексов.
Частая причина медленных запросов — отсутствие правильных индексов под конкретную нагрузку. Индексы на PK ускоряют поиск по ID, но не по условиям WHERE или сортировке. Составной индекс, покрывающий фильтрацию и сортировку, кардинально ускорит запрос. Варианты B, C, D — это более тяжелые архитектурные изменения, которые уместны, если оптимизация индексов и запросов уже не помогает. Начинать всегда нужно с анализа плана запроса (EXPLAIN) и индексов.
4655. При интеграции с внешним API платежной системы вам необходимо ежедневно сохрачать полный JSON-ответ от них для аудита и отладки. Структура ответа сложная и часто меняется. Какой подход к хранению в БД наиболее рационален?
Anonymous Quiz
30%
Создать реляционную схему, максимально соответствующую JSON, и парсить данные в нее.
48%
Хранить «как есть» в поле типа JSONB (в PostgreSQL) или аналогичном.
18%
Сохранять JSON в виде простого текста (TEXT / CLOB).
4%
Не хранить в БД, а писать сразу в файлы на диске.
👩🏫Объяснение:
Это практический кейс, где нужна гибкость схемы. Современные реляционные СУБД (PostgreSQL, MySQL) имеют специализированные JSON-типы (JSONB), которые позволяют хранить, запрашивать и индексировать данные внутри JSON-документа. Это намного эффективнее, чем хранить JSON как простой текст (C), и гибче, чем создавать жесткую реляционную схему (A), которую придется менять при каждом обновлении API. Прямое сохранение в файлы (D) лишает вас преимуществ транзакционности и SQL-запросов.