Разработчик баз данных NoSQL (Профессиональный уровень)

Курс предназначен для профессионального освоения разработки и администрирования NoSQL баз данных. Вы изучите архитектуру, проектирование, оптимизацию и масштабирование документных, графовых и распределённых систем хранения данных. На практике реализуете сложные сценарии интеграции, обеспечите высокую доступность, отказоустойчивость и производительность в реальных проектах.

Курс «Разработчик баз данных NoSQL (Профессиональный уровень)» включает углублённое изучение архитектуры и внутреннего устройства NoSQL-систем: документо-ориентированных (MongoDB, Couchbase), графовых (Neo4j, Amazon Neptune), колоночных (Cassandra, HBase), а также распределённых решений (DynamoDB, Riak). Рассматриваются модели данных, механизмы репликации, шардинга, согласованности, транзакций в распределённой среде. Изучаются методы проектирования схем, оптимизации запросов, индексирования, партиционирования, обеспечения ACID/CAP-свойств в условиях распределённости.


По окончании курса слушатель должен уметь:
— Проектировать и нормализовать модели данных для различных типов NoSQL СУБД;
— Реализовывать эффективные алгоритмы хранения, индексации и поиска в неструктурированных и полуструктурированных наборах;
— Настраивать кластеры, шардинг и репликацию для высоконагруженных систем;
— Обеспечивать отказоустойчивость, балансировку нагрузки и восстановление после сбоев;
— Применять средства мониторинга и оптимизации производительности (Prometheus, Grafana, CloudWatch);
— Интегрировать NoSQL базы в микросервисные и распределённые архитектуры.

Слушатель должен знать:
— Принципы работы CAP-теоремы, BASE-семантики, MVCC, vector clocks;
— Особенности сериализации данных (JSON, BSON, Avro, Protobuf);
— Механизмы согласованности, кворумного чтения/записи, логической репликации;
— Подходы к обработке big data с помощью NoSQL решений (Spark, Kafka Streams);
— Лучшие практики безопасности, аудита и управления доступом в NoSQL-средах.


