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
4730. Мобильное приложение использует API. Разработчики хотят изменить формат ответа, добавив новые поля. Как сделать это без поломки старых версий приложения?
Anonymous Quiz
3%
Оповестить пользователей и попросить обновить приложение
87%
Версионировать API (v1, v2) и поддерживать обе версии параллельно
1%
Менять формат, старые приложения пусть падают
9%
Добавлять поля в конец ответа, старые приложения их проигнорируют
✅ Версионирование API — отраслевой стандарт. Вы начинаете с /api/v1/.... Когда нужно внести изменения, несовместимые со старой версией, вы создаёте /api/v2/.... Старые приложения продолжают работать с v1, новые используют v2. Через некоторое время, когда доля старых клиентов станет ничтожной, вы можете отключить v1. Это гарантирует, что ни одно приложение не сломается.
❌ Оповестить пользователей (A) — не работает. Пользователи не обновляют приложения мгновенно, некоторые могут вообще не обновить. Вы не можете полагаться на их действия.
❌ Пусть падают (C) — недопустимо для серьёзного продукта. Это потеря пользователей и репутации.
❌ Добавлять поля в конец (D) — работает только для добавления необязательных полей, но не для изменений структуры. Если нужно переименовать поле или изменить тип данных, старые приложения сломаются.
Вывод: Версионирование API должно быть заложено в архитектуру с самого первого дня. Это единственный способ эволюционировать систему, не ломая клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Кажется, знакомая история, не правда ли? Бесконечный поиск "волшебной таблетки" в мире онлайн-маркетинга может вымотать кого угодно. Обещания золотых гор, гуру, предлагающие секретные формулы успеха, и горы потраченных впустую денег.
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
➡️ ЗАБИРАЙ МЕТОД ТУТ https://t.me/addlist/wW0ESLUtsM0wZTQy
Результат:
😃за 3 дня работы, +60 подписчиков и 3 продажи сразу.
Добавляй себе всю папку https://t.me/addlist/wW0ESLUtsM0wZTQy и
Записывайся в подборку🫶
Чувствуете себя белкой в колесе, которая крутится, но не двигается с места?
🔥ПРИВЛЕКАЙ ПОДПИСЧИКОВ И ПОЛУЧАЙ ЕЖЕДНЕВНЫЕ ЗАЯВКИ БЕСПЛАТНО, С ПОМОЩЬЮ ЭТОГО МЕТОДАРезультат:
😃за 3 дня работы, +60 подписчиков и 3 продажи сразу.
Добавляй себе всю папку https://t.me/addlist/wW0ESLUtsM0wZTQy и
Записывайся в подборку
Please open Telegram to view this post
VIEW IN TELEGRAM
4731. Мобильное приложение использует API. Разработчики хотят изменить формат ответа, добавив новые поля. Как сделать это без поломки старых версий приложения?
Anonymous Quiz
2%
Оповестить пользователей и попросить обновить приложение
91%
Версионировать API (v1, v2) и поддерживать обе версии параллельно
1%
Менять формат, старые приложения пусть падают
6%
Добавлять поля в конец ответа, старые приложения их проигнорируют
✅ Версионирование API — отраслевой стандарт. Вы начинаете с /api/v1/.... Когда нужно внести изменения, несовместимые со старой версией, вы создаёте /api/v2/.... Старые приложения продолжают работать с v1, новые используют v2. Через некоторое время, когда доля старых клиентов станет ничтожной, вы можете отключить v1. Это гарантирует, что ни одно приложение не сломается.
❌ Оповестить пользователей (A) — не работает. Пользователи не обновляют приложения мгновенно, некоторые могут вообще не обновить. Вы не можете полагаться на их действия.
❌ Пусть падают (C) — недопустимо для серьёзного продукта. Это потеря пользователей и репутации.
❌ Добавлять поля в конец (D) — работает только для добавления необязательных полей, но не для изменений структуры. Если нужно переименовать поле или изменить тип данных, старые приложения сломаются.
Вывод: Версионирование API должно быть заложено в архитектуру с самого первого дня. Это единственный способ эволюционировать систему, не ломая клиентов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4732. На диаграмме классов отношение, показывающее, что один класс является частным случаем другого
Anonymous Quiz
12%
Ассоциация
12%
Агрегация
66%
Наследование
10%
Зависимость