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
4728. Система управления задачами: нагрузка на чтение в 10 раз выше, чем на запись. Как разделить модели чтения и записи?
Anonymous Quiz
40%
CQRS
14%
CRUD с одной БД
34%
Master-slave репликация
12%
Шардирование по user_id
Оптимизировать модель записи под целостность (нормализованная форма).
Создать отдельные модели чтения (денормализованные, с предвычисленными данными) для быстрых запросов.
Каждую модель масштабировать независимо (например, чтение может обслуживаться репликами).
❌ CRUD с одной БД (B) — классический подход, но при сильном дисбалансе нагрузки он приведёт к тому, что чтения будут «забивать» ресурсы, мешая записи.
❌ Master-slave репликация (C) помогает распределить нагрузку чтения на реплики, но модели данных остаются одинаковыми (нормализованными). Для сложных отчётов или представлений это может быть неэффективно.
❌ Шардирование (D) решает проблему объёма данных, но не разнородности нагрузки. Оно не оптимизирует модель под специфику чтения.
Вывод: При сильном дисбалансе нагрузок чтения и записи, а также при сложных представлениях данных, CQRS — архитектурный паттерн, позволяющий достичь высокой производительности и масштабируемости.
Please open Telegram to view this post
VIEW IN TELEGRAM
4729. В системе бронирования отелей два менеджера одновременно пытаются забронировать последний номер. Как гарантировать, что номер не продадут дважды?
Anonymous Quiz
16%
Оптимистическая блокировка (проверка версии)
60%
Пессимистическая блокировка (блокировка строки в БД)
8%
Уникальный индекс на номер отеля
15%
Обрабатывать ошибки дубликатов и уведомлять второго
✅ Пессимистическая блокировка — самый надёжный способ. В начале транзакции вы выполняете SELECT ... FOR UPDATE. Эта команда блокирует строку в базе данных до завершения транзакции. Второй менеджер, попытавшись прочитать ту же строку с FOR UPDATE, будет ждать. Когда блокировка снимется, он увидит, что номер уже занят. Это гарантирует, что одновременных бронирований не произойдёт.
❌ Оптимистическая блокировка (A) работает иначе: вы читаете данные без блокировки, запоминаете версию, а при записи проверяете, не изменилась ли версия. В нашем случае оба менеджера прочитают номер как свободный, оба попытаются записать, и один получит ошибку. Это допустимо, но пользователь узнает об отказе только после попытки, что хуже для UX.
❌ Уникальный индекс (C) на поле (hotel_id, room_number) предотвратит вставку дубликата на уровне БД. Но проблема та же: оба менеджера могут попытаться вставить, одна вставка упадёт с ошибкой, второй успеет. Это лучше, чем двойная продажа, но второй менеджер получит неожиданную ошибку.
❌ Обрабатывать ошибки (D) — значит полагаться на то, что приложение само разберётся с конфликтом. Это ненадёжно и усложняет код.
Вывод: Для критически важных ресурсов (билеты, номера, товары) используйте пессимистическую блокировку. Она гарантирует целостность и даёт пользователю мгновенную обратную связь.
Please open Telegram to view this post
VIEW IN TELEGRAM