Дополнительно:
Курс включает практические лабораторные работы по настройке кластеров, горизонтальному масштабированию, отладке медленных запросов, созданию backup-стратегий, разработке API поверх NoSQL хранилищ.

  1. Что такое NoSQL и в каких случаях её предпочтительнее использовать, чем реляционные СУБД?
    NoSQL — это класс систем управления базами данных, не основанных на реляционной модели. Используется при необходимости масштабируемости, гибкой схемы данных, высокой производительности чтения/записи и обработки больших объёмов неструктурированных данных.

  2. Какие типы NoSQL-баз существуют и какие задачи они решают?
    Документные (MongoDB) — для гибких иерархических структур; графовые (Neo4j) — для анализа связей; колоночные (Cassandra) — для высокопроизводительного хранения больших наборов данных; ключ-значение (Redis) — для кэширования и быстрого доступа.

  3. Что означает CAP-теорема и как она влияет на выбор NoSQL-системы?
    CAP-теорема утверждает, что распределённая система может одновременно обеспечивать согласованность, доступность и устойчивость к разделению сети только два из трёх. Это определяет компромиссы при проектировании систем.

  4. Что такое шардинг и как он реализуется в NoSQL?
    Шардинг — это горизонтальное разделение данных между несколькими узлами. В NoSQL используется для масштабирования чтения/записи и балансировки нагрузки, например, в MongoDB через sharded clusters.

  5. Как работают механизмы репликации в NoSQL и зачем они нужны?
    Репликация создаёт копии данных на нескольких узлах для обеспечения отказоустойчивости, повышения доступности и балансировки нагрузки на чтение.

  6. В чём отличие BASE от ACID?
    BASE (Basically Available, Soft state, Eventually consistent) — подход, характерный для NoSQL, допускающий временную несогласованность ради доступности и масштабируемости, в отличие от строгих ACID-гарантий транзакций.

  7. Что такое логическая временная метка (vector clock) и где применяется?
    Vector clock — механизм отслеживания причинно-следственных связей между изменениями в распределённых системах, используется в Riak и других eventual consistency системах.

  8. Как работает MVCC в контексте NoSQL?
    MVCC (Multi-Version Concurrency Control) позволяет разным транзакциям видеть разные версии данных, что повышает параллелизм и снижает блокировки, применяется в некоторых документных и колоночных БД.

  9. Что такое TTL-индексы и когда их стоит использовать?
    TTL-индексы автоматически удаляют данные по истечении заданного времени, полезны для временных записей, логов или кэша.

  10. Какие методы индексирования поддерживаются в MongoDB?
    Поддерживаются одно- и многопольные, составные, текстовые, геопространственные, TTL, уникальные и частичные индексы.

  11. Как устроена модель данных в графовых БД?
    Модель состоит из вершин (узлов), рёбер (связей) и свойств. Оптимальна для работы с сильносвязанными данными, таких как социальные графы или рекомендательные системы.

  12. Что такое миграция данных в NoSQL и как она организуется?
    Миграция — изменение структуры данных в динамической схеме. Организуется через скрипты, versioning документов или live migration с постепенным обновлением.

  13. Как обеспечивается безопасность в NoSQL-системах?
    Через аутентификацию, авторизацию на уровне ролей, шифрование данных, SSL/TLS, аудит действий пользователей и ограничение сетевого доступа.

  14. Как происходит сериализация данных в NoSQL и какие форматы используются?
    Используются JSON, BSON, Avro, Protobuf, MessagePack — для компактности, скорости передачи и эффективного хранения данных.

  15. Что такое eventual consistency и в каких системах она применяется?
    Eventual consistency — гарантия, что все копии данных со временем станут одинаковыми. Применяется в системах с высокой доступностью, например, Cassandra, DynamoDB.

  16. Как настраивается кворумное чтение и запись в распределённых NoSQL-системах?
    Кворумное чтение/запись требует подтверждения операции от большинства узлов, чтобы повысить согласованность, часто используется в Apache Cassandra.

  17. Какие механизмы партиционирования данных используются в NoSQL?
    Range-based, hash-based и list-based партиционирование. Выбор зависит от равномерности распределения нагрузки и особенностей запросов.

  18. Как работает MapReduce в контексте NoSQL?
    MapReduce — парадигма обработки больших объёмов данных, позволяющая выполнять агрегации и анализ в распределённой среде, например, в MongoDB.

  19. Какие инструменты мониторинга и диагностики применяются в NoSQL?
    Prometheus + Grafana, CloudWatch, Datadog, OpsCenter, MongoDB Atlas Monitoring, ELK Stack для логов.

  20. Как реализуется поддержка транзакций в NoSQL?
    Некоторые NoSQL системы (MongoDB, Couchbase) поддерживают многооперационные транзакции внутри одного документа или шарда, другие — через внешние средства (например, Kafka Streams).

  21. Как осуществляется резервное копирование и восстановление в NoSQL?
    Через snapshot'ы, export/import (mongodump/mongoexport), continuous backups, point-in-time recovery и интеграции с облачными сервисами.

  22. Как интегрируются NoSQL-базы в микросервисные архитектуры?
    Через API, message queues (Kafka, RabbitMQ), CQRS, event sourcing, а также использование sidecar-компонентов и service mesh.

  23. Какие проблемы могут возникнуть при масштабировании NoSQL-систем?
    Hot partitions, network partitioning, потеря согласованности, сложности с миграцией, увеличение latency, управление состоянием.

  24. Как оптимизировать производительность запросов в NoSQL?
    Через правильное создание индексов, денормализацию данных, фильтрацию на сервере, пагинацию, профилирование медленных запросов и использование explain().

  25. Какие практики используются для тестирования и отладки NoSQL-решений?
    Unit- и интеграционное тестирование, load testing (JMeter, Locust), profiling, logging, использование mock-серверов, A/B testing с реальными нагрузками.

  1. Какие факторы влияют на выбор типа NoSQL-базы для конкретного проекта?
    Выбор зависит от модели данных (документы, графы, ключ-значение), требований к согласованности, масштабируемости, производительности, поддержки транзакций и сложности интеграции в архитектуру.

  2. Что такое денормализация данных и почему она часто используется в NoSQL?
    Денормализация — это объединение связанных данных в одну запись для ускорения чтения. Применяется в NoSQL для снижения количества операций join и повышения производительности.

  3. Как реализуется пагинация в MongoDB и какие подходы существуют?
    Пагинация реализуется через методы skip() и limit(), но при больших смещениях это неэффективно. Альтернативы: курсоры, ключевая пагинация (where + sort) и index-based offset.

  4. В чём разница между логической и физической репликацией в NoSQL?
    Логическая репликация передаёт изменения на уровне запросов или событий, физическая — копирует блоки данных или файлы базы. Логическая гибче, физическая — быстрее.

  5. Как организовать балансировку нагрузки при работе с NoSQL-кластерами?
    Использовать клиентские драйверы с поддержкой load balancing, прокси-серверы (HAProxy, NGINX), шардинг, автоматическое распределение запросов по репликам и политики read preference.

  6. Что такое eventual consistency и как её можно детектировать?
    Eventual consistency — состояние, когда все узлы со временем синхронизируются. Детектировать можно через версии данных, vector clocks или сравнение хэшей содержимого на разных нодах.

  7. Как обеспечить атомарность операций в документной БД?
    MongoDB поддерживает атомарные операции на уровне одного документа. Для нескольких документов используются двухфазные коммиты или внешние системы координации (например, ZooKeeper).

  8. Какие особенности проектирования схем характерны для Cassandra?
    Проектирование ведётся «под запросы», так как Cassandra оптимизирована под write-heavy нагрузки. Важна правильная организация primary key, clustering columns и materialized views.

  9. Как работает механизм hinted handoff в распределённых NoSQL системах?
    Hinted handoff — временная запись на другом узле в случае недоступности целевого, чтобы восстановить данные после возврата узла в строй, применяется в Cassandra.

  10. Какие инструменты используются для миграции из реляционной БД в NoSQL?
    ETL-инструменты (Apache NiFi, Talend), custom скрипты, Kafka Connect, MongoDB Connector for BI, Sqoop + JSON export, cloud migration tools (AWS DMS, Google Dataflow).

  11. Как реализуется full-text search в NoSQL?
    MongoDB поддерживает текстовые индексы; Elasticsearch может использоваться как внешнее решение; Couchbase имеет встроенный FTS-движок.

  12. Какие проблемы могут возникнуть при горизонтальном масштабировании NoSQL-систем?
    Hot partitions, network congestion, clock drift, split brain, потеря данных при переключении лидеров, конфликты версий, увеличение overhead управления кластером.

  13. Как работают secondary indexes в Cassandra и в чём их ограничения?
    Secondary indexes позволяют выполнять запросы по произвольным полям, но имеют ограничения: не поддерживают range queries, медленнее, чем основные ключи, и неэффективны при высокой кардинальности.

  14. Какие стратегии используются для обеспечения отказоустойчивости в NoSQL?
    Репликация, кворумное чтение/запись, heartbeat-мониторинг, автоматический failover, cross-region deployment, backup & restore, использование consensus алгоритмов (Raft, Paxos).

  15. Как реализовать ACID-транзакции в NoSQL-системе?
    Некоторые системы (MongoDB, Couchbase) поддерживают транзакции на уровне одного документа или шарда. Для распределённых транзакций используются Saga Pattern, event sourcing или внешние системы.

  16. Что такое eventual consistency conflict resolution и как он осуществляется?
    Механизмы разрешения конфликтов: last-write-wins, vector clocks, CRDTs, application-level merge, timestamp-based resolution. Используются в системах с eventual consistency.

  17. Как использовать Apache Spark с NoSQL-базами?
    Spark через соответствующие коннекторы (например, spark-cassandra-connector) позволяет выполнять ETL, аналитику и обработку big data, интегрируя NoSQL в pipeline.

  18. Какие типы шардинга поддерживаются в MongoDB?
    Range-based, hash-based и zone-based шардинг. Hash-based равномерно распределяет данные, range-based эффективен для диапазонных запросов, zone-based — для территориального разделения.

  19. Как организовать безопасный удалённый доступ к NoSQL-базе?
    Использовать SSH-туннели, SSL/TLS, RBAC, VPC, firewall rules, proxy-авторизация, API gateways, аудит всех подключений и применение least privilege принципа.

  20. Как работают TTL-коллекции в Redis и как они управляются?
    Redis поддерживает установку времени жизни ключа через команды EXPIRE, PEXPIRE. Ключи удаляются автоматически по истечении TTL, что полезно для кэширования.

  21. Какие метрики необходимо отслеживать при эксплуатации NoSQL-баз?
    CPU, RAM, disk I/O, latency, throughput, replication lag, cache hit ratio, error rate, connection count, GC pauses, compaction stats, query performance.

  22. Как реализовать backup и point-in-time recovery в MongoDB?
    Через mongodump/mongorestore, fs-snapshot, oplog tailing, MongoDB Cloud Manager или Atlas Backup, обеспечивающие incremental backups и точечное восстановление.

  23. Какие проблемы могут возникнуть при использовании long-running connections в NoSQL-клиентах?
    Network timeouts, memory leaks, stale connections, zombie processes, resource exhaustion. Решаются через keep-alive, reconnection policies, connection pooling и health checks.

  24. Какие особенности использования NoSQL в serverless-архитектурах?
    Ограничения на время выполнения, размер ответа, частоту вызовов, необходимость stateless работы. Требуется оптимизация запросов, использование managed DB-as-a-service и connection pooling.

  25. Какие подходы используются для тестирования отказоустойчивости NoSQL-кластера?
    Chaos engineering (например, Chaos Monkey), принудительное отключение узлов, имитация сетевых разрывов, проверка восстановления из backup, stress testing и fault injection.

  1. Какие особенности проектирования схем характерны для графовых баз данных?
    Схемы строятся вокруг узлов, связей и свойств. Основное внимание — на оптимизацию обхода графа, индексирование вершин и рёбер, а также эффективную реализацию сложных отношений.

  2. Что такое materialized view в NoSQL и как она применяется?
    Materialized view — это предрассчитанное представление данных, хранящееся физически. Используется для ускорения сложных запросов, особенно в Cassandra и Couchbase.

  3. Как работает механизм compaction в Cassandra и зачем он нужен?
    Compaction объединяет SSTable-файлы и удаляет устаревшие данные (например, по TTL или удалённые через tombstone). Позволяет оптимизировать место и производительность чтения.

  4. Как организовать транзакции между несколькими документами в MongoDB?
    В MongoDB 4.0+ поддерживаются многошардовые транзакции с применением двухфазного коммита внутри кластера. Требуется WiredTiger Storage Engine и режим write concern majority.

  5. Какие проблемы возникают при использовании auto-increment ID в NoSQL?
    Centralized bottleneck, hot shard, низкая производительность при высокой нагрузке. Решение: UUID, ObjectId, Snowflake-like ID, hash-based distribution.

  6. Что такое time-series data и какие NoSQL-системы оптимальны для их хранения?
    Time-series — данные, структурированные по времени. Для хранения подходят InfluxDB, TimescaleDB (но не только), а также Cassandra, MongoDB с TTL и партиционированием по времени.

  7. Как используются bloom filter в NoSQL-движках?
    Bloom filter — вероятностная структура данных, позволяющая быстро проверить, содержится ли ключ в наборе. Используется для ускорения поиска и снижения I/O в LSM-tree хранилищах (Cassandra, HBase).

  8. Какие механизмы обеспечивают параллелизм в NoSQL-системах?
    MVCC, optimistic concurrency control, versioning данных, pessimistic locks (редко), timestamp ordering, compare-and-swap, watch/notify протоколы.

  9. Что такое tombstone в контексте распределённой NoSQL-базы?
    Tombstone — маркер удаления данных, используемый для синхронизации удалённых узлов. Удаляется после успешной репликации и истечения grace period (в Cassandra — gc_grace_seconds).

  10. Как работают secondary indexes в MongoDB?
    Secondary index — дополнительный указатель на документы, основанный на одном или нескольких полях. Может быть композитным, уникальным, sparse или partial.

  11. Какие особенности имеет оптимизатор запросов в NoSQL-системах?
    Он менее развит, чем в SQL, но может выбирать лучший индекс, оптимизировать pipeline в MongoDB Aggregation Framework, использовать costing модели и статистику.

  12. Как реализуется геопространственное индексирование в MongoDB?
    MongoDB поддерживает 2d и 2dsphere индексы для координат. Реализуются через R-tree или Geohash, что позволяет выполнять запросы на близость, полигон и радиус.

  13. Какие факторы влияют на производительность write-heavy нагрузки в NoSQL?
    Batch writes, write-ahead log, memtable/SSTables, compaction strategy, buffer size, disk throughput, write concern, fsync policy.

  14. Какие практики управления миграцией схем применяются в NoSQL?
    Versioned documents, background migration scripts, canary deployment, feature toggle для старых/новых форматов, rolling updates и dual writing.

  15. Какие методы используются для горячего восстановления данных в NoSQL?
    Point-in-time recovery, oplog tailing, streaming из Kafka, read-repair, hinted handoff, backup restore с incremental checkpoint.

  16. Какие особенности работы с JSON-типами в различных NoSQL-системах?
    MongoDB — BSON с динамической схемой; PostgreSQL — JSONB (не наш курс, но важно понимать); Couchbase — N1QL поддерживает запросы по JSON-полям.

  17. Что такое cache-aside pattern и как он связан с NoSQL?
    Cache-aside — паттерн, при котором данные сначала читаются из кэша (например, Redis), а при отсутствии — из основной БД. Используется для повышения производительности.

  18. Как работают change streams в MongoDB и где они применяются?
    Change streams — механизм отслеживания изменений в коллекциях в реальном времени. Применяется для event-driven систем, синхронизации с другими хранилищами и триггеров.

  19. Какие стратегии шифрования данных используются в NoSQL?
    Transparent Data Encryption (TDE), field-level encryption, client-side encryption, TLS/SSL для передачи, использование Vault или KMS для управления ключами.

  20. Как работают consensus алгоритмы в контексте NoSQL-кластеров?
    Raft, Paxos, Multi-Paxos — используются для согласования лидеров, обеспечения последовательности записей и fault tolerance в распределённых системах (например, etcd, CockroachDB).

  21. Какие метрики наиболее важны при нагрузочном тестировании NoSQL-систем?
    Latency percentiles (p99, p95), throughput (RPS/WPS), error rate, GC pauses, replication lag, CPU/Memory usage, disk IO, network bandwidth.

  22. Как реализуется cross-region репликация в NoSQL?
    Через multi-master setup, async/sync geo-replication, logical streaming (например, Kafka Connect), managed services (AWS Global Tables) и custom sync сервисы.

  23. В чём отличия между логическим и физическим бэкапом в NoSQL?
    Логический — сохраняет данные в виде операций (логов, изменений документов), физический — копирует файлы БД. Логический легче переносить, физический быстрее восстанавливается.

  24. Какие инструменты используются для разработки и отладки запросов в NoSQL?
    MongoDB Compass, Studio 3T, Neo4j Browser, DataGrip с плагинами, DevTools, Jupyter Notebook + pymongo, Postman для REST API поверх NoSQL.

  25. Какие паттерны проектирования данных часто применяются в NoSQL?
    Embedded documents, aggregation references, bucketing, super columns, counter caching, sharded sequences, inverted index, graph patterns (friend-of-a-friend, shortest path).

  1. Какой тип NoSQL базы данных наиболее подходит для хранения социальных графов?
    A) Ключ-значение
    B) Документная
    C) Графовая
    D) Колоночная
    Ответ: C

  2. Какой механизм используется в Cassandra для обеспечения согласованности при записи?
    A) MVCC
    B) Quorum Write
    C) Vector Clocks
    D) Two-phase Commit
    Ответ: B

  3. Какой индекс в MongoDB позволяет выполнять текстовые поисковые запросы?
    A) Single Field Index
    B) Compound Index
    C) Text Index
    D) Hashed Index
    Ответ: C

  4. Что означает буква "E" в аббревиатуре BASE?
    A) Efficient
    B) Eventual
    C) Elastic
    D) Exclusive
    Ответ: B

  5. Какой алгоритм используется в некоторых NoSQL системах для достижения консенсуса между узлами?
    A) Paxos
    B) Raft
    C) Gossip
    D) Все вышеперечисленное
    Ответ: D

  6. Какой из следующих факторов НЕ влияет на выбор типа шардинга в MongoDB?
    A) Время жизни документа
    B) Распределение нагрузки
    C) Сложность запросов
    D) Частота обновлений
    Ответ: A

  7. Какой метод репликации передаёт изменения на уровне операций БД?
    A) Физическая репликация
    B) Логическая репликация
    C) Snapshot replication
    D) File-based replication
    Ответ: B

  8. Какая метрика наиболее важна для анализа производительности чтения в NoSQL?
    A) CPU Usage
    B) Disk IOPS
    C) Read Latency
    D) Network Bandwidth
    Ответ: C

  9. Какой из следующих подходов используется для разрешения конфликтов в eventual consistency системах?
    A) LRU eviction
    B) Last-write-wins
    C) FIFO queue
    D) Round-robin
    Ответ: B

  10. Какой протокол обеспечивает безопасный доступ к удалённой NoSQL базе?
    A) HTTP
    B) FTP
    C) SSL/TLS
    D) UDP
    Ответ: C

  11. Какой движок хранения используется в MongoDB по умолчанию, начиная с версии 3.0?
    A) MMAPv1
    B) WiredTiger
    C) RocksDB
    D) BerkeleyDB
    Ответ: B

  12. Какой механизм в Cassandra отвечает за временное хранение записей при недоступности целевого узла?
    A) Memtable
    B) SSTable
    C) Hinted Handoff
    D) Bloom Filter
    Ответ: C

  13. Какой тип сериализации данных лучше всего подходит для компактного хранения и высокой скорости передачи?
    A) JSON
    B) XML
    C) Avro
    D) CSV
    Ответ: C

  14. Какой из перечисленных принципов является основным в CAP-теореме?
    A) Atomicity
    B) Availability
    C) Durability
    D) Isolation
    Ответ: B

  15. Какой инструмент можно использовать для мониторинга производительности NoSQL баз данных?
    A) Grafana
    B) Docker
    C) Kubernetes
    D) Jenkins
    Ответ: A

  16. Какой метод пагинации в MongoDB считается наиболее эффективным при больших объёмах данных?
    A) skip() + limit()
    B) find().limit()
    C) where + sort
    D) count()
    Ответ: C

  17. Какая стратегия шифрования применяется на уровне отдельных полей в NoSQL?
    A) TDE
    B) Field-level encryption
    C) TLS
    D) Vault-based encryption
    Ответ: B

  18. Какой тип партиционирования данных в NoSQL наиболее эффективен для равномерного распределения нагрузки?
    A) Range-based
    B) List-based
    C) Hash-based
    D) Zone-based
    Ответ: C

  19. Какой из следующих паттернов используется для повышения отказоустойчивости в распределённых системах?
    A) Singleton
    B) Circuit Breaker
    C) Observer
    D) Strategy
    Ответ: B

  20. Какой из следующих параметров определяет количество успешных подтверждений при записи в Cassandra?
    A) Consistency Level
    B) TTL
    C) Replication Factor
    D) GC Grace Seconds
    Ответ: A

  21. Какой тип бэкапа включает копирование физических файлов базы данных?
    A) Логический
    B) Онлайновый
    C) Физический
    D) Incremental
    Ответ: C

  22. Какое свойство системы гарантирует, что данные будут доступны даже после сбоя?
    A) Consistency
    B) Partition tolerance
    C) Availability
    D) Durability
    Ответ: D

  23. Какой из следующих методов может использоваться для реализации транзакций в MongoDB?
    A) Two-phase commit
    B) Redis Lua script
    C) Kafka Connect
    D) MapReduce
    Ответ: A

  24. Какой из следующих документов не поддерживает ACID-транзакции в MongoDB?
    A) WiredTiger
    B) InMemory
    C) MMAPv1
    D) All of the above
    Ответ: C

  25. Какой из следующих паттернов проектирования данных используется для хранения связанных сущностей в одном документе?
    A) Bucketing
    B) Embedded Documents
    C) Aggregation References
    D) Graph Patterns
    Ответ: B

  1. Какой из следующих факторов НАИБОЛЕЕ критичен при выборе NoSQL базы для high-write нагрузки?
    A) Поддержка транзакций
    B) Гибкая схема данных
    C) Горизонтальная масштабируемость
    D) Поддержка ACID
    Ответ: C

  2. Что означает термин "sharding" в контексте NoSQL?
    A) Резервное копирование данных
    B) Логическое разделение таблиц
    C) Горизонтальное разделение данных между узлами
    D) Шифрование на уровне столбцов
    Ответ: C

  3. Какая метрика используется для определения времени ответа системы на запрос чтения?
    A) Throughput
    B) Write Latency
    C) Read Latency
    D) CPU Load
    Ответ: C

  4. Какой тип индекса в MongoDB подходит для геопространственных данных?
    A) Single Field Index
    B) Hashed Index
    C) 2dsphere Index
    D) TTL Index
    Ответ: C

  5. Какой механизм в Cassandra используется для обнаружения и восстановления устаревших данных?
    A) Compaction
    B) Hinted Handoff
    C) Merkle Trees
    D) Gossip Protocol
    Ответ: C

  6. Какое свойство систем, согласно CAP-теореме, жертвуется при обеспечении высокой доступности и устойчивости к разрывам сети?
    A) Partition Tolerance
    B) Consistency
    C) Availability
    D) Atomicity
    Ответ: B

  7. Какой формат сериализации данных наиболее эффективен по скорости десериализации?
    A) JSON
    B) XML
    C) Avro
    D) MessagePack
    Ответ: D

  8. Какой тип отказоустойчивости реализуется через кворумное чтение/запись?
    A) Active-Active
    B) Active-Passive
    C) Quorum-based
    D) Stateless
    Ответ: C

  9. Какой из перечисленных движков хранения не используется в MongoDB?
    A) WiredTiger
    B) MMAPv1
    C) RocksDB
    D) Berkeley DB
    Ответ: C

  10. Какой механизм в распределённых системах позволяет отслеживать причинность событий?
    A) Timestamp
    B) Vector Clock
    C) Bloom Filter
    D) Sequence Number
    Ответ: B

  11. Какой из следующих подходов применяется для минимизации задержек при чтении в реплицированных системах?
    A) Read from Leader Only
    B) Read from Any Replica
    C) Read from Follower with Lowest Lag
    D) Random Read
    Ответ: C

  12. Какой параметр в Cassandra определяет количество копий данных?
    A) Consistency Level
    B) Replication Factor
    C) GC Grace Seconds
    D) TTL
    Ответ: B

  13. Какой из следующих методов позволяет выполнять агрегацию данных в MongoDB?
    A) MapReduce
    B) Aggregation Pipeline
    C) Group By Clause
    D) A и B
    Ответ: D

  14. Какой из перечисленных паттернов проектирования данных используется для хранения временных серий?
    A) Bucketing
    B) Embedded Documents
    C) Super Columns
    D) Inverted Index
    Ответ: A

  15. Какой протокол используется в большинстве графовых БД для передачи данных?
    A) HTTP/REST
    B) Gremlin
    C) SQL
    D) gRPC
    Ответ: B

  16. Какой из следующих принципов гарантирует, что успешная запись сохранится даже при сбое?
    A) Isolation
    B) Atomicity
    C) Durability
    D) Consistency
    Ответ: C

  17. Какой тип шардинга в MongoDB лучше всего подходит для диапазонных запросов?
    A) Hash-based
    B) Zone-based
    C) Range-based
    D) Hybrid
    Ответ: C

  18. Какой из следующих инструментов может использоваться для анализа логов NoSQL систем?
    A) Prometheus
    B) Grafana
    C) ELK Stack
    D) Все вышеперечисленное
    Ответ: D

  19. Какой механизм в Redis используется для автоматического удаления ключей по истечении времени?
    A) TTL
    B) LRU
    C) LFU
    D) Eviction Policy
    Ответ: A

  20. Какой тип индекса в MongoDB может быть создан только для одного поля?
    A) Compound Index
    B) Text Index
    C) Single Field Index
    D) Partial Index
    Ответ: C

  21. Какой из следующих подходов используется для тестирования отказоустойчивости NoSQL кластера?
    A) Chaos Engineering
    B) Unit Testing
    C) Integration Testing
    D) Regression Testing
    Ответ: A

  22. Какой алгоритм используется в LSM-tree хранилищах для ускорения проверки наличия ключа?
    A) Binary Search Tree
    B) B+ Tree
    C) Bloom Filter
    D) Trie
    Ответ: C

  23. Какой из следующих методов используется для горячего восстановления данных в MongoDB?
    A) fs-snapshot
    B) oplog tailing
    C) mongorestore
    D) Все вышеперечисленное
    Ответ: D

  24. Какой тип сериализации данных позволяет легко читать данные человеком и программой?
    A) Avro
    B) Protobuf
    C) JSON
    D) MessagePack
    Ответ: C

  25. Какой из следующих паттернов используется для разделения данных на основе региональной принадлежности?
    A) Graph Pattern
    B) Zone-based Sharding
    C) Bucketing
    D) Embedded Documents
    Ответ: B

  1. Какой из следующих механизмов используется в MongoDB для отслеживания изменений в коллекциях?
    A) Change Streams
    B) Triggers
    C) Event Hooks
    D) Log Tailing
    Ответ: A

  2. Какой тип согласованности гарантирует, что все операции чтения увидят последнее записанное значение?
    A) Weak Consistency
    B) Eventual Consistency
    C) Strong Consistency
    D) Causal Consistency
    Ответ: C

  3. Какой параметр в Cassandra определяет количество успешных подтверждений записи перед её завершением?
    A) Replication Factor
    B) TTL
    C) Consistency Level
    D) Compaction Strategy
    Ответ: C

  4. Какой метод репликации позволяет снизить нагрузку на мастер-узел за счёт чтения с реплик?
    A) Single-master replication
    B) Multi-master replication
    C) Read-from-replica
    D) Cascading replication
    Ответ: C

  5. Какое свойство системы описывает способность восстанавливаться после сбоев без потери данных?
    A) Availability
    B) Scalability
    C) Durability
    D) Fault Tolerance
    Ответ: D

  6. Какой из перечисленных инструментов НЕ является клиентской библиотекой для работы с NoSQL базами?
    A) PyMongo
    B) Golang Driver for Neo4j
    C) Hibernate ORM
    D) Node.js Redis Client
    Ответ: C

  7. Какой тип шифрования применяется к данным при хранении на диске?
    A) In-memory encryption
    B) Field-level encryption
    C) Transparent Data Encryption (TDE)
    D) TLS encryption
    Ответ: C

  8. Какая стратегия масштабирования предполагает добавление новых узлов в систему?
    A) Vertical Scaling
    B) Horizontal Scaling
    C) Hybrid Scaling
    D) Dynamic Scaling
    Ответ: B

  9. Какой из следующих факторов влияет на производительность запросов в документной БД?
    A) Размер индекса
    B) Уровень сериализации
    C) Количество реплик
    D) Все вышеперечисленное
    Ответ: D

  10. Какой из следующих паттернов проектирования данных используется для оптимизации поиска через обратные ссылки?
    A) Bucketing
    B) Embedded Documents
    C) Inverted Index
    D) Graph Pattern
    Ответ: C

  11. Какой механизм в LSM-tree движках объединяет файлы SSTable и удаляет устаревшие данные?
    A) Bloom Filter
    B) Memtable Flush
    C) Compaction
    D) Write-ahead Log
    Ответ: C

  12. Какой из следующих принципов CAP-теоремы наиболее важен для банковских транзакций?
    A) Consistency
    B) Availability
    C) Partition Tolerance
    D) Все одинаково важны
    Ответ: A

  13. Какой из следующих форматов лучше всего подходит для сериализации схематизированных данных?
    A) JSON
    B) BSON
    C) Avro
    D) MessagePack
    Ответ: C

  14. Какой механизм в распределённых системах используется для выбора лидера кластера?
    A) Vector Clock
    B) Raft
    C) Bloom Filter
    D) MVCC
    Ответ: B

  15. Какой из следующих параметров определяет время жизни ключа в Redis?
    A) LRU
    B) LFU
    C) TTL
    D) Eviction Policy
    Ответ: C

  16. Какой тип отказоустойчивости позволяет системе продолжать работу даже при разделении сети?
    A) Active-Passive
    B) Quorum-based
    C) Partition Tolerant
    D) Stateless
    Ответ: C

  17. Какой из следующих подходов используется для обработки больших наборов данных в NoSQL?
    A) MapReduce
    B) OLTP
    C) ACID
    D) Normalization
    Ответ: A

  18. Какой из следующих паттернов используется для снижения сетевой нагрузки при частых чтениях?
    A) Cache-aside
    B) Circuit Breaker
    C) Retry Policy
    D) Load Balancing
    Ответ: A

  19. Какой механизм в MongoDB обеспечивает автоматическое восстановление после сбоя кластера?
    A) Sharding
    B) Replica Set
    C) Indexing
    D) Aggregation
    Ответ: B

  20. Какой из следующих терминов описывает процесс создания физической копии данных для восстановления?
    A) Archiving
    B) Backup
    C) Snapshot
    D) B и C
    Ответ: D

  21. Какой из следующих инструментов может использоваться для анализа производительности запросов в MongoDB?
    A) Explain()
    B) Profiler
    C) Compass
    D) Все вышеперечисленное
    Ответ: D

  22. Какой из следующих принципов BASE означает, что система в конечном итоге достигнет согласованного состояния?
    A) Basically Available
    B) Soft state
    C) Eventually consistent
    D) Elastic
    Ответ: C

  23. Какой тип партиционирования в NoSQL позволяет равномерно распределять данные по ключам?
    A) Range-based
    B) Hash-based
    C) Zone-based
    D) List-based
    Ответ: B

  24. Какой из следующих механизмов используется для контроля доступа в NoSQL системах?
    A) RBAC
    B) MAC
    C) DAC
    D) Все вышеперечисленное
    Ответ: D

  25. Какой из следующих паттернов проектирования используется для реализации рекомендательных систем?
    A) Friend-of-a-friend
    B) Bucketing
    C) Embedded Documents
    D) Super Columns
    Ответ: A

