❌ B: Увеличение памяти может помочь, если текущий объём недостаточен для кэширования, но это не решит проблему полного сканирования.
❌ C: Составной индекс полезен, если запросы часто используют оба поля, но для поиска только по email он будет менее эффективен (можно использовать, но он больше по размеру).
❌ D: Шардинг (горизонтальное партиционирование) — сложное архитектурное решение, которое обычно применяют при распределении нагрузки, а не для ускорения одного вида запросов. Индекс проще и дешевле.
Вывод: Индекс — базовый инструмент оптимизации запросов. Аналитик должен рекомендовать индексацию часто используемых в условиях WHERE полей.
Please open Telegram to view this post
VIEW IN TELEGRAM
4723. В системе онлайн-бронирования отелей два пользователя одновременно пытаются забронировать последний свободный номер. В результате номер забронирован дважды. Какой механизм СУБД предотвратил бы эту проблему?
Anonymous Quiz
9%
Уникальный индекс на поле room_id
17%
Триггер, проверяющий количество броней
73%
Блокировка строки при чтении (SELECT ... FOR UPDATE)
1%
Журналирование всех изменений
Добавьте папку — и сразу получите доступ к закрытому каналу с подарками от экспертов: полезными гайдами, чек-листами, промокодами на карьерные консультации и т.д.
🍂 Карьерный рост — стратегии переговоров, продажи, маркетинг🍂 Удалёнка и фриланс — как находить заказчиков и работать из любой точки мира🍂 Личный бренд — создание экспертного статуса🍂 Hard и soft skills — навыки, за которые готовы платить в 2026 года🍂 Автоматизация и тайм-менеджмент — как работать меньше, а зарабатывать больше и многое другое
Добавить папку + открыть бонусы
https://t.me/addlist/ZcC3dzQ0ZJhjZjgy
(Доступ открыт 72 часа)
Присоединяйтесь: @prodvizheniye_reklama
Please open Telegram to view this post
VIEW IN TELEGRAM
❌ A: Уникальный индекс предотвращает дубликаты по ключу, но здесь уникальность не в одном поле, а в сочетании «номер + дата» (или что-то подобное). Если бы индекс был составным, он бы сработал, но в условии только room_id — не хватит.
❌ B: Триггер выполняется после попытки вставки, но не блокирует чтение, поэтому оба пользователя могут пройти проверку одновременно.
❌ D: Журналирование помогает при восстановлении после сбоя, но не решает проблему конкурентного доступа.
Вывод: Для критичных по конкуренции операций необходимо использовать явные блокировки или повышать уровень изоляции транзакции до REPEATABLE READ / SERIALIZABLE.
Please open Telegram to view this post
VIEW IN TELEGRAM
4724. Для нового проекта — системы мониторинга IoT-датчиков — нужно хранить поток показаний. Каждое событие: ID датчика, временная метка, значение. Требуется быстрая запись и аналитика по временным диапазонам. Какую базу данных лучше выбрать?
Anonymous Quiz
17%
Реляционную (PostgreSQL) с нормализованной схемой
10%
Документную (MongoDB)
68%
Колоночную временную (Time Series DB) — например, InfluxDB или ClickHouse
6%
Графовую (Neo4j)
❌ A: Реляционные БД справляются с временными рядами, но при 100k событий/сек быстро упрутся в ограничения по записи и объёму, если не использовать специализированные расширения (например, TimescaleDB для PostgreSQL — но это уже гибрид).
❌ B: MongoDB хорошо подходит для документов, но не оптимизирована для временных агрегаций на больших объёмах.
❌ D: Графовые БД нужны для анализа связей (социальные сети, рекомендации), здесь они не релевантны.
Вывод: Аналитик должен понимать классы СУБД и выбирать под задачу: для временных рядов — специализированные хранилища.
Please open Telegram to view this post
VIEW IN TELEGRAM
4724. Новостной портал с миллионной аудиторией, высокая нагрузка на чтение, небольшая команда, быстрое развитие. Какую архитектуру выбрать на старте?
Anonymous Quiz
19%
Микросервисная
55%
Модульный монолит
9%
Serverless
17%
Событийно-ориентированная
Быстро разрабатывать и развертывать (единое приложение, простая инфраструктура).
Чётко разделить код на модули (например, статьи, комментарии, пользователи), что в будущем позволит безболезненно выделить микросервисы.
Эффективно использовать ресурсы: один процесс обрабатывает запросы без сетевых задержек между сервисами.
❌ Микросервисная архитектура (A) на старте приведёт к излишней сложности: нужно настраивать межсервисное взаимодействие, обеспечивать согласованность данных, управлять конфигурациями нескольких сервисов — для небольшой команды это замедлит разработку.
❌ Serverless (C) может дать холодный старт при первом обращении к статье, что ухудшит пользовательский опыт. Кроме того, serverless сложнее отлаживать и тестировать локально, а также возможен vendor lock-in.
❌ Событийно-ориентированная архитектура (D) с брокером сообщений избыточна для новостного портала, где основная логика синхронна (отдать статью). Она добавит сложности без явной выгоды.
Вывод: Для большинства стартапов с монолитной предметной областью и небольшой командой модульный монолит — разумный выбор, позволяющий сохранить гибкость и скорость.
Please open Telegram to view this post
VIEW IN TELEGRAM
4725. Система бронирования авиабилетов. Как не допустить двойную продажу одного места при одновременных запросах?
Anonymous Quiz
5%
Оптимистическая блокировка
71%
Пессимистическая блокировка (SELECT FOR UPDATE)
10%
Уникальный индекс на (рейс, место)
13%
Очередь запросов
SELECT ... FOR UPDATE в начале транзакции блокирует строку до её завершения. Второй пользователь, попытавшийся выполнить такой же запрос, будет ждать освобождения блокировки и увидит, что место уже занято.
Этот подход гарантирует, что два пользователя не смогут одновременно начать бронирование одного места.
❌ Оптимистическая блокировка (A) предполагает проверку версии при обновлении. При высокой конкуренции оба пользователя могут прочитать место как свободное, и только при попытке записи один получит ошибку. Это допустимо, но пользователь получит отказ после ввода данных, что хуже для UX.
❌ Уникальный индекс (C) предотвращает дубликаты на уровне вставки, но не защищает от чтения: оба могут попытаться вставить, и одна вставка упадёт с ошибкой дубликата. Опять же, пользователь узнаёт об отказе после попытки.
❌ Очередь (D) сериализует запросы, но добавляет задержку и сложность. При этом первый запрос в очереди может занять место, а остальные увидят отказ. Однако реализация очереди и обработка таймаутов сложнее, чем блокировка в БД.
Вывод: Для критичных по конкурентности операций с уникальным ресурсом (место, товар) выбирайте пессимистическую блокировку — она даёт наилучший UX и простоту реализации.
Please open Telegram to view this post
VIEW IN TELEGRAM
4726. IoT-система: миллионы показаний датчиков в секунду. Нужны средние за 5 минут для аналитики. Какую архитектуру обработки выбрать?
Anonymous Quiz
12%
Синхронная запись в SQL + агрегация запросами
68%
Потоковая обработка (Kafka + Flink) с окнами
4%
Пакетная обработка раз в сутки
17%
NoSQL + агрегация в приложении
Брокер сообщений (Kafka) принимает поток событий и гарантирует надёжность.
Процессор потоков (Apache Flink, Kafka Streams) выполняет агрегацию с окнами (tumbling window of 5 minutes) прямо в памяти, выдавая готовые средние значения без хранения сырых данных в полном объёме.
Результаты можно сохранять в колоночную БД (ClickHouse) для быстрой аналитики.
❌ Синхронная запись в SQL (A) не выдержит нагрузку: 1 млн записей/сек — это предел даже для самых мощных реляционных СУБД, не говоря уже об агрегации.
❌ Пакетная обработка раз в сутки (C) не даёт оперативности: данные будут устаревшими на сутки, что неприемлемо для мониторинга в реальном времени.
❌ NoSQL + агрегация в приложении (D) — сырые данные будут храниться в NoSQL (например, Cassandra), но агрегация потребует чтения миллионов записей из БД каждые 5 минут, что создаст колоссальную нагрузку.
Вывод: Для высокочастотных временных рядов необходима потоковая обработка с оконными агрегатами. Это стандарт в современной Big Data архитектуре.
Please open Telegram to view this post
VIEW IN TELEGRAM
4727. Интернет-магазин: страницы товаров тормозят из-за высокой нагрузки на БД. Как снизить нагрузку?
Anonymous Quiz
11%
Добавить индексы на все поля
82%
Внедрить кэширование (Redis)
3%
Увеличить мощность сервера
4%
Перейти на NoSQL
Redis или Memcached хранят часто запрашиваемые данные в оперативной памяти, обеспечивая ответ за миллисекунды.
Для страниц товаров можно кэшировать по ключу product:{id} с TTL (например, 5 минут) или инвалидировать кэш при изменении цены/наличия.
Это снижает число запросов к основной БД на 90–95%.
❌ Индексы (A) уже должны быть на полях, используемых в WHERE (например, product_id). Добавление индексов на все поля бесполезно и даже вредно (замедляет запись).
❌ Увеличение мощности сервера (C) — временное решение, не решающее проблему масштабирования. При росте нагрузки снова упрётесь в потолок.
❌ Переход на NoSQL (D) — сложный и дорогой шаг, не гарантирующий успеха. Часто проблемы решаются кэшированием и оптимизацией запросов, без смены СУБД.
Вывод: Кэширование — первая линия обороны при проблемах с производительностью чтения. Аналитик должен закладывать требования к кэшированию и стратегии инвалидации.
Please open Telegram to view this post
VIEW IN TELEGRAM