👩🏫Объяснение:
Когда требования к поиску выходят за рамки базовых возможностей реляционных СУБД, используется специализированный поисковый движок. Elasticsearch/Solr построены на инвертированных индексах, созданных именно для задач:
* Полнотекстового поиска со стеммингом, синонимами, обработкой омонимов.
* Нечеткого поиска (fuzzy).
* Сложного ранжирования (relevance scoring) на основе TF-IDF, BM25.
* Масштабирования и отказоустойчивости за счет распределенной кластеризации.
«Подкручивание» существующей БД (A, D) дает лишь временный и ограниченный эффект. Кастомная реализация (B) неоправданно сложна и не будет соответствовать по качеству и производительности готовым решениям.
* Полнотекстового поиска со стеммингом, синонимами, обработкой омонимов.
* Нечеткого поиска (fuzzy).
* Сложного ранжирования (relevance scoring) на основе TF-IDF, BM25.
* Масштабирования и отказоустойчивости за счет распределенной кластеризации.
«Подкручивание» существующей БД (A, D) дает лишь временный и ограниченный эффект. Кастомная реализация (B) неоправданно сложна и не будет соответствовать по качеству и производительности готовым решениям.
4677. Таблица votes потенциально может расти на миллиарды строк. Критически важна скорость проверки, голосовал ли пользователь. Какой первичный ключ для таблицы votes будет оптимальным?
Anonymous Quiz
15%
id BIGSERIAL PRIMARY KEY (автоинкремент).
42%
Составной первичный ключ (user_id, entity_type, entity_id).
20%
PRIMARY KEY (entity_type, entity_id, user_id).
23%
uuid PRIMARY KEY.
👩🏫Объяснение:
Здесь важны две вещи: гарантия уникальности комбинации «пользователь-сущность» и скорость проверки этой уникальности при вставке. Составной первичный ключ (user_id, entity_type, entity_id) (B) идеально решает обе задачи:
1. Он на уровне БД гарантирует, что дубликат невозможен.
2. Запрос SELECT 1 FROM votes WHERE user_id = ? AND entity_type = ? AND entity_id = ? для проверки будет выполняться очень быстро, используя поиск по первичному ключу (т.е. по кластеризованному индексу).
Порядок колонок важен: если чаще проверяют по user_id, он должен быть первым. Ключ из варианта C тоже рабочий, но оптимизирован для поиска всех голосов за сущность, что менее частый сценарий. Автоинкремент (A) и UUID (D) не предотвращают дублирование логических записей без отдельного UNIQUE-ограничения.
1. Он на уровне БД гарантирует, что дубликат невозможен.
2. Запрос SELECT 1 FROM votes WHERE user_id = ? AND entity_type = ? AND entity_id = ? для проверки будет выполняться очень быстро, используя поиск по первичному ключу (т.е. по кластеризованному индексу).
Порядок колонок важен: если чаще проверяют по user_id, он должен быть первым. Ключ из варианта C тоже рабочий, но оптимизирован для поиска всех голосов за сущность, что менее частый сценарий. Автоинкремент (A) и UUID (D) не предотвращают дублирование логических записей без отдельного UNIQUE-ограничения.
4678. Вы обнаружили, что в таблице events с временными рядами 99% запросов обращаются только к данным за последние 7 дней. Таблица содержит данные за 5 лет. Какое изменение структуры хранения даст максимальный эффект ?
Anonymous Quiz
62%
Создать партиционирование таблицы по диапазону дат (например, по дням или неделям).
14%
Добавить индекс на поле с датой, включив в него все часто запрашиваемые колонки.
3%
Запустить процедуру полной перестройки (REINDEX) всех индексов таблицы.
21%
Регулярно (раз в неделю) удалять старые данные, перемещая их в архивную таблицу.
👩🏫Объяснение:
Партиционирование — наиболее фундаментальное и эффективное решение для временных рядов с ярко выраженным паттерном доступа к «горячим» (свежим) данным. Оно позволяет:
* Резко уменьшить объем сканируемых данных: оптимизатор запросов будет обращаться только к партициям за последние 7 дней (партициональная прунинг).
* Упростить управление жизненным циклом: удаление старых данных (DROP PARTITION) — мгновенная и дешевая операция.
* Улучшить производительность обслуживания: операции VACUUM, REINDEX можно выполнять точечно на устаревших партициях.
Создание покрывающего индекса (B) или его перестройка (C) могут помочь, но не решат проблему работы с огромной неделимой таблицей. Ручное перемещение данных (D) — это, по сути, «ручное» партиционирование, но менее эффективное и встроенное в СУБД.
* Резко уменьшить объем сканируемых данных: оптимизатор запросов будет обращаться только к партициям за последние 7 дней (партициональная прунинг).
* Упростить управление жизненным циклом: удаление старых данных (DROP PARTITION) — мгновенная и дешевая операция.
* Улучшить производительность обслуживания: операции VACUUM, REINDEX можно выполнять точечно на устаревших партициях.
Создание покрывающего индекса (B) или его перестройка (C) могут помочь, но не решат проблему работы с огромной неделимой таблицей. Ручное перемещение данных (D) — это, по сути, «ручное» партиционирование, но менее эффективное и встроенное в СУБД.
4679. Какую репликацию нужно настроить для гарантии того, что реплика всегда имеет актуальные данные.
Anonymous Quiz
54%
Синхронную репликацию (Synchronous Replication).
31%
Асинхронную репликацию (Asynchronous Replication) с более быстрым сетевым оборудованием.
4%
Логическую репликацию (Logical Replication).
11%
Каскадную репликацию (Cascade Replication).
👩🏫Объяснение:
Синхронная репликация гарантирует, что транзакция на мастере будет считаться завершенной (получит COMMIT) только после того, как изменения будут записаны не только на мастер, но и на реплику (или реплики). Это обеспечивает нулевое отставание (RPO=0) для выбранных реплик и защиту от потери данных. Недостаток — повышенная задержка записи на мастер и его остановка, если реплика «упала». Асинхронная репликация (B) всегда имеет лаг. Логическая (C) и каскадная (D) репликации — это варианты реализации, которые сами по себе могут быть как синхронными, так и асинхронными.
4680. Вы проектируете схему для хранения древовидных комментариев (как в Reddit или Хабре) с неограниченным уровнем вложенности. Какой метод хранения иерархии позволит наиболее эффективно выбрать всю ветку обсуждения для одного корневого комментария?
Anonymous Quiz
41%
Структура «Вложенные множества» (Nested Sets).
25%
Поле parent_id со ссылкой на родительский комментарий.
28%
Хранение пути (path) в виде материализованного пути (например, 1.5.12.34).
7%
Таблица замыканий (Closure Table).
👩🏫Объяснение:
Для задачи выборки целого поддерева структура «Вложенные множества» является самой эффективной. Каждая вершина хранит два числа: 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
22%
Одна таблица user_answers с полями: id, user_id, quiz_id, question_id, answer, created_at
40%
Та же таблица user_answers, но с горизонтальным шардингом по user_id.
22%
Использовать временную таблицу с простой структурой и без индексов
17%
Для каждого активного квиза создавать отдельную таблицу, например, quiz_12345_answers.
👩🏫Объяснение:
Этот кейс — классический пример «проблемы горячей точки» (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%
Писать детальные тест-кейсы
71%
Провести ревью требований с QA
10%
Сгенерировать тестовые данные
9%
Составить план UAT
👩🏫Объяснение:
Наиболее критичный и эффективный вклад аналитика в этап тестирования происходит до написания кода — на стадии верификации самих требований. 🤔
Почему?
Подавляющее большинство дорогих и сложных дефектов возникают не из-за ошибки в коде, а из-за неоднозначных, противоречивых или неполных требований. Разработчик и тестировщик могут по-разному интерпретировать расплывчатую формулировку, что приводит к функционалу, не соответствующему ожиданиям бизнеса.
Ревью требований с QA решает ключевые проблемы:
✅ Тестируемость: Тестировщики помогают убедиться, что каждое требование может быть объективно проверено. Например, требование «система должна работать быстро» → превращается в «время отклика интерфейса при оформлении платежа не должно превышать 2 секунд при нагрузке до 1000 concurrent users». ⏱️
✅ Однозначность: Исключаются формулировки типа «как правило», «может быть», «удобный интерфейс».
✅ Полнота: QA, мысля сценариями, сразу видят «дыры» в логике — что должно происходить при ошибке сети? При повторном нажатии кнопки? При истечении таймаута сессии? 🕳
✅ Раннее вовлечение: Тестировщики начинают погружаться в логику системы с самого начала, что ускоряет последующее проектирование тестов.
Почему?
Подавляющее большинство дорогих и сложных дефектов возникают не из-за ошибки в коде, а из-за неоднозначных, противоречивых или неполных требований. Разработчик и тестировщик могут по-разному интерпретировать расплывчатую формулировку, что приводит к функционалу, не соответствующему ожиданиям бизнеса.
Ревью требований с QA решает ключевые проблемы:
✅ Тестируемость: Тестировщики помогают убедиться, что каждое требование может быть объективно проверено. Например, требование «система должна работать быстро» → превращается в «время отклика интерфейса при оформлении платежа не должно превышать 2 секунд при нагрузке до 1000 concurrent users». ⏱️
✅ Однозначность: Исключаются формулировки типа «как правило», «может быть», «удобный интерфейс».
✅ Полнота: QA, мысля сценариями, сразу видят «дыры» в логике — что должно происходить при ошибке сети? При повторном нажатии кнопки? При истечении таймаута сессии? 🕳
✅ Раннее вовлечение: Тестировщики начинают погружаться в логику системы с самого начала, что ускоряет последующее проектирование тестов.
❤1
4683. Веб-приложению нужно отправлять SMS через внешний сервис. Отправка долгая, но основной процесс не должен ждать. Какой способ интеграции выбрать?
Anonymous Quiz
9%
Синхронный REST API вызов
84%
Асинхронная очередь через брокер сообщений
4%
Фоновая синхронизация по расписанию
3%
Общая база данных для обмена