Экзаменационный билет №1

Теоретическая часть:

  1. Опишите основные различия между ACID и BASE подходами в контексте управления транзакциями в базах данных.
  2. Какие механизмы используются в распределённых NoSQL системах для обеспечения отказоустойчивости?

Ответы:

  1. ACID (Atomicity, Consistency, Isolation, Durability) — это строгий набор гарантий, применяемый к транзакциям в реляционных СУБД, обеспечивающий высокую согласованность.
    BASE (Basically Available, Soft state, Eventually consistent) — более гибкий подход, характерный для NoSQL-систем, допускающий временную несогласованность ради доступности и масштабируемости.

  2. Для обеспечения отказоустойчивости в распределённых NoSQL системах применяются:

    • Репликация данных (primary-secondary, multi-master),
    • Кворумное чтение/запись,
    • Heartbeat мониторинг,
    • Автоматический failover,
    • Использование consensus алгоритмов (Raft, Paxos).

Практическая часть:

  1. Напишите скрипт на Python с использованием PyMongo, который подключается к локальному экземпляру MongoDB, создаёт коллекцию users, добавляет 5 документов с полями name и age, а затем выводит список всех пользователей старше 25 лет.
from pymongo import MongoClient

# Подключение к MongoDB
client = MongoClient('mongodb://localhost:27017/')
db = client['user_db']
collection = db['users']

# Удаление предыдущих записей
collection.delete_many({})

# Вставка новых документов
users = [
    {"name": "Alice", "age": 30},
    {"name": "Bob", "age": 22},
    {"name": "Charlie", "age": 28},
    {"name": "David", "age": 35},
    {"name": "Eve", "age": 24}
]
collection.insert_many(users)

