4663. Вы проектируете систему сбора телеметрии с IoT-устройств. Устройства отправляют 100 000 событий в секунду. Нужно писать события с минимальной задержкой и раз в час строить агрегационные отчеты. Какую стратегию хранения выбрать на первом этапе?
Anonymous Quiz
16%
Писать сразу в колоночную БД (ClickHouse) с высокой степенью сжатия.
11%
Писать в реляционную БД (PostgreSQL) в таблицу с партиционированием по часам.
52%
Писать в шину событий (Kafka), а оттуда batch-ами загружать в хранилище данных.
20%
Писать в документную БД (MongoDB), используя TTL-индексы для автоматического удаления старых данных.
👩🏫Объяснение:
При таком объеме и требовании к минимальной задержке записи, прямая запись в аналитическое или транзакционное хранилище (A, B) создаст чрезмерную нагрузку. Правильный паттерн — буферизация через шину событий (Kafka). Она гарантирует прием высокого потока, обеспечивает отказоустойчивость и позволяет затем гибко направлять данные в разные системы (в холодное хранилище, в real-time агрегатор и т.д.). Вариант D не решает проблему аналитической обработки и может стать дорогим из-за объема.
4664. В финансовом приложении есть строгое требование: нельзя удалять данные об операциях. При этом пользователь может отозвать согласие на обработку персональных данных (GDPR). Как технически реализовать «забывание» пользователя?
Anonymous Quiz
3%
Физически удалить строки с данными пользователя, предварительно сделав экспорт для регулятора.
32%
Помечать записи как удаленные (is_deleted = true), скрывая их из интерфейса.
55%
Провести криптографическое обезличивание (шифрование) персональных полей с уничтожением ключа.
10%
Перенести все записи пользователя в отдельный архивный сервис с ограниченным доступом.
👩🏫Объяснение:
Этот кейс на стыке compliance и архитектуры. Требования: 1) Неизменяемость операций (нужны для аудита), 2) Право на забвение. Физическое удаление (A) нарушает первое. Soft-delete (B) не соответствует GDPR, так как данные остаются в исходном виде. Архивация (D) не решает проблему обезличивания. Криптографическое удаление (crypto-shredding) — отраслевой best practice: чувствительные поля (ФИО, email) шифруются отдельным ключом на пользователя; при удалении ключ уничтожается, делая данные нечитаемыми, при этом неизменяемые метаданные операции (сумма, время) остаются.
👍1
4665. В таблице Users есть текстовое поле search_vector (full-text search) и часто выполняется запрос WHERE search_vector @@ to_tsquery('keyword'). При росте таблицы до 5 млн записей запрос стал медленным. Индекс GIN уже существует. Что делать?
Anonymous Quiz
4%
Добавить больше оперативной памяти для кэша СУБД.
46%
Провести партиционирование таблицы по диапазонам ID.
42%
Перестроить индекс GIN с изменением параметра заполнения (fillfactor).
8%
Заменить GIN-индекс на GiST-индекс.
👩🏫Объяснение:
На практике, если GIN-индекс уже есть и запросы тормозят на 5 млн записей, часто проблема не в индексе, а в селективности запроса. Если запрос возвращает тысячи строк (например, по популярному слову), то основное время уходит на их чтение и сортировку. Партиционирование (B) может помочь, если разделить данные по какому-либо признаку (например, по дате регистрации) и делать запрос только по актуальным партициям. Однако, если запрос всегда сканирует все партиции, то выигрыша не будет. Перестройка индекса (C) может помочь, если индекс разросся и стал неэффективным. Но в реальности чаще требуется оптимизация самого запроса (например, добавление дополнительных условий для повышения селективности) или использование специализированной поисковой системы (Elasticsearch). В контексте экзамена правильнее B, так как это масштабное изменение структуры для больших данных.
Ребята, классные новости 🙌
Нас добавили в ламповую папку с самыми годными телеграм-каналами про ИТ🐱
Внутри — технологии, ИИ, карьера в ИТ, полезные разборы и контент без воды.
Короче, всё, что хочется видеть в ленте, если вы в теме (или только хотите войти)
Тык 👉 https://news.1rj.ru/str/addlist/Tgpq6yK7iYMzNWRi — добавить папку себе
И пусть в ленте будет больше пользы и меньше случайного шума✨
❤️ Поделитесь с тем, кто тоже хочет прокачиваться в ИТ и читать только толковый контент
Нас добавили в ламповую папку с самыми годными телеграм-каналами про ИТ
Внутри — технологии, ИИ, карьера в ИТ, полезные разборы и контент без воды.
Короче, всё, что хочется видеть в ленте, если вы в теме (или только хотите войти)
Тык 👉 https://news.1rj.ru/str/addlist/Tgpq6yK7iYMzNWRi — добавить папку себе
И пусть в ленте будет больше пользы и меньше случайного шума
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
4666. При репликации «master-slave» в MySQL возникла проблема: на slave-сервере в некоторых таблицах появляются дубликаты записей по уникальному ключу, хотя на master-дублей нет. В чем наиболее вероятная причина?
Anonymous Quiz
3%
Недостаточно места на диске slave-сервера.
63%
AUTO_INCREMENT auto_increment_increment и auto_increment_offset в master-master репликации.
5%
Разные версии MySQL на master и slave.
28%
Асинхронная репликация и задержки между серверами.
👩🏫Объяснение:
Это очень конкретный и частый кейс при настройке репликации с автоинкрементными полями. Если топология не просто «master-slave», а «master-master» или «circular replication», и на обоих серверах могут писаться данные в одну таблицу, то без специальных настроек auto_increment_increment (шаг) и auto_increment_offset (смещение) оба сервера начнут генерировать одинаковые ID, что приведет к конфликтам и дубликатам на slave. Остальные варианты (A, C, D) к дубликатам по уникальному ключу обычно не приводят.
Если вы всё еще пишете весь код вручную — вы теряете время. Современные нейросети — это не просто «чат», это полноценный напарник (Pair Programmer).
Что ИИ делает лучше всего прямо сейчас:
Совет: Не бойтесь экспериментировать с разными моделями. Там, где GPT «галлюцинирует», Claude выдает чистейшую логику.
Будущее разработки — это умение эффективно управлять искусственным интеллектом. А наша подборка каналов поможет Вам в этом!
https://news.1rj.ru/str/addlist/kbnn_yWvqHsyODky
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ITech👾
Юлия invites you to add the folder “ITech👾”, which includes 29 chats.
❤1
4667. Вы проектируете систему для мультитенантного SaaS. Данные тысяч клиентов должны быть надежно изолированы. Какой подход к схеме БД обеспечит наилучший баланс между изоляцией, простотой обслуживания и эффективностью для среднего размера бизнеса?
Anonymous Quiz
36%
Отдельная схема (schema) в одной БД для каждого тенанта.
16%
Отдельная физическая база данных для каждого тенанта.
21%
Единая таблица для всех тенантов с колонкой tenant_id на каждой строке.
26%
Партиционирование одной большой таблицы по колонке tenant_id.
👩🏫Объяснение:
Отдельная схема в общей БД — классический и сбалансированный паттерн. Каждый тенант получает свои собственные таблицы в рамках своей схемы, что обеспечивает четкую логическую изоляцию и упрощает резервное копирование/восстановление данных для одного клиента. Это проще в администрировании, чем управление тысячами отдельных БД (B), и обеспечивает лучшую изоляцию и производительность, чем подход с единой таблицей (C), где ошибка в WHERE-условии может привести к утечке данных. Партиционирование (D) — это физическое разделение, но логически данные все еще в одной таблице, что не дает такой же чистоты изоляции.
4668. В ленте новостей социальной сети запрос для получения постов друзей, начал выполняться медленно, несмотря на индексы. Анализ показал, что СУБД тратит 95% времени на сортировку огромного промежуточного результата перед LIMIT. Как это можно оптимизи
Anonymous Quiz
8%
Создать более селективный индекс по post_date DESC.
57%
Создать составной индекс, который включает все поля для фильтрации и сортировки в нужном порядке.
3%
Увеличить значение LIMIT для более точного планирования запроса.
32%
Разбить запрос на два: сначала получить ID постов подзапросом, затем основную информацию.
👩🏫Объяснение:
Ключевая проблема — сортировка по неиндексированному полю post_date после объединения таблиц. LIMIT применяется уже после сортировки всей выборки. Правильный составной индекс (например, на (user_id, friend_id, post_date DESC)) позволит СУБД выполнить «index scan» в уже отсортированном порядке, сразу отбирая топ-20 записей без ресурсоемкой операции filesort. Простой индекс на post_date (A) не поможет, так как сортировка происходит после JOIN. Разбиение запроса (D) иногда помогает, но радикальное решение — предоставить СУБД индекс, который сразу возвращает данные в нужном порядке.