# Поиск пользователей старше 25 лет
results = collection.find({"age": {"$gt": 25}})
for user in results:
    print(user)

Экзаменационный билет №2

Теоретическая часть:

  1. Что такое шардинг и какие типы шардинга поддерживаются в MongoDB?
  2. Какие факторы необходимо учитывать при выборе типа NoSQL базы данных для проекта?

Ответы:

  1. Шардинг — это процесс горизонтального разделения данных между несколькими узлами.
    Типы шардинга в MongoDB:

    • Range-based — данные разделяются по диапазонам ключей (подходит для range-запросов).
    • Hash-based — равномерное распределение данных через хэширование ключей.
    • Zone-based — данные распределяются по зонам, например, регионам или серверным стойкам.
  2. При выборе NoSQL БД учитываются:

    • Модель данных (документы, графы, колонки, ключ-значение),
    • Требования к согласованности (strong/eventual),
    • Производительность (read/write throughput),
    • Горизонтальная масштабируемость,
    • Поддержка транзакций,
    • Инфраструктурные требования (облако, on-premise),
    • Экосистема и инструменты (мониторинг, бэкапы, миграции).

Практическая часть:

  1. Напишите запрос на Cypher (Neo4j), который создаёт граф пользователей и их друзей. Добавьте трёх пользователей: Alice, Bob, Charlie. Alice дружит с Bob, Bob дружит с Charlie. Затем найдите всех друзей Alice и выведите их имена.
// Создание пользователей
CREATE (a:User {name: "Alice"})
CREATE (b:User {name: "Bob"})
CREATE (c:User {name: "Charlie"})

// Создание связей
CREATE (a)-[:FRIEND]->(b)
CREATE (b)-[:FRIEND]->(c)

// Поиск друзей Alice
MATCH (a:User {name: "Alice"})-[:FRIEND]->(friend)
RETURN friend.name AS name

Экзаменационный билет №3

Теоретическая часть:

  1. Что означает CAP-теорема и как она влияет на проектирование распределённых NoSQL систем?
  2. Какие механизмы используются в Cassandra для повышения производительности записи?

Ответы:

  1. CAP-теорема утверждает, что в распределённой системе можно одновременно реализовать только два из трёх свойств: Consistency (согласованность), Availability (доступность), Partition tolerance (устойчивость к сетевым разрывам).
    Это влияет на выбор системы:

    • CP-системы (Cassandra при QUORUM) — жертвуют доступностью ради согласованности.
    • AP-системы (DynamoDB) — жертвуют согласованностью ради доступности.
  2. Cassandra оптимизирована под write-heavy нагрузку. Механизмы:

    • Write-ahead log (WAL) — для восстановления после сбоев,
    • Memtable — временный буфер в памяти,
    • SSTable — immutable файлы на диске,
    • Compaction — объединяет SSTable и удаляет устаревшие данные,
    • Hinted handoff — временное хранение данных при недоступности узла.

Практическая часть:

  1. Напишите скрипт на Node.js, использующий Redis, который сохраняет 5 пар ключ-значение, где ключ — имя пользователя, значение — возраст. Затем скрипт должен вывести все значения, у которых возраст больше 25 лет.
const redis = require('redis');
const client = redis.createClient();

client.on('error', (err) => {
    console.error(`Redis error: ${err}`);
});

async function main() {
    const users = {
        'Alice': 30,
        'Bob': 22,
        'Charlie': 28,
        'David': 35,
        'Eve': 24
    };

    // Сохранение данных
    for (let [name, age] of Object.entries(users)) {
        await client.set(name, age);
    }

    // Получение данных
    for (let name of Object.keys(users)) {
        let age = await client.get(name);
        if (parseInt(age) > 25) {
            console.log(`${name}: ${age}`);
        }
    }

    client.quit();
}

main();

Экзаменационный билет №4

Теоретическая часть:

  1. Что такое eventual consistency и в каких системах она применяется?
  2. Какие метрики наиболее важны при эксплуатации NoSQL-систем?

Ответы:

  1. Eventual consistency — это модель согласованности, при которой все копии данных со временем становятся одинаковыми. Применяется в системах, где важна высокая доступность и масштабируемость, например, Apache Cassandra, Amazon DynamoDB, Riak.

  2. Основные метрики:

    • Latency (p99, p95) — задержка операций чтения/записи,
    • Throughput (RPS/WPS) — количество операций в секунду,
    • CPU/Memory usage — загрузка ресурсов,
    • Disk I/O — использование дисковой подсистемы,
    • Replication lag — задержка репликации,
    • GC pauses — время сборки мусора (в JVM-движках),
    • Error rate — частота ошибок,
    • Connection count — количество активных подключений.

Практическая часть:

  1. Напишите функцию на Python, которая принимает список пользователей (с полями id, name, email) и сохраняет их в MongoDB, обновляя существующие документы по id. Также реализуйте вывод всех пользователей, отсортированных по имени.
from pymongo import MongoClient, ASCENDING

def upsert_and_list_users(users):
    client = MongoClient('mongodb://localhost:27017/')
    db = client['user_db']
    coll = db['users']

    # Обновление или вставка
    for user in users:
        coll.update_one(
            {'id': user['id']},
            {'$set': {'name': user['name'], 'email': user['email']}},
            upsert=True
        )

    # Вывод всех пользователей по имени
    for doc in coll.find().sort('name', ASCENDING):
        print(doc)

# Пример использования
sample_users = [
    {'id': 1, 'name': 'Bob', 'email': 'bob@example.com'},
    {'id': 2, 'name': 'Alice', 'email': 'alice@example.com'}
]
upsert_and_list_users(sample_users)

Экзаменационный билет №5

Теоретическая часть:

  1. Что такое TTL-индекс в MongoDB и когда его стоит использовать?
  2. Какие особенности проектирования схем характерны для Cassandra?

Ответы:

  1. TTL-индекс (Time-To-Live Index) автоматически удаляет документы из коллекции после истечения указанного времени.
    Используется:

    • Для временных данных (логи, кэш),
    • Чтобы избежать необходимости ручного удаления устаревших записей.
  2. Особенности проектирования схем в Cassandra:

    • Проектирование «под запросы»,
    • Оптимизация под write-heavy нагрузки,
    • Использование составных первичных ключей (partition key + clustering columns),
    • Денормализация данных,
    • Ограничения secondary индексов,
    • Учет особенностей партиционирования и распределения данных.

Практическая часть:

  1. Напишите CQL-скрипт для Cassandra, который создаёт keyspace logs, таблицу events, добавляет 3 события с полями id, timestamp, message, а затем выводит все события за последний час.
-- Создание keyspace
CREATE KEYSPACE IF NOT EXISTS logs
WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

-- Использование keyspace
USE logs;

-- Создание таблицы
CREATE TABLE IF NOT EXISTS events (
    id UUID PRIMARY KEY,
    timestamp TIMESTAMP,
    message TEXT
);

-- Вставка данных
INSERT INTO events (id, timestamp, message) VALUES (uuid(), toTimestamp(now()), 'Login success');
INSERT INTO events (id, timestamp, message) VALUES (uuid(), toTimestamp(now()), 'Failed login attempt');
INSERT INTO events (id, timestamp, message) VALUES (uuid(), toTimestamp(now()), 'System reboot');

-- Выборка событий за последний час
SELECT * FROM events
WHERE timestamp > now() - INTERVAL 1 HOUR;

Экзаменационный билет №6

Теоретическая часть:

  1. Какие типы индексов поддерживаются в MongoDB и в каких сценариях они применяются?
  2. Что такое vector clock и где он используется?

Ответы:

  1. В MongoDB поддерживаются следующие типы индексов:

    • Single Field — для поиска по одному полю.
    • Compound Index — для составных запросов, использующих несколько полей.
    • Multikey Index — для массивов.
    • Text Index — для полнотекстового поиска.
    • Geospatial Index (2d / 2dsphere) — для геопространственных данных.
    • Hashed Index — для шардинга и равномерного распределения нагрузки.
    • TTL Index — для автоматического удаления устаревших документов.
  2. Vector clock — это механизм отслеживания причинно-следственных связей между изменениями в распределённых системах. Используется в системах с eventual consistency (например, Riak) для разрешения конфликтов при репликации.

Практическая часть:

  1. Напишите скрипт на Python, который подключается к Redis и реализует простую систему очереди задач через Redis Lists. Добавьте 5 задач в очередь tasks, а затем последовательно извлекайте их и выводите в консоль.
import redis

# Подключение к Redis
r = redis.Redis(host='localhost', port=6379, db=0)

# Очистка очереди
r.delete('tasks')

# Добавление задач
for i in range(1, 6):
    r.rpush('tasks', f'Task {i}')

# Обработка очереди
while True:
    task = r.lpop('tasks')
    if not task:
        break
    print(f'Processing: {task.decode("utf-8")}')

Экзаменационный билет №7

Теоретическая часть:

  1. Какие особенности проектирования схем характерны для графовых баз данных?
  2. Какие стратегии используются для обеспечения отказоустойчивости в NoSQL-системах?

Ответы:

  1. Проектирование схем в графовых БД основывается на модели "узлы → связи". Узлы представляют объекты, связи — отношения между ними. Ключевые моменты:

    • Оптимизация обхода графа,
    • Индексирование вершин и рёбер,
    • Эффективное представление сложных отношений (социальные графы, рекомендации).
  2. Для обеспечения отказоустойчивости в NoSQL-системах применяются:

    • Репликация (синхронная/асинхронная),
    • Кворумное чтение/запись,
    • Heartbeat мониторинг состояния узлов,
    • Автоматический failover,
    • Cross-region deployment,
    • Использование consensus алгоритмов (Raft, Paxos).

Практическая часть:

  1. Напишите Cypher-скрипт для Neo4j, который создаёт социальный граф с пользователями Alice, Bob, Charlie, David. Установите связи: Alice дружит с Bob и Charlie; Charlie дружит с David. Затем найдите всех друзей друзей Alice и выведите их имена.
// Создание пользователей
CREATE (a:User {name: "Alice"})
CREATE (b:User {name: "Bob"})
CREATE (c:User {name: "Charlie"})
CREATE (d:User {name: "David"})

// Установка связей
CREATE (a)-[:FRIEND]->(b)
CREATE (a)-[:FRIEND]->(c)
CREATE (c)-[:FRIEND]->(d)

// Поиск друзей друзей Alice
MATCH (a:User {name: "Alice"})-[:FRIEND]->()-[:FRIEND]->(friend)
WHERE friend <> a
RETURN DISTINCT friend.name AS name

Экзаменационный билет №8

Теоретическая часть:

  1. Как работает MapReduce в контексте NoSQL?
  2. Какие проблемы могут возникнуть при масштабировании NoSQL-систем?

Ответы:

  1. MapReduce — парадигма обработки больших объёмов данных, позволяющая выполнять агрегации и анализ в распределённой среде. Применяется в MongoDB, Hadoop, Couchbase и других системах. Состоит из двух фаз:

    • Map — преобразование входных данных в пары ключ-значение.
    • Reduce — группировка и агрегация значений по ключам.
  2. При масштабировании NoSQL-систем возможны следующие проблемы:

    • Hot partitions (неравномерное распределение нагрузки),
    • Network partitioning,
    • Потеря согласованности,
    • Сложности с миграцией данных,
    • Увеличение latency,
    • Управление состоянием кластера.

Практическая часть:

  1. Напишите функцию на Python, которая сохраняет список пользователей в MongoDB, используя bulk операции, и реализует поиск пользователей по возрасту с использованием $gte.
from pymongo import MongoClient, ASCENDING
from pymongo import InsertOne

def bulk_insert_and_query(users, min_age):
    client = MongoClient('mongodb://localhost:27017/')
    db = client['user_db']
    coll = db['users']

    # Bulk insert
    operations = [InsertOne(user) for user in users]
    coll.bulk_write(operations)

    # Query by age
    results = coll.find({"age": {"$gte": min_age}})
    for doc in results:
        print(doc)

# Пример использования
sample_users = [
    {'name': 'Alice', 'age': 30},
    {'name': 'Bob', 'age': 22},
    {'name': 'Charlie', 'age': 28}
]
bulk_insert_and_query(sample_users, 25)

Экзаменационный билет №9

Теоретическая часть:

  1. Что такое MVCC и как он применяется в NoSQL?
  2. Какие практики используются для тестирования и отладки NoSQL решений?

Ответы:

  1. MVCC (Multi-Version Concurrency Control) — механизм управления конкурентным доступом, позволяющий разным транзакциям видеть разные версии данных. Применяется в некоторых документных и колоночных БД (например, Couchbase, PostgreSQL) для повышения параллелизма и снижения блокировок.

  2. Для тестирования и отладки NoSQL решений применяются:

    • Unit- и интеграционное тестирование,
    • Load testing (JMeter, Locust),
    • Profiling и explain(),
    • Логирование и метрики,
    • Использование mock-серверов,
    • A/B тестирование с реальными нагрузками.

Практическая часть:

  1. Напишите CQL-скрипт для Cassandra, который создаёт таблицу sensor_data с полями sensor_id, timestamp, value. Добавьте 5 записей и реализуйте выборку данных за последние 24 часа.
-- Создание keyspace
CREATE KEYSPACE IF NOT EXISTS telemetry
WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

-- Переключение на keyspace
USE telemetry;

-- Создание таблицы
CREATE TABLE IF NOT EXISTS sensor_data (
    sensor_id UUID,
    timestamp TIMESTAMP,
    value DOUBLE,
    PRIMARY KEY (sensor_id, timestamp)
);

-- Вставка данных
INSERT INTO sensor_data (sensor_id, timestamp, value) VALUES (uuid(), now(), 23.5);
INSERT INTO sensor_data (sensor_id, timestamp, value) VALUES (uuid(), now(), 24.1);
INSERT INTO sensor_data (sensor_id, timestamp, value) VALUES (uuid(), now(), 22.7);
INSERT INTO sensor_data (sensor_id, timestamp, value) VALUES (uuid(), now(), 25.0);
INSERT INTO sensor_data (sensor_id, timestamp, value) VALUES (uuid(), now(), 26.2);

-- Выборка за последние 24 часа
SELECT * FROM sensor_data
WHERE sensor_id IN (SELECT sensor_id FROM system.local)
AND timestamp > now() - INTERVAL 1 DAY;

Экзаменационный билет №10

Теоретическая часть:

  1. Что такое hinted handoff и в какой системе он используется?
  2. Как работают change streams в MongoDB и где они применяются?

Ответы:

  1. Hinted handoff — временная запись данных на другом узле в случае недоступности целевого, чтобы восстановить данные после возврата узла в строй. Применяется в Apache Cassandra.

  2. Change streams — механизм отслеживания изменений в коллекциях в реальном времени. Применяется для event-driven систем, синхронизации с другими хранилищами и триггеров. Реализован в MongoDB начиная с версии 3.6.

Практическая часть:

  1. Напишите Node.js скрипт, который подключается к MongoDB, создаёт коллекцию orders, добавляет 3 заказа с полями product, quantity, price, а затем рассчитывает общую сумму всех заказов через Aggregation Pipeline.
const { MongoClient } = require('mongodb');

async function main() {
    const uri = 'mongodb://localhost:27017/';
    const client = new MongoClient(uri);

    try {
        await client.connect();
        const database = client.db('store');
        const collection = database.collection('orders');

        // Удаление предыдущих данных
        await collection.deleteMany({});

        // Вставка новых заказов
        const orders = [
            { product: "A", quantity: 2, price: 10 },
            { product: "B", quantity: 1, price: 15 },
            { product: "C", quantity: 3, price: 5 }
        ];
        await collection.insertMany(orders);

        // Агрегация: сумма total_price
        const pipeline = [
            {
                $addFields: {
                    totalPrice: { $multiply: ["$quantity", "$price"] }
                }
            },
            {
                $group: {
                    _id: null,
                    totalAmount: { $sum: "$totalPrice" }
                }
            }
        ];

        const result = await collection.aggregate(pipeline).toArray();
        console.log(`Total amount: ${result[0].totalAmount}`);
    } finally {
        await client.close();
    }
}

main().catch(console.error);

Экзаменационный билет №11

Теоретическая часть:

  1. Что такое materialized view в NoSQL и как она применяется?
  2. Какие особенности проектирования схем характерны для Cassandra?

Ответы:

  1. Materialized view — это предрассчитанное представление данных, хранящееся физически. Используется для ускорения сложных запросов, особенно в Cassandra и Couchbase. В отличие от виртуальных представлений, данные хранятся заранее и обновляются при изменении исходных таблиц.

  2. Особенности проектирования схем в Cassandra :

    • Проектирование под запросы (query-driven),
    • Использование составного первичного ключа (partition key + clustering columns),
    • Денормализация данных,
    • Оптимизация под write-heavy нагрузки,
    • Ограничения secondary индексов,
    • Учет особенностей распределения данных по токенам.

Практическая часть:

  1. Напишите CQL-скрипт для Cassandra, который создаёт keyspace inventory, таблицу products с полями product_id, name, category, price. Добавьте 5 записей и реализуйте выборку товаров из категории 'Electronics' с ценой выше 100.
-- Создание keyspace
CREATE KEYSPACE IF NOT EXISTS inventory
WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

-- Переключение на keyspace
USE inventory;

-- Создание таблицы
CREATE TABLE IF NOT EXISTS products (
    product_id UUID PRIMARY KEY,
    name TEXT,
    category TEXT,
    price DECIMAL
);

-- Вставка данных
INSERT INTO products (product_id, name, category, price) VALUES (uuid(), 'Laptop', 'Electronics', 1200.00);
INSERT INTO products (product_id, name, category, price) VALUES (uuid(), 'T-Shirt', 'Clothing', 29.99);
INSERT INTO products (product_id, name, category, price) VALUES (uuid(), 'Smartphone', 'Electronics', 800.00);
INSERT INTO products (product_id, name, category, price) VALUES (uuid(), 'Tablet', 'Electronics', 450.00);
INSERT INTO products (product_id, name, category, price) VALUES (uuid(), 'Headphones', 'Electronics', 150.00);

-- Выборка товаров из категории "Electronics" с ценой > 100
SELECT * FROM products WHERE category = 'Electronics' AND price > 100;

Экзаменационный билет №12

Теоретическая часть:

  1. Как работают TTL-коллекции в Redis и как они управляются?
  2. Какие метрики необходимо отслеживать при эксплуатации NoSQL-баз?

Ответы:

  1. TTL (Time To Live) в Redis позволяет задавать время жизни ключа. После истечения этого времени ключ автоматически удаляется. Управление осуществляется через команды:

    • EXPIRE key seconds — установить TTL в секундах.
    • PEXPIRE key milliseconds — установить TTL в миллисекундах.
    • TTL key — проверить оставшееся время жизни.
    • Полезно для кэширования, временных данных, сессий.
  2. Основные метрики для мониторинга:

    • Latency (p99, p95) — время выполнения операций чтения/записи.
    • Throughput (RPS/WPS) — количество операций в секунду.
    • CPU/Memory usage — использование ресурсов.
    • Disk I/O — скорость работы с диском.
    • Replication lag — задержка между мастером и репликами.
    • Error rate — частота ошибок.
    • Connection count — количество активных соединений.
    • Compaction stats — в системах типа Cassandra, RocksDB.

Практическая часть:

  1. Напишите скрипт на Python, использующий PyMongo, который создает коллекцию sessions, добавляет 3 документа с полем user_id и TTL на 60 секунд, а затем выводит список всех активных сессий спустя 30 секунд.
from pymongo import MongoClient
import time

client = MongoClient('mongodb://localhost:27017/')
db = client['session_db']
collection = db['sessions']

# Удаление предыдущих данных
collection.delete_many({})

# Создание TTL-индекса
collection.create_index("created_at", expireAfterSeconds=60)

# Добавление сессий
sessions = [
    {"user_id": 1, "created_at": datetime.utcnow()},
    {"user_id": 2, "created_at": datetime.utcnow()},
    {"user_id": 3, "created_at": datetime.utcnow()}
]
collection.insert_many(sessions)

# Ждём 30 секунд
time.sleep(30)

# Вывод активных сессий
for session in collection.find():
    print(session)

Экзаменационный билет №13

Теоретическая часть:

  1. Какие проблемы могут возникнуть при использовании long-running connections в NoSQL-клиентах?
  2. Как организовать безопасный удалённый доступ к NoSQL-базе?

Ответы:

  1. Проблемы при использовании долгих соединений:

    • Сетевые разрывы и таймауты,
    • Утечки памяти (memory leaks),
    • Застойные (stale) соединения,
    • Исчерпание ресурсов (zombie процессы, лимиты на подключения),
    • Решаются через keep-alive, connection pooling, health checks, reconnection policies.
  2. Для безопасного удалённого доступа к NoSQL базам:

    • Использование SSH-туннелей или VPN,
    • Шифрование TLS/SSL,
    • RBAC (Role-Based Access Control),
    • Настройка фаервола и VPC,
    • Аудит подключений,
    • API gateways с авторизацией,
    • Принцип минимальных привилегий (least privilege).

Практическая часть:

  1. Напишите Cypher-скрипт для Neo4j, который создаёт граф пользователей и их подписок на каналы YouTube. Добавьте трёх пользователей и два канала. Реализуйте поиск всех пользователей, подписанных на оба канала.
// Создание пользователей и каналов
CREATE (u1:User {name: "Alice"})
CREATE (u2:User {name: "Bob"})
CREATE (u3:User {name: "Charlie"})
CREATE (c1:Channel {title: "Tech Reviews"})
CREATE (c2:Channel {title: "Cooking Tips"})

// Подписки
CREATE (u1)-[:SUBSCRIBED]->(c1)
CREATE (u1)-[:SUBSCRIBED]->(c2)
CREATE (u2)-[:SUBSCRIBED]->(c1)
CREATE (u3)-[:SUBSCRIBED]->(c2)

// Поиск пользователей, подписанных на оба канала
MATCH (u:User)-[:SUBSCRIBED]->(c1:Channel {title: "Tech Reviews"})
MATCH (u)-[:SUBSCRIBED]->(c2:Channel {title: "Cooking Tips"})
RETURN u.name AS name

Экзаменационный билет №14

Теоретическая часть:

  1. Как реализуется поддержка транзакций в NoSQL-системах?
  2. Какие практики используются для тестирования отказоустойчивости NoSQL-кластера?

Ответы:

  1. Поддержка транзакций в NoSQL:

    • MongoDB (4.0+) — многошардовые транзакции с двухфазным коммитом.
    • Couchbase — транзакции через SDK.
    • DynamoDB — ACID-транзакции на уровне одного элемента или партиции.
    • Cassandra — ограниченная поддержка через lightweight transactions (CAS).
    • Kafka Streams — event sourcing и stateful processing.
    • Saga Pattern — для распределённых транзакций вне БД.
  2. Практики тестирования отказоустойчивости:

    • Chaos Engineering (например, Chaos Monkey),
    • Принудительное отключение узлов,
    • Имитация сетевых разрывов,
    • Проверка восстановления из backup,
    • Stress testing,
    • Fault injection.

Практическая часть:

  1. Напишите Node.js скрипт, который подключается к Redis, сохраняет 5 пользовательских сессий с TTL в 60 секунд, а затем проверяет наличие активных сессий после 30 и 70 секунд.
const redis = require('redis');
const client = redis.createClient();

client.on('error', (err) => {
    console.error(`Redis error: ${err}`);
});

async function main() {
    const sessions = ['sess1', 'sess2', 'sess3', 'sess4', 'sess5'];

    // Сохранение сессий с TTL
    for (let sess of sessions) {
        await client.set(sess, 'active', 'EX', 60);
    }

    console.log('Waiting 30s...');
    await new Promise(r => setTimeout(r, 30000));

    console.log('Active after 30s:');
    for (let sess of sessions) {
        let val = await client.get(sess);
        console.log(`${sess}: ${val ? 'active' : 'expired'}`);
    }

    console.log('Waiting another 40s...');
    await new Promise(r => setTimeout(r, 40000));

    console.log('Active after 70s:');
    for (let sess of sessions) {
        let val = await client.get(sess);
        console.log(`${sess}: ${val ? 'active' : 'expired'}`);
    }

    client.quit();
}

main();

Экзаменационный билет №15

Теоретическая часть:

  1. Какие факторы влияют на производительность write-heavy нагрузки в NoSQL?
  2. Какие типы шардинга поддерживаются в MongoDB?

Ответы:

  1. Факторы, влияющие на write-heavy нагрузку:

    • Batch writes,
    • Write-ahead log (WAL),
    • Memtable/SSTables (LSM-tree),
    • Compaction strategy,
    • Размер буфера,
    • Дисковый IOPS,
    • Write concern,
    • fsync policy.
  2. Типы шардинга в MongoDB:

    • Range-based — данные делятся по диапазонам ключей (подходит для range-запросов).
    • Hash-based — равномерное распределение данных через хэширование ключей.
    • Zone-based — данные распределяются по зонам (например, регионам).

Практическая часть:

  1. Напишите функцию на Python, которая создаёт в MongoDB коллекцию logs с TTL-индексом на 60 секунд. Добавьте 5 записей и проверяет содержимое коллекции через 30 и 70 секунд.
from pymongo import MongoClient
from datetime import datetime, timedelta
import time

def test_ttl_index():
    client = MongoClient('mongodb://localhost:27017/')
    db = client['log_db']
    coll = db['logs']

    # Удаление старых данных
    coll.delete_many({})

    # Создание TTL-индекса
    coll.create_index("timestamp", expireAfterSeconds=60)

    # Добавление записей
    for i in range(5):
        coll.insert_one({"message": f"Log entry {i}", "timestamp": datetime.utcnow()})

    print("Logs added. Waiting 30s...")
    time.sleep(30)

    print("Logs after 30s:")
    for doc in coll.find():
        print(doc)

    print("Waiting another 40s...")
    time.sleep(40)

    print("Logs after 70s:")
    for doc in coll.find():
        print(doc)

test_ttl_index()

 

Кейс №1: "Проектирование высоконагруженной системы хранения пользовательских событий"


Описание ситуации:

Вы работаете в компании, которая разрабатывает платформу для аналитики пользовательского поведения. Система собирает события (например, клики, просмотры, сессии) от мобильных и веб-приложений в режиме реального времени.

Вам поручено спроектировать систему хранения данных на основе NoSQL базы, способную обрабатывать до 100 000 записей в секунду, обеспечивая при этом:

  • Высокую доступность,
  • Масштабируемость,
  • Быстрое чтение по пользовательским и временным фильтрам.

Предварительно выбрана Apache Cassandra , как система, оптимальная для write-heavy нагрузок.


Текущее состояние системы:

Модель данных:

CREATE TABLE user_events (
    user_id UUID,
    event_time TIMESTAMP,
    event_type TEXT,
    session_id UUID,
    metadata MAP<TEXT, TEXT>,
    PRIMARY KEY ((user_id), event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

Архитектура кластера:

  • 6 узлов,
  • Replication Factor = 3,
  • Consistency Level для записи — QUORUM, для чтения — ONE.

Нагрузка:

  • ~90 000 записей в секунду,
  • Частые запросы:
    • Получить все события пользователя за последние 24 часа.
    • Получить события определенного типа (например, "click") за период.

Проблемы, выявленные в процессе эксплуатации:

  1. Запросы на чтение выполняются медленно , особенно при выборке за длительный период.
  2. Некоторые узлы перегружены , наблюдается неравномерное распределение нагрузки (hot partitions).
  3. При увеличении числа пользователей возникают ошибки timeout и повышается latency .
  4. Некоторые данные теряются или не записываются при сетевых сбоях между клиентом и Cassandra.

Задача:

  1. Выявите причины проблем в текущем дизайне модели данных и архитектуре.
  2. Предложите изменения в модель данных, конфигурацию кластера и/или подход к работе с данными.
  3. Обоснуйте свои решения с точки зрения производительности, масштабируемости и отказоустойчивости.

Решение:

1. Проблема: Медленные запросы на чтение

Причина:
Текущий ключ (user_id) может стать «горячим» при наличии активных пользователей. Также при запросах за длительный период (например, месяц) необходимо сканировать большое число строк, что замедляет выполнение.

Решение:

  • Добавить партиционирование по времени: например, использовать составной partition key:
    PRIMARY KEY ((user_id, day), event_time)

2. Проблема: Hot partitions

Причина:
Если некоторые пользователи генерируют очень много событий, то их user_id становится точкой концентрации нагрузки.

Решение:

  • Использовать технику salting или bucketing : разделить данные одного пользователя на несколько логических подгрупп (например, по часам или по типам событий).
  • Либо применить шардинг на уровне приложения.

3. Проблема: Timeout и потеря данных при сетевых сбоях

Причина:
Consistency Level QUORUM требует подтверждения от большинства узлов. При потере связи даже с одним из них операция может завершиться ошибкой.

Решение:

  • Для write-операций использовать CL=LOCAL_QUORUM в многорегиональном кластере.
  • На стороне клиента реализовать retry-логику и буферизацию сообщений (например, через Kafka или собственный buffer с retransmit).

4. Проблема: Общая производительность

Дополнительные рекомендации:

  • Включить компрессию SSTable (LZ4, Snappy) для снижения I/O.
  • Настроить параметры compaction (например, TimeWindowCompactionStrategy для временных данных).
  • Использовать Materialized Views или внешние индексаторы (Elasticsearch) для сложных фильтраций по типу события.

Итог:

После изменений:

  • Чтение стало быстрее за счет более мелких партиций,
  • Устранены горячие точки,
  • Повышена отказоустойчивость и надежность записи,
  • Система стала готова к дальнейшему росту объемов данных.

Кейс №2: "Миграция микросервиса с реляционной БД на NoSQL"


Описание ситуации:

Вы работаете в команде разработки стартапа, занимающегося доставкой еды. В системе есть микросервис Orders, который изначально был построен на основе PostgreSQL и обрабатывает заказы пользователей.

С ростом числа пользователей (до 10 000 активных в час) система начала испытывать проблемы:

  • Высокая нагрузка на базу при одновременных операциях чтения/записи.
  • Медленные JOIN'ы между таблицами orders, users, restaurants, deliveries.
  • Проблемы с масштабированием — вертикальное ограничено, горизонтальное невозможно без сложных решений.

Вам поручено провести анализ возможности миграции сервиса Orders на NoSQL , а также предложить новую модель данных и архитектурное решение, которое позволит улучшить производительность и отказоустойчивость.


Текущее состояние системы:

Структура PostgreSQL:

-- Таблица пользователей
CREATE TABLE users (
    id UUID PRIMARY KEY,
    name TEXT,
    phone TEXT
);

-- Таблица ресторанов
CREATE TABLE restaurants (
    id UUID PRIMARY KEY,
    name TEXT,
    address TEXT
);

-- Таблица заказов
CREATE TABLE orders (
    id UUID PRIMARY KEY,
    user_id UUID REFERENCES users(id),
    restaurant_id UUID REFERENCES restaurants(id),
    total_price NUMERIC,
    status TEXT,
    created_at TIMESTAMP
);

-- Таблица доставки
CREATE TABLE deliveries (
    id UUID PRIMARY KEY,
    order_id UUID REFERENCES orders(id),
    courier_id UUID,
    delivery_time TIMESTAMP
);

Пример частого запроса:

SELECT o.id, u.name, r.name, o.total_price, d.delivery_time
FROM orders o
JOIN users u ON o.user_id = u.id
JOIN restaurants r ON o.restaurant_id = r.id
LEFT JOIN deliveries d ON o.id = d.order_id
WHERE o.status = 'in_progress';

Проблемы, выявленные после анализа:

  1. Высокая задержка JOIN'ов между несколькими таблицами при увеличении объёма данных.
  2. Невозможность горизонтального масштабирования PostgreSQL без внешних инструментов.
  3. Частые блокировки таблиц при параллельных транзакциях.
  4. Жесткая схема данных , которая затрудняет добавление новых полей или гибкое изменение структуры заказов.
  5. Нагрузка на один сервер — становится бутылочным горлышком.

Задача:

  1. Обосновать выбор подходящего типа NoSQL СУБД для задачи.
  2. Предложить новую модель данных, учитывающую специфику выбранной NoSQL базы.
  3. Описать процесс миграции с минимальным downtime.
  4. Указать возможные подводные камни при переходе и способы их минимизации.

Решение:

1. Выбор NoSQL СУБД:

На основе требований к модели данных и характеру нагрузки, наиболее подходящей является документная БД , например MongoDB :

  • Поддерживает гибкую схему данных.
  • Позволяет денормализовать данные и хранить связанные сущности в одном документе.
  • Хорошо масштабируется горизонтально.
  • Подходит для read-heavy и write-heavy сценариев.

2. Новая модель данных в MongoDB:

{
  "_id": "order_123",
  "user": {
    "id": "user_456",
    "name": "Иван Иванов",
    "phone": "+79991234567"
  },
  "restaurant": {
    "id": "rest_789",
    "name": "Sushi Bar",
    "address": "ул. Ленина, д. 10"
  },
  "total_price": 780.00,
  "status": "in_progress",
  "created_at": "2025-04-05T14:23:00Z",
  "delivery": {
    "courier_id": "courier_321",
    "delivery_time": "2025-04-05T15:00:00Z"
  }
}

Преимущества:

  • Все необходимые данные находятся в одном документе → нет JOIN'ов.
  • Запросы выполняются быстрее.
  • Гибкость: можно добавлять новые поля (например, discount, payment_method) без изменения схемы.

3. Процесс миграции:

Этапы:

  1. Подготовка:

    • Создание нового микросервиса OrdersNoSQL, работающего параллельно с текущим.
    • Настройка двойной записи: все новые заказы пишутся в обе БД.
  2. Перенос исторических данных:

    • Использовать ETL-процесс (Apache NiFi, custom скрипты) для преобразования и переноса старых заказов в MongoDB.
    • Добавить флаг migrated: true.
  3. Тестирование:

    • Тестирование новых API и проверка согласованности данных.
    • Сравнение времени выполнения запросов.
  4. Переключение трафика:

    • Перевести клиентов на новый микросервис через API Gateway.
    • Отключить PostgreSQL после завершения всех проверок.

4. Возможные подводные камни и решения:

Проблема
Решение
Потеря ACID-гарантий
Использовать multi-document transactions (в MongoDB 4.0+), Saga Pattern для распределённых операций
Рост размера документов
Ограниченный вложенный объект, использование ссылок или отдельных коллекций для больших данных
Сложность поиска по вложенным полям
Создание индексов, использование$lookupпри необходимости
Необходимость обновления старых документов
Versioning документов + background migration

Итог:

После миграции:

  • Скорость обработки запросов увеличилась на 40–60%.
  • Система стала готова к горизонтальному масштабированию.
  • Команда получила гибкость в управлении данными.
  • Снизились накладные расходы на обслуживание JOIN'ов и блокировок.

Ролевая игра №1: "Проектирование масштабируемой системы хранения данных для онлайн-игры"


Цель игры:

Научить участников проектировать, обосновывать выбор и настраивать NoSQL-решения в условиях высоких нагрузок и сложных бизнес-требований. Развить навыки командной работы, анализа требований и принятия технических решений под реальные сценарии.


Формат:

  • Групповая ролевая игра (4–6 человек в команде)
  • Продолжительность: 2–3 академических часа
  • Форма проведения: очная или онлайн с использованием досок (Miro, Jamboard), чата и презентаций
  • Итог: устная защита решения + техническая документация / диаграммы модели данных

Сеттинг:

Вы — команда разработчиков и архитекторов, работающих в стартапе, который создаёт новую многопользовательскую онлайн-игру. Ваша задача — спроектировать систему хранения пользовательских данных, игровых сессий, инвентаря, достижений и рейтинга игроков.

Компания ожидает:

  • Поддержку до 100 000 активных пользователей одновременно,
  • Обработку 5000 операций записи и 20 000 операций чтения в секунду,
  • Высокую доступность (99.9% uptime),
  • Быстрое восстановление после сбоев,
  • Гибкость при добавлении новых игровых механик.

Роли в команде:

Роль
Ответственность
Технический лидер
Организует работу, следит за сроками, координирует обсуждение решений
Архитектор баз данных
Отвечает за выбор СУБД, проектирование модели данных, шардинга, репликации
DevOps-инженер
Предлагает решения по развертыванию кластера, мониторингу, бэкапам, автоматизации
Специалист по безопасности
Обеспечивает безопасность данных, контроль доступа, шифрование
Инженер по производительности
Анализирует нагрузку, задержки, предлагает оптимизации
Представитель продукта
Передаёт требования от бизнеса, выступает на финальной защите

Этапы игры:

1. Введение (15 мин)

  • Проведение брифинга: описание ситуации, целей, ограничений.
  • Распределение ролей в командах.

2. Анализ требований (20 мин)

  • Изучение бизнес-задач:
    • Хранение профиля игрока
    • Инвентарь предметов
    • Логи действий
    • Онлайн-рейтинги
    • Социальные функции (чат, друзья)
  • Выявление ключевых метрик: read/write throughput, latency SLA, availability.

3. Выбор NoSQL СУБД (30 мин)

  • Команда анализирует варианты:
    • MongoDB (document)
    • Cassandra (columnar, write-heavy)
    • Redis (cache, session storage)
    • Neo4j (социальные графы)
  • Обоснование выбора одной или нескольких систем.

4. Проектирование модели данных (40 мин)

  • Разработка схемы данных под выбранную СУБД.
  • Учет денормализации, партиционирования, индексирования.
  • Примеры запросов: получение профиля, обновление рейтинга, поиск друзей.

5. Архитектурные решения (30 мин)

  • Шардинг, репликация, disaster recovery.
  • Мониторинг и логирование.
  • Безопасность: RBAC, шифрование, аудит.

6. Защита решения (30 мин)

  • Каждая команда представляет свой подход:
    • Какие СУБД были выбраны и почему?
    • Как организовано хранение данных?
    • Как обеспечивается отказоустойчивость и производительность?
    • Какие компромиссы были приняты?

Обучающие эффекты:

  • Понимание различий между типами NoSQL СУБД и их применимости в реальных задачах.
  • Навыки проектирования моделей данных под конкретные сценарии использования.
  • Умение принимать архитектурные решения в условиях ограниченных ресурсов и времени.
  • Развитие soft skills: коммуникация, распределение ролей, управление временем.

Ролевая игра №2: "Восстановление после катастрофы в распределённой NoSQL системе"


Цель игры:

Научить участников диагностировать и устранять критические инциденты в распределённых NoSQL системах, развить навыки работы под давлением, анализа логов, принятия решений в условиях неопределённости и командного взаимодействия.


Формат:

  • Групповая ролевая игра (5–7 человек в команде)
  • Продолжительность: 2 академических часа
  • Форма проведения: симуляция реального инцидента (инцидент-рум)
  • Результат: отчет об инциденте + рекомендации по предотвращению

Сеттинг:

Вы — часть SRE/DevOps команды компании, которая управляет масштабируемой платформой для онлайн-голосования. Основное хранилище данных — Apache Cassandra , размещённое на трёх дата-центрах в разных регионах.

Утром команда получает сигналы мониторинга:

  • Значительный рост latency при чтении.
  • Множественные ошибки timeout.
  • Некоторые узлы недоступны.
  • Восстановление из backup занимает слишком много времени.

Вам необходимо:

  • Диагностировать проблему,
  • Принять экстренные меры для восстановления доступности,
  • Предложить долгосрочные решения для предотвращения подобных ситуаций.

Роли в команде:

Роль
Ответственность
Технический лидер / Incident Commander
Координирует действия, принимает ключевые решения, общается с внешними участниками
База данных / Специалист по Cassandra
Анализирует состояние кластера, топологию, данные о нагрузке и консистентности
Инженер по мониторингу
Интерпретирует метрики (latency, throughput, GC pauses, replication lag)
DevOps / Инженер по инфраструктуре
Проверяет сетевое взаимодействие, доступность узлов, состояние дисков и процессов
Специалист по бэкапам и DR (Disaster Recovery)
Проверяет актуальность и целостность бэкапов, оценивает возможность восстановления
Аналитик безопасности
Исключает версию атаки или несанкционированного доступа
Коммуникатор / PR-менеджер
Готовит внутренние и внешние сообщения об инциденте

Этапы игры:

1. Брифинг и запуск инцидента (10 мин)

  • Команде предоставляется описание ситуации и начальные метрики.
  • Демонстрация dashboard'ов (Prometheus/Grafana), логов, оповещений.

2. Анализ проблемы (30 мин)

  • Изучение логов, метрик, состояния кластера.
  • Выявление возможных причин:
    • Сетевой разрыв между DC,
    • Hot partitions,
    • Ошибки компакции или переполнение диска,
    • Сбой репликации,
    • Потеря кворума.

3. Экстренные действия (30 мин)

  • Принятие решений:
    • Перезапуск узлов?
    • Ручной failover?
    • Восстановление из backup?
    • Изменение Consistency Level?
  • Реализация временных мер для стабилизации системы.

4. Долгосрочные решения (20 мин)

  • Разработка рекомендаций:
    • Настройка автоматического мониторинга и alerting’а,
    • Улучшение стратегии бэкапов,
    • Перераспределение данных,
    • Обновление политик отказоустойчивости.

5. Защита и анализ (30 мин)

  • Каждая команда представляет:
    • Что произошло?
    • Как были приняты меры?
    • Какие выводы сделаны?
  • Тренер проводит debriefing: что было сделано хорошо, где были ошибки, как можно улучшить процессы.

Обучающие эффекты:

  • Навыки диагностики и устранения инцидентов в распределённых системах.
  • Понимание принципов отказоустойчивости, репликации, шардинга и согласованности.
  • Опыт работы в условиях дефицита информации и времени.
  • Умение работать в составе cross-functional команды.
  • Развитие soft skills: коммуникация, делегирование, стрессоустойчивость.

Ролевая игра №3: "Выбор NoSQL решения для стартапа в сфере интернета вещей (IoT)"


Цель игры:

Научить участников анализировать бизнес-требования, оценивать технические ограничения и выбирать наиболее подходящее NoSQL решение для масштабируемой IoT-платформы. Развить навыки сравнительного анализа СУБД, принятия обоснованных решений и аргументации выбора.


Формат:

  • Групповая ролевая игра (4–6 человек в команде)
  • Продолжительность: 2 академических часа
  • Форма проведения: симуляция тендера / внутреннего технического комитета по выбору технологии
  • Результат: презентация + техническая рекомендация с обоснованием выбора

Сеттинг:

Вы — часть технической команды стартапа, который разрабатывает платформу для управления умными устройствами (IoT). Платформа должна поддерживать:

  • Приём данных от миллионов датчиков (температура, уровень влажности, геолокация и т.д.)
  • Хранение временных рядов
  • Быстрое чтение по временным интервалам и устройству
  • Возможность хранения неструктурированных метаданных
  • Обработку данных в реальном времени
  • Высокую доступность и отказоустойчивость

Вам предстоит выбрать одну из нескольких NoSQL систем, проанализировать их соответствие требованиям проекта и представить обоснованное решение на совещании с техническим директором.


Роли в команде:

Роль
Ответственность
Технический лидер / Архитектор
Организует работу, принимает ключевые решения, координирует обсуждение
Специалист по данным / Data Engineer
Анализирует типы данных, нагрузку, частоту записи/чтения
DevOps-инженер
Оценивает сложность эксплуатации, мониторинг, автоматизацию
Инженер по производительности
Сравнивает системы по latency, throughput, scalability
Аналитик безопасности
Учитывает риски безопасности, контроля доступа, шифрования
Представитель бизнеса / Product Owner
Представляет интересы заказчика, задаёт вопросы о стоимости, времени внедрения

Этапы игры:

1. Введение и брифинг (15 мин)

  • Команде предоставляется описание проекта, целевой аудитории и основных требований.
  • Перечислены возможные кандидаты на роль хранилища:
    • InfluxDB (time-series)
    • MongoDB (document)
    • Cassandra (columnar, write-heavy)
    • Redis (in-memory, stream data type)
    • Amazon DynamoDB (managed, key-value/document)

2. Исследование требований (30 мин)

  • Команда выделяет ключевые показатели:
    • Типы данных: временные ряды, метаданные устройства, события.
    • Нагрузка: ~1 млн записей в секунду, 100 тыс. запросов чтения в секунду.
    • SLA: 99.9% доступности, минимальная латентность при чтении.
    • Масштабируемость: горизонтальная, возможность интеграции с cloud провайдерами.
    • Безопасность: шифрование, RBAC, аудит.
    • Долгосрочные цели: machine learning, аналитика, интеграция с Kafka.

3. Сравнение СУБД (40 мин)

  • Каждый участник или пара участников "принимает сторону" одной СУБД.
  • Изучают её особенности:
    • Поддержка временных рядов
    • Горизонтальное масштабирование
    • Инструменты мониторинга и восстановления
    • Производительность при высоких нагрузках
    • Экосистема и интеграции
  • Готовят аргументы за/против каждой системы.

4. Обсуждение и принятие решения (30 мин)

  • Команда проводит обсуждение:
    • Какие компромиссы приходится делать?
    • Какие СУБД не соответствуют требованиям?
    • Какая система лучше всего подходит под текущие и будущие задачи?
  • Формируется финальное решение.

5. Защита решения (30 мин)

  • Команда представляет результаты:
    • Почему была выбрана конкретная СУБД?
    • Какие были компромиссы?
    • Как будет происходить внедрение?
    • Какие есть планы развития?

Обучающие эффекты:

  • Умение оценивать NoSQL СУБД через призму реальных задач.
  • Навыки сравнительного анализа технологий и обоснования выбора.
  • Знакомство с особенностями популярных NoSQL решений.
  • Опыт работы в условиях ограниченной информации и необходимости принятия стратегических решений.
  • Развитие soft skills: аргументация, работа в команде, публичная защита решения.

Ролевая игра №4: "Оптимизация производительности NoSQL кластера в условиях роста нагрузки"


Цель игры:

Научить участников анализировать метрики производительности, выявлять узкие места и применять практические методы оптимизации NoSQL-кластеров. Развить навыки диагностики, тюнинга системы и принятия решений под давлением роста нагрузки.


Формат:

  • Групповая ролевая игра (5–7 человек в команде)
  • Продолжительность: 2 академических часа
  • Форма проведения: симуляция реального сценария роста нагрузки на систему
  • Результат: отчет об анализе производительности + рекомендации по оптимизации

Сеттинг:

Вы — часть инженерной команды SaaS-платформы, которая предоставляет сервис аналитики для мобильных приложений. Основное хранилище данных — MongoDB , работающая в режиме шардинга с несколькими репликами.

Платформа испытывает стабильный рост пользователей:

  • Количество записываемых событий увеличилось в 3 раза за последние 2 месяца.
  • Пользователи начали жаловаться на замедление работы интерфейса.
  • Мониторинг показывает рост latency, ошибки timeout, перегрузку отдельных шардов.

Вам нужно:

  • Проанализировать текущее состояние кластера,
  • Выявить узкие места,
  • Предложить и реализовать меры по оптимизации производительности.

Роли в команде:

Роль
Ответственность
Технический лидер / MongoDB DBA
Координирует работу, принимает ключевые решения, следит за сроками
Инженер по производительности
Анализирует медленные запросы, используетexplain(), профилирование
DevOps / Инженер по кластеру
Изучает параметры шардинга, репликации, балансировки
Мониторинг-специалист
Читает метрики из Prometheus/Grafana, Cloud Manager или Atlas Monitoring
Аналитик индексов
Исследует текущие индексы, предлагает новые, устраняет missing index
Инженер по данным
Оценивает объём данных, партиционирование, TTL и lifecycle policy
Коммуникатор / Product Ops
Передаёт выводы технической команды бизнесу, готовит чек-лист действий

Этапы игры:

1. Брифинг и постановка задачи (10 мин)

  • Представление проблемы: рост нагрузки, падение SLA, жалобы пользователей.
  • Демонстрация метрик (latency, throughput, CPU, RAM, disk I/O).
  • Команды получают доступ к документам: конфигурация кластера, список коллекций, примеры медленных запросов.

2. Диагностика состояния системы (30 мин)

  • Изучение логов, метрик, explain-планов.
  • Анализ:
    • Наличие full scans вместо indexed queries
    • Hot partitions
    • Неэффективные индексы
    • Состояние реплик и балансировки шардов
    • Уровень фрагментации и компактируемых документов

3. Поиск узких мест (20 мин)

  • Выявление основных проблем:
    • Отсутствие индексов на часто используемых полях
    • Запросы без ограничений (limit/offset)
    • Неправильно настроенная балансировка
    • Большое количество одновременных write-операций
    • Неоптимальное использование connection pool

4. Разработка мер оптимизации (30 мин)

  • Предложение решений:
    • Создание новых индексов (single, compound, partial, TTL)
    • Настройка query hints
    • Перераспределение шардов
    • Использование materialized views или агрегационных коллекций
    • Введение caching layer (Redis)
    • Адаптация TTL-policy для старых данных

5. Защита и презентация решений (30 мин)

  • Команда представляет:
    • Какие проблемы были найдены?
    • Какие меры предлагаются?
    • Какой ожидается эффект от изменений?
    • Как будет внедряться решение (пошагово)?
  • Тренер проводит debriefing: какие решения эффективны, где возможны побочные эффекты, как можно улучшить подход.

Обучающие эффекты:

  • Навыки диагностики и анализа производительности NoSQL кластеров.
  • Умение читать метрики и использовать инструменты мониторинга.
  • Опыт работы с explain-планами и оптимизацией запросов.
  • Понимание влияния модели данных и индексирования на производительность.
  • Развитие soft skills: коммуникация, делегирование, групповое принятие решений.

Интеллект-карта №1: "Общая экосистема NoSQL технологий"

Центральный узел:
NoSQL — Базы данных нового поколения

1. Типы NoSQL СУБД

  • Документные (MongoDB, Couchbase)
  • Графовые (Neo4j, Amazon Neptune)
  • Колоночные (Cassandra, HBase)
  • Ключ-значение (Redis, DynamoDB)

2. Основные концепции

  • CAP-теорема
  • BASE семантика
  • Репликация и шардинг
  • Eventual consistency
  • MVCC / Vector Clocks

3. Архитектурные особенности

  • Хранение данных
  • Модели данных
  • Транзакции в NoSQL
  • Индексирование и поиск
  • Безопасность и контроль доступа

4. Применение по сценариям

  • Аналитика больших данных
  • Игровые платформы
  • IoT и временные ряды
  • Социальные графы
  • Электронная коммерция

5. Экосистема и инструменты

  • Мониторинг (Prometheus, Grafana)
  • ETL, Kafka, Spark
  • Backup & Recovery
  • API и интеграции
  • DevOps и CI/CD практики

Интеллект-карта №2: "Навыки и компетенции разработчика NoSQL"

Центральный узел:
Компетенции разработчика NoSQL

1. Проектирование модели данных

  • Выбор типа СУБД под задачу
  • Денормализация vs нормализация
  • Партиционирование и ключи
  • Версионность и миграции

2. Работа с конкретными системами

  • MongoDB: Aggregation, Indexing, TTL
  • Cassandra: Composite keys, Compaction
  • Neo4j: Graph Patterns, Traversal
  • Redis: Data Types, Lua Scripts
  • DynamoDB: Partitions, Throughput

3. Оптимизация производительности

  • Explain(), профилирование запросов
  • Индексирование (single, compound, partial)
  • Query tuning и пагинация
  • Устранение hot partitions
  • Настройка write concern / read preference

4. Масштабируемость и отказоустойчивость

  • Шардинг
  • Репликация
  • Disaster recovery
  • Consensus алгоритмы (Raft, Paxos)
  • High availability и балансировка нагрузки

5. Безопасность и управление

  • RBAC и ACL
  • Шифрование (TLS, TDE, Field-level)
  • Аудит действий
  • Управление секретами (Vault, KMS)
  • Least privilege подход

6. Автоматизация и DevOps

  • Мониторинг (CloudWatch, Prometheus)
  • Backup & Restore стратегии
  • CI/CD для миграций и релизов
  • Chaos Engineering и тестирование отказов
  • Docker, Kubernetes, Helm чарты

Интеллект-карта №3: "Путь от новичка к профессионалу"

Центральный узел:
Карьера: Разработчик NoSQL баз данных

1. Фундамент

  • Основы СУБД
  • JSON, BSON, Avro, Protobuf
  • Введение в Big Data
  • Модели данных
  • CAP/BASE/ACID теории

2. Начальный уровень

  • Работа с документной БД (MongoDB)
  • Создание индексов, простые запросы
  • Вставка, обновление, удаление
  • Написание скриптов (Python, Node.js)
  • Понимание шардинга и репликации

3. Средний уровень

  • Производительность: explain(), slow query log
  • Комплексное проектирование схем
  • Агрегация, MapReduce
  • Подключение к микросервисам
  • Backup и восстановление

4. Профессиональный уровень

  • Архитектура кластеров
  • Горизонтальное масштабирование
  • Распределённые транзакции
  • Chaos engineering
  • Интеграция с аналитическими системами

5. Экспертный уровень

  • Custom storage engines
  • Алгоритмы согласованности
  • Сравнение NoSQL решений
  • Лидерство в проектах
  • Консультирование бизнеса

6. Карьерные возможности

  • Разработчик NoSQL
  • Data Engineer
  • Technical Architect
  • SRE / DevOps Engineer
  • Преподаватель / Технический автор

1. Научная литература

Название: Designing Data-Intensive Applications
Авторы: Martin Kleppmann
Год издания: 2017
Издательство: O'Reilly Media
Краткое описание:
Фундаментальный труд по архитектуре систем хранения данных, включая реляционные и NoSQL СУБД. Освещает принципы работы распределённых систем, согласованности, репликации, шардинга, сериализации данных и транзакций.
Ценность для курса: Базовый источник знаний о внутреннем устройстве NoSQL-систем.


2. Хрестоматия / Учебное пособие

Название: NoSQL for Mere Mortals
Автор: Dan Sullivan
Год издания: 2015
Издательство: Addison-Wesley
Краткое описание:
Практическое руководство по выбору и применению NoSQL решений. Включает обзор типов баз данных, моделирование данных, примеры использования в реальных сценариях.
Ценность для курса: Подходит как учебное пособие для освоения концепций и практики применения различных NoSQL СУБД.


3. Учебник

Название: Database Internals
Автор: Alex Petrov
Год издания: 2019
Издательство: O'Reilly Media
Краткое описание:
Углублённое погружение в устройство современных систем управления базами данных. Рассмотрены методы хранения, индексирования, сериализации, механизмы транзакций и репликации.
Ценность для курса: Для профессионального уровня — понимание "под капотом" NoSQL-движков и их отличий от классических решений.


4. Методические рекомендации

Название: Apache Cassandra: The Definitive Guide
Авторы: Jeff Carpenter, Eben Hewitt
Год издания: 2020
Издательство: O'Reilly Media
Краткое описание:
Подробное практическое руководство по проектированию, настройке и эксплуатации кластеров Apache Cassandra. Включает примеры моделей данных, оптимизацию производительности и управление отказоустойчивостью.
Ценность для курса: Отличный материал для лабораторных работ и проектной деятельности по колоночным NoSQL системам.


5. Задачник / дидактическое пособие

Название: MongoDB: The Definitive Guide
Авторы: Kristina Chodorow
Год издания: 2022
Издательство: O'Reilly Media
Краткое описание:
Практическое пособие по работе с MongoDB. Включает упражнения по созданию коллекций, написанию запросов, индексированию, шардингу и агрегациям.
Ценность для курса: Может использоваться как задачник для студентов при изучении документно-ориентированных СУБД.

 
  1. NoSQL: Профессиональное проектирование и эксплуатация Курс по углубленному изучению архитектуры, моделированию данных и администрированию NoSQL решений в высоконагруженных системах.

  2. Разработка масштабируемых NoSQL решений Научитесь создавать отказоустойчивые и производительные системы хранения данных на основе NoSQL технологий.

  3. NoSQL для распределённых систем Изучение особенностей применения NoSQL в микросервисных и cloud-native архитектурах.

  4. Профессиональная работа с MongoDB Глубокое погружение в проектирование, оптимизацию и администрирование документных БД на примере MongoDB.

  5. Графовые базы данных: от теории к практике Курс по Neo4j и другим графовым СУБД, включая моделирование связей и обработку социальных графов.

  6. Cassandra: Масштабирование и отказоустойчивость Подробное изучение Apache Cassandra — от модели данных до управления кластером в production.

  7. Redis: Высокопроизводительные решения Применение Redis в качестве кэша, message broker и in-memory хранилища с акцентом на производительность и отказоустойчивость.

  8. NoSQL и Big Data: интеграция с Hadoop и Spark Освоение работы с NoSQL в экосистеме больших данных, включая ETL-процессы и аналитику.

  9. Использование DynamoDB в облачных архитектурах Практический курс по применению Amazon DynamoDB в облачных решениях с акцентом на шардинг и автоматизацию.

  10. Технологии временных рядов и NoSQL Изучение применения Time Series DB (InfluxDB, Cassandra) и их интеграции в IoT и мониторинговые системы.

  11. NoSQL и искусственный интеллект Интеграция NoSQL решений в ML-системы, хранение неструктурированных данных и организация data lakes.

  12. Администрирование NoSQL кластеров Углублённый курс по управлению кластерами, репликации, балансировке нагрузки и мониторингу производительности.

  13. Оптимизация производительности NoSQL Практические методики улучшения скорости чтения/записи, снижения latency и повышения throughput.

  14. Сравнительный анализ NoSQL решений Сравнение типов NoSQL СУБД и выбор наиболее подходящего решения под конкретную предметную область.

  15. Интеграция NoSQL в DevOps процессы Автоматизация деплоя, миграции схем, бэкапов и восстановления данных в CI/CD pipeline.

  16. Безопасность в NoSQL системах Обеспечение конфиденциальности, контроля доступа, шифрования и аудита в NoSQL средах.

  17. NoSQL и микросервисная архитектура Использование NoSQL в составе микросервисов: изоляция данных, согласованность, транзакции и интеграция.

  18. Построение аналитических систем на NoSQL Создание систем бизнес-аналитики с использованием NoSQL, Elasticsearch и других инструментов.

  19. Chaos Engineering и тестирование отказов в NoSQL Методы тестирования отказоустойчивости, fault tolerance и disaster recovery в распределённых NoSQL системах.

  20. Разработка API поверх NoSQL Построение RESTful и GraphQL API над NoSQL хранилищами, включая кэширование и обработку ошибок.

  21. Моделирование данных в NoSQL Техники проектирования моделей данных для различных типов NoSQL СУБД с учётом требований бизнес-логики.

  22. NoSQL в реальном времени Разработка систем обработки событий в реальном времени с использованием stream processing и NoSQL.

  23. Работа с геопространственными данными в NoSQL Хранение и обработка геолокационной информации в NoSQL, включая индексирование и пространственные запросы.

  24. NoSQL для интернета вещей (IoT) Использование NoSQL в системах сбора, хранения и обработки данных с датчиков и устройств IoT.

  25. Экспертный уровень: внутреннее устройство NoSQL Курс о том, как работают движки NoSQL внутри: storage engines, сериализация, MVCC, vector clocks и consensus алгоритмы.

Заявка ученика, студента, слушателя
Заявка преподавателя, репетитора админу сети.
18:19
26
Посещая этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.