Разработчик баз данных 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 хранилищ.
-
Что такое NoSQL и в каких случаях её предпочтительнее использовать, чем реляционные СУБД?
NoSQL — это класс систем управления базами данных, не основанных на реляционной модели. Используется при необходимости масштабируемости, гибкой схемы данных, высокой производительности чтения/записи и обработки больших объёмов неструктурированных данных. -
Какие типы NoSQL-баз существуют и какие задачи они решают?
Документные (MongoDB) — для гибких иерархических структур; графовые (Neo4j) — для анализа связей; колоночные (Cassandra) — для высокопроизводительного хранения больших наборов данных; ключ-значение (Redis) — для кэширования и быстрого доступа. -
Что означает CAP-теорема и как она влияет на выбор NoSQL-системы?
CAP-теорема утверждает, что распределённая система может одновременно обеспечивать согласованность, доступность и устойчивость к разделению сети только два из трёх. Это определяет компромиссы при проектировании систем. -
Что такое шардинг и как он реализуется в NoSQL?
Шардинг — это горизонтальное разделение данных между несколькими узлами. В NoSQL используется для масштабирования чтения/записи и балансировки нагрузки, например, в MongoDB через sharded clusters. -
Как работают механизмы репликации в NoSQL и зачем они нужны?
Репликация создаёт копии данных на нескольких узлах для обеспечения отказоустойчивости, повышения доступности и балансировки нагрузки на чтение. -
В чём отличие BASE от ACID?
BASE (Basically Available, Soft state, Eventually consistent) — подход, характерный для NoSQL, допускающий временную несогласованность ради доступности и масштабируемости, в отличие от строгих ACID-гарантий транзакций. -
Что такое логическая временная метка (vector clock) и где применяется?
Vector clock — механизм отслеживания причинно-следственных связей между изменениями в распределённых системах, используется в Riak и других eventual consistency системах. -
Как работает MVCC в контексте NoSQL?
MVCC (Multi-Version Concurrency Control) позволяет разным транзакциям видеть разные версии данных, что повышает параллелизм и снижает блокировки, применяется в некоторых документных и колоночных БД. -
Что такое TTL-индексы и когда их стоит использовать?
TTL-индексы автоматически удаляют данные по истечении заданного времени, полезны для временных записей, логов или кэша. -
Какие методы индексирования поддерживаются в MongoDB?
Поддерживаются одно- и многопольные, составные, текстовые, геопространственные, TTL, уникальные и частичные индексы. -
Как устроена модель данных в графовых БД?
Модель состоит из вершин (узлов), рёбер (связей) и свойств. Оптимальна для работы с сильносвязанными данными, таких как социальные графы или рекомендательные системы. -
Что такое миграция данных в NoSQL и как она организуется?
Миграция — изменение структуры данных в динамической схеме. Организуется через скрипты, versioning документов или live migration с постепенным обновлением. -
Как обеспечивается безопасность в NoSQL-системах?
Через аутентификацию, авторизацию на уровне ролей, шифрование данных, SSL/TLS, аудит действий пользователей и ограничение сетевого доступа. -
Как происходит сериализация данных в NoSQL и какие форматы используются?
Используются JSON, BSON, Avro, Protobuf, MessagePack — для компактности, скорости передачи и эффективного хранения данных. -
Что такое eventual consistency и в каких системах она применяется?
Eventual consistency — гарантия, что все копии данных со временем станут одинаковыми. Применяется в системах с высокой доступностью, например, Cassandra, DynamoDB. -
Как настраивается кворумное чтение и запись в распределённых NoSQL-системах?
Кворумное чтение/запись требует подтверждения операции от большинства узлов, чтобы повысить согласованность, часто используется в Apache Cassandra. -
Какие механизмы партиционирования данных используются в NoSQL?
Range-based, hash-based и list-based партиционирование. Выбор зависит от равномерности распределения нагрузки и особенностей запросов. -
Как работает MapReduce в контексте NoSQL?
MapReduce — парадигма обработки больших объёмов данных, позволяющая выполнять агрегации и анализ в распределённой среде, например, в MongoDB. -
Какие инструменты мониторинга и диагностики применяются в NoSQL?
Prometheus + Grafana, CloudWatch, Datadog, OpsCenter, MongoDB Atlas Monitoring, ELK Stack для логов. -
Как реализуется поддержка транзакций в NoSQL?
Некоторые NoSQL системы (MongoDB, Couchbase) поддерживают многооперационные транзакции внутри одного документа или шарда, другие — через внешние средства (например, Kafka Streams). -
Как осуществляется резервное копирование и восстановление в NoSQL?
Через snapshot'ы, export/import (mongodump/mongoexport), continuous backups, point-in-time recovery и интеграции с облачными сервисами. -
Как интегрируются NoSQL-базы в микросервисные архитектуры?
Через API, message queues (Kafka, RabbitMQ), CQRS, event sourcing, а также использование sidecar-компонентов и service mesh. -
Какие проблемы могут возникнуть при масштабировании NoSQL-систем?
Hot partitions, network partitioning, потеря согласованности, сложности с миграцией, увеличение latency, управление состоянием. -
Как оптимизировать производительность запросов в NoSQL?
Через правильное создание индексов, денормализацию данных, фильтрацию на сервере, пагинацию, профилирование медленных запросов и использование explain(). -
Какие практики используются для тестирования и отладки NoSQL-решений?
Unit- и интеграционное тестирование, load testing (JMeter, Locust), profiling, logging, использование mock-серверов, A/B testing с реальными нагрузками.
-
Какие факторы влияют на выбор типа NoSQL-базы для конкретного проекта?
Выбор зависит от модели данных (документы, графы, ключ-значение), требований к согласованности, масштабируемости, производительности, поддержки транзакций и сложности интеграции в архитектуру. -
Что такое денормализация данных и почему она часто используется в NoSQL?
Денормализация — это объединение связанных данных в одну запись для ускорения чтения. Применяется в NoSQL для снижения количества операций join и повышения производительности. -
Как реализуется пагинация в MongoDB и какие подходы существуют?
Пагинация реализуется через методы skip() и limit(), но при больших смещениях это неэффективно. Альтернативы: курсоры, ключевая пагинация (where + sort) и index-based offset. -
В чём разница между логической и физической репликацией в NoSQL?
Логическая репликация передаёт изменения на уровне запросов или событий, физическая — копирует блоки данных или файлы базы. Логическая гибче, физическая — быстрее. -
Как организовать балансировку нагрузки при работе с NoSQL-кластерами?
Использовать клиентские драйверы с поддержкой load balancing, прокси-серверы (HAProxy, NGINX), шардинг, автоматическое распределение запросов по репликам и политики read preference. -
Что такое eventual consistency и как её можно детектировать?
Eventual consistency — состояние, когда все узлы со временем синхронизируются. Детектировать можно через версии данных, vector clocks или сравнение хэшей содержимого на разных нодах. -
Как обеспечить атомарность операций в документной БД?
MongoDB поддерживает атомарные операции на уровне одного документа. Для нескольких документов используются двухфазные коммиты или внешние системы координации (например, ZooKeeper). -
Какие особенности проектирования схем характерны для Cassandra?
Проектирование ведётся «под запросы», так как Cassandra оптимизирована под write-heavy нагрузки. Важна правильная организация primary key, clustering columns и materialized views. -
Как работает механизм hinted handoff в распределённых NoSQL системах?
Hinted handoff — временная запись на другом узле в случае недоступности целевого, чтобы восстановить данные после возврата узла в строй, применяется в Cassandra. -
Какие инструменты используются для миграции из реляционной БД в NoSQL?
ETL-инструменты (Apache NiFi, Talend), custom скрипты, Kafka Connect, MongoDB Connector for BI, Sqoop + JSON export, cloud migration tools (AWS DMS, Google Dataflow). -
Как реализуется full-text search в NoSQL?
MongoDB поддерживает текстовые индексы; Elasticsearch может использоваться как внешнее решение; Couchbase имеет встроенный FTS-движок. -
Какие проблемы могут возникнуть при горизонтальном масштабировании NoSQL-систем?
Hot partitions, network congestion, clock drift, split brain, потеря данных при переключении лидеров, конфликты версий, увеличение overhead управления кластером. -
Как работают secondary indexes в Cassandra и в чём их ограничения?
Secondary indexes позволяют выполнять запросы по произвольным полям, но имеют ограничения: не поддерживают range queries, медленнее, чем основные ключи, и неэффективны при высокой кардинальности. -
Какие стратегии используются для обеспечения отказоустойчивости в NoSQL?
Репликация, кворумное чтение/запись, heartbeat-мониторинг, автоматический failover, cross-region deployment, backup & restore, использование consensus алгоритмов (Raft, Paxos). -
Как реализовать ACID-транзакции в NoSQL-системе?
Некоторые системы (MongoDB, Couchbase) поддерживают транзакции на уровне одного документа или шарда. Для распределённых транзакций используются Saga Pattern, event sourcing или внешние системы. -
Что такое eventual consistency conflict resolution и как он осуществляется?
Механизмы разрешения конфликтов: last-write-wins, vector clocks, CRDTs, application-level merge, timestamp-based resolution. Используются в системах с eventual consistency. -
Как использовать Apache Spark с NoSQL-базами?
Spark через соответствующие коннекторы (например, spark-cassandra-connector) позволяет выполнять ETL, аналитику и обработку big data, интегрируя NoSQL в pipeline. -
Какие типы шардинга поддерживаются в MongoDB?
Range-based, hash-based и zone-based шардинг. Hash-based равномерно распределяет данные, range-based эффективен для диапазонных запросов, zone-based — для территориального разделения. -
Как организовать безопасный удалённый доступ к NoSQL-базе?
Использовать SSH-туннели, SSL/TLS, RBAC, VPC, firewall rules, proxy-авторизация, API gateways, аудит всех подключений и применение least privilege принципа. -
Как работают TTL-коллекции в Redis и как они управляются?
Redis поддерживает установку времени жизни ключа через команды EXPIRE, PEXPIRE. Ключи удаляются автоматически по истечении TTL, что полезно для кэширования. -
Какие метрики необходимо отслеживать при эксплуатации NoSQL-баз?
CPU, RAM, disk I/O, latency, throughput, replication lag, cache hit ratio, error rate, connection count, GC pauses, compaction stats, query performance. -
Как реализовать backup и point-in-time recovery в MongoDB?
Через mongodump/mongorestore, fs-snapshot, oplog tailing, MongoDB Cloud Manager или Atlas Backup, обеспечивающие incremental backups и точечное восстановление. -
Какие проблемы могут возникнуть при использовании long-running connections в NoSQL-клиентах?
Network timeouts, memory leaks, stale connections, zombie processes, resource exhaustion. Решаются через keep-alive, reconnection policies, connection pooling и health checks. -
Какие особенности использования NoSQL в serverless-архитектурах?
Ограничения на время выполнения, размер ответа, частоту вызовов, необходимость stateless работы. Требуется оптимизация запросов, использование managed DB-as-a-service и connection pooling. -
Какие подходы используются для тестирования отказоустойчивости NoSQL-кластера?
Chaos engineering (например, Chaos Monkey), принудительное отключение узлов, имитация сетевых разрывов, проверка восстановления из backup, stress testing и fault injection.
-
Какие особенности проектирования схем характерны для графовых баз данных?
Схемы строятся вокруг узлов, связей и свойств. Основное внимание — на оптимизацию обхода графа, индексирование вершин и рёбер, а также эффективную реализацию сложных отношений. -
Что такое materialized view в NoSQL и как она применяется?
Materialized view — это предрассчитанное представление данных, хранящееся физически. Используется для ускорения сложных запросов, особенно в Cassandra и Couchbase. -
Как работает механизм compaction в Cassandra и зачем он нужен?
Compaction объединяет SSTable-файлы и удаляет устаревшие данные (например, по TTL или удалённые через tombstone). Позволяет оптимизировать место и производительность чтения. -
Как организовать транзакции между несколькими документами в MongoDB?
В MongoDB 4.0+ поддерживаются многошардовые транзакции с применением двухфазного коммита внутри кластера. Требуется WiredTiger Storage Engine и режим write concern majority. -
Какие проблемы возникают при использовании auto-increment ID в NoSQL?
Centralized bottleneck, hot shard, низкая производительность при высокой нагрузке. Решение: UUID, ObjectId, Snowflake-like ID, hash-based distribution. -
Что такое time-series data и какие NoSQL-системы оптимальны для их хранения?
Time-series — данные, структурированные по времени. Для хранения подходят InfluxDB, TimescaleDB (но не только), а также Cassandra, MongoDB с TTL и партиционированием по времени. -
Как используются bloom filter в NoSQL-движках?
Bloom filter — вероятностная структура данных, позволяющая быстро проверить, содержится ли ключ в наборе. Используется для ускорения поиска и снижения I/O в LSM-tree хранилищах (Cassandra, HBase). -
Какие механизмы обеспечивают параллелизм в NoSQL-системах?
MVCC, optimistic concurrency control, versioning данных, pessimistic locks (редко), timestamp ordering, compare-and-swap, watch/notify протоколы. -
Что такое tombstone в контексте распределённой NoSQL-базы?
Tombstone — маркер удаления данных, используемый для синхронизации удалённых узлов. Удаляется после успешной репликации и истечения grace period (в Cassandra — gc_grace_seconds). -
Как работают secondary indexes в MongoDB?
Secondary index — дополнительный указатель на документы, основанный на одном или нескольких полях. Может быть композитным, уникальным, sparse или partial. -
Какие особенности имеет оптимизатор запросов в NoSQL-системах?
Он менее развит, чем в SQL, но может выбирать лучший индекс, оптимизировать pipeline в MongoDB Aggregation Framework, использовать costing модели и статистику. -
Как реализуется геопространственное индексирование в MongoDB?
MongoDB поддерживает 2d и 2dsphere индексы для координат. Реализуются через R-tree или Geohash, что позволяет выполнять запросы на близость, полигон и радиус. -
Какие факторы влияют на производительность write-heavy нагрузки в NoSQL?
Batch writes, write-ahead log, memtable/SSTables, compaction strategy, buffer size, disk throughput, write concern, fsync policy. -
Какие практики управления миграцией схем применяются в NoSQL?
Versioned documents, background migration scripts, canary deployment, feature toggle для старых/новых форматов, rolling updates и dual writing. -
Какие методы используются для горячего восстановления данных в NoSQL?
Point-in-time recovery, oplog tailing, streaming из Kafka, read-repair, hinted handoff, backup restore с incremental checkpoint. -
Какие особенности работы с JSON-типами в различных NoSQL-системах?
MongoDB — BSON с динамической схемой; PostgreSQL — JSONB (не наш курс, но важно понимать); Couchbase — N1QL поддерживает запросы по JSON-полям. -
Что такое cache-aside pattern и как он связан с NoSQL?
Cache-aside — паттерн, при котором данные сначала читаются из кэша (например, Redis), а при отсутствии — из основной БД. Используется для повышения производительности. -
Как работают change streams в MongoDB и где они применяются?
Change streams — механизм отслеживания изменений в коллекциях в реальном времени. Применяется для event-driven систем, синхронизации с другими хранилищами и триггеров. -
Какие стратегии шифрования данных используются в NoSQL?
Transparent Data Encryption (TDE), field-level encryption, client-side encryption, TLS/SSL для передачи, использование Vault или KMS для управления ключами. -
Как работают consensus алгоритмы в контексте NoSQL-кластеров?
Raft, Paxos, Multi-Paxos — используются для согласования лидеров, обеспечения последовательности записей и fault tolerance в распределённых системах (например, etcd, CockroachDB). -
Какие метрики наиболее важны при нагрузочном тестировании NoSQL-систем?
Latency percentiles (p99, p95), throughput (RPS/WPS), error rate, GC pauses, replication lag, CPU/Memory usage, disk IO, network bandwidth. -
Как реализуется cross-region репликация в NoSQL?
Через multi-master setup, async/sync geo-replication, logical streaming (например, Kafka Connect), managed services (AWS Global Tables) и custom sync сервисы. -
В чём отличия между логическим и физическим бэкапом в NoSQL?
Логический — сохраняет данные в виде операций (логов, изменений документов), физический — копирует файлы БД. Логический легче переносить, физический быстрее восстанавливается. -
Какие инструменты используются для разработки и отладки запросов в NoSQL?
MongoDB Compass, Studio 3T, Neo4j Browser, DataGrip с плагинами, DevTools, Jupyter Notebook + pymongo, Postman для REST API поверх NoSQL. -
Какие паттерны проектирования данных часто применяются в NoSQL?
Embedded documents, aggregation references, bucketing, super columns, counter caching, sharded sequences, inverted index, graph patterns (friend-of-a-friend, shortest path).
-
Какой тип NoSQL базы данных наиболее подходит для хранения социальных графов?
A) Ключ-значение
B) Документная
C) Графовая
D) Колоночная
Ответ: C -
Какой механизм используется в Cassandra для обеспечения согласованности при записи?
A) MVCC
B) Quorum Write
C) Vector Clocks
D) Two-phase Commit
Ответ: B -
Какой индекс в MongoDB позволяет выполнять текстовые поисковые запросы?
A) Single Field Index
B) Compound Index
C) Text Index
D) Hashed Index
Ответ: C -
Что означает буква "E" в аббревиатуре BASE?
A) Efficient
B) Eventual
C) Elastic
D) Exclusive
Ответ: B -
Какой алгоритм используется в некоторых NoSQL системах для достижения консенсуса между узлами?
A) Paxos
B) Raft
C) Gossip
D) Все вышеперечисленное
Ответ: D -
Какой из следующих факторов НЕ влияет на выбор типа шардинга в MongoDB?
A) Время жизни документа
B) Распределение нагрузки
C) Сложность запросов
D) Частота обновлений
Ответ: A -
Какой метод репликации передаёт изменения на уровне операций БД?
A) Физическая репликация
B) Логическая репликация
C) Snapshot replication
D) File-based replication
Ответ: B -
Какая метрика наиболее важна для анализа производительности чтения в NoSQL?
A) CPU Usage
B) Disk IOPS
C) Read Latency
D) Network Bandwidth
Ответ: C -
Какой из следующих подходов используется для разрешения конфликтов в eventual consistency системах?
A) LRU eviction
B) Last-write-wins
C) FIFO queue
D) Round-robin
Ответ: B -
Какой протокол обеспечивает безопасный доступ к удалённой NoSQL базе?
A) HTTP
B) FTP
C) SSL/TLS
D) UDP
Ответ: C -
Какой движок хранения используется в MongoDB по умолчанию, начиная с версии 3.0?
A) MMAPv1
B) WiredTiger
C) RocksDB
D) BerkeleyDB
Ответ: B -
Какой механизм в Cassandra отвечает за временное хранение записей при недоступности целевого узла?
A) Memtable
B) SSTable
C) Hinted Handoff
D) Bloom Filter
Ответ: C -
Какой тип сериализации данных лучше всего подходит для компактного хранения и высокой скорости передачи?
A) JSON
B) XML
C) Avro
D) CSV
Ответ: C -
Какой из перечисленных принципов является основным в CAP-теореме?
A) Atomicity
B) Availability
C) Durability
D) Isolation
Ответ: B -
Какой инструмент можно использовать для мониторинга производительности NoSQL баз данных?
A) Grafana
B) Docker
C) Kubernetes
D) Jenkins
Ответ: A -
Какой метод пагинации в MongoDB считается наиболее эффективным при больших объёмах данных?
A) skip() + limit()
B) find().limit()
C) where + sort
D) count()
Ответ: C -
Какая стратегия шифрования применяется на уровне отдельных полей в NoSQL?
A) TDE
B) Field-level encryption
C) TLS
D) Vault-based encryption
Ответ: B -
Какой тип партиционирования данных в NoSQL наиболее эффективен для равномерного распределения нагрузки?
A) Range-based
B) List-based
C) Hash-based
D) Zone-based
Ответ: C -
Какой из следующих паттернов используется для повышения отказоустойчивости в распределённых системах?
A) Singleton
B) Circuit Breaker
C) Observer
D) Strategy
Ответ: B -
Какой из следующих параметров определяет количество успешных подтверждений при записи в Cassandra?
A) Consistency Level
B) TTL
C) Replication Factor
D) GC Grace Seconds
Ответ: A -
Какой тип бэкапа включает копирование физических файлов базы данных?
A) Логический
B) Онлайновый
C) Физический
D) Incremental
Ответ: C -
Какое свойство системы гарантирует, что данные будут доступны даже после сбоя?
A) Consistency
B) Partition tolerance
C) Availability
D) Durability
Ответ: D -
Какой из следующих методов может использоваться для реализации транзакций в MongoDB?
A) Two-phase commit
B) Redis Lua script
C) Kafka Connect
D) MapReduce
Ответ: A -
Какой из следующих документов не поддерживает ACID-транзакции в MongoDB?
A) WiredTiger
B) InMemory
C) MMAPv1
D) All of the above
Ответ: C -
Какой из следующих паттернов проектирования данных используется для хранения связанных сущностей в одном документе?
A) Bucketing
B) Embedded Documents
C) Aggregation References
D) Graph Patterns
Ответ: B
-
Какой из следующих факторов НАИБОЛЕЕ критичен при выборе NoSQL базы для high-write нагрузки?
A) Поддержка транзакций
B) Гибкая схема данных
C) Горизонтальная масштабируемость
D) Поддержка ACID
Ответ: C -
Что означает термин "sharding" в контексте NoSQL?
A) Резервное копирование данных
B) Логическое разделение таблиц
C) Горизонтальное разделение данных между узлами
D) Шифрование на уровне столбцов
Ответ: C -
Какая метрика используется для определения времени ответа системы на запрос чтения?
A) Throughput
B) Write Latency
C) Read Latency
D) CPU Load
Ответ: C -
Какой тип индекса в MongoDB подходит для геопространственных данных?
A) Single Field Index
B) Hashed Index
C) 2dsphere Index
D) TTL Index
Ответ: C -
Какой механизм в Cassandra используется для обнаружения и восстановления устаревших данных?
A) Compaction
B) Hinted Handoff
C) Merkle Trees
D) Gossip Protocol
Ответ: C -
Какое свойство систем, согласно CAP-теореме, жертвуется при обеспечении высокой доступности и устойчивости к разрывам сети?
A) Partition Tolerance
B) Consistency
C) Availability
D) Atomicity
Ответ: B -
Какой формат сериализации данных наиболее эффективен по скорости десериализации?
A) JSON
B) XML
C) Avro
D) MessagePack
Ответ: D -
Какой тип отказоустойчивости реализуется через кворумное чтение/запись?
A) Active-Active
B) Active-Passive
C) Quorum-based
D) Stateless
Ответ: C -
Какой из перечисленных движков хранения не используется в MongoDB?
A) WiredTiger
B) MMAPv1
C) RocksDB
D) Berkeley DB
Ответ: C -
Какой механизм в распределённых системах позволяет отслеживать причинность событий?
A) Timestamp
B) Vector Clock
C) Bloom Filter
D) Sequence Number
Ответ: B -
Какой из следующих подходов применяется для минимизации задержек при чтении в реплицированных системах?
A) Read from Leader Only
B) Read from Any Replica
C) Read from Follower with Lowest Lag
D) Random Read
Ответ: C -
Какой параметр в Cassandra определяет количество копий данных?
A) Consistency Level
B) Replication Factor
C) GC Grace Seconds
D) TTL
Ответ: B -
Какой из следующих методов позволяет выполнять агрегацию данных в MongoDB?
A) MapReduce
B) Aggregation Pipeline
C) Group By Clause
D) A и B
Ответ: D -
Какой из перечисленных паттернов проектирования данных используется для хранения временных серий?
A) Bucketing
B) Embedded Documents
C) Super Columns
D) Inverted Index
Ответ: A -
Какой протокол используется в большинстве графовых БД для передачи данных?
A) HTTP/REST
B) Gremlin
C) SQL
D) gRPC
Ответ: B -
Какой из следующих принципов гарантирует, что успешная запись сохранится даже при сбое?
A) Isolation
B) Atomicity
C) Durability
D) Consistency
Ответ: C -
Какой тип шардинга в MongoDB лучше всего подходит для диапазонных запросов?
A) Hash-based
B) Zone-based
C) Range-based
D) Hybrid
Ответ: C -
Какой из следующих инструментов может использоваться для анализа логов NoSQL систем?
A) Prometheus
B) Grafana
C) ELK Stack
D) Все вышеперечисленное
Ответ: D -
Какой механизм в Redis используется для автоматического удаления ключей по истечении времени?
A) TTL
B) LRU
C) LFU
D) Eviction Policy
Ответ: A -
Какой тип индекса в MongoDB может быть создан только для одного поля?
A) Compound Index
B) Text Index
C) Single Field Index
D) Partial Index
Ответ: C -
Какой из следующих подходов используется для тестирования отказоустойчивости NoSQL кластера?
A) Chaos Engineering
B) Unit Testing
C) Integration Testing
D) Regression Testing
Ответ: A -
Какой алгоритм используется в LSM-tree хранилищах для ускорения проверки наличия ключа?
A) Binary Search Tree
B) B+ Tree
C) Bloom Filter
D) Trie
Ответ: C -
Какой из следующих методов используется для горячего восстановления данных в MongoDB?
A) fs-snapshot
B) oplog tailing
C) mongorestore
D) Все вышеперечисленное
Ответ: D -
Какой тип сериализации данных позволяет легко читать данные человеком и программой?
A) Avro
B) Protobuf
C) JSON
D) MessagePack
Ответ: C -
Какой из следующих паттернов используется для разделения данных на основе региональной принадлежности?
A) Graph Pattern
B) Zone-based Sharding
C) Bucketing
D) Embedded Documents
Ответ: B
-
Какой из следующих механизмов используется в MongoDB для отслеживания изменений в коллекциях?
A) Change Streams
B) Triggers
C) Event Hooks
D) Log Tailing
Ответ: A -
Какой тип согласованности гарантирует, что все операции чтения увидят последнее записанное значение?
A) Weak Consistency
B) Eventual Consistency
C) Strong Consistency
D) Causal Consistency
Ответ: C -
Какой параметр в Cassandra определяет количество успешных подтверждений записи перед её завершением?
A) Replication Factor
B) TTL
C) Consistency Level
D) Compaction Strategy
Ответ: C -
Какой метод репликации позволяет снизить нагрузку на мастер-узел за счёт чтения с реплик?
A) Single-master replication
B) Multi-master replication
C) Read-from-replica
D) Cascading replication
Ответ: C -
Какое свойство системы описывает способность восстанавливаться после сбоев без потери данных?
A) Availability
B) Scalability
C) Durability
D) Fault Tolerance
Ответ: D -
Какой из перечисленных инструментов НЕ является клиентской библиотекой для работы с NoSQL базами?
A) PyMongo
B) Golang Driver for Neo4j
C) Hibernate ORM
D) Node.js Redis Client
Ответ: C -
Какой тип шифрования применяется к данным при хранении на диске?
A) In-memory encryption
B) Field-level encryption
C) Transparent Data Encryption (TDE)
D) TLS encryption
Ответ: C -
Какая стратегия масштабирования предполагает добавление новых узлов в систему?
A) Vertical Scaling
B) Horizontal Scaling
C) Hybrid Scaling
D) Dynamic Scaling
Ответ: B -
Какой из следующих факторов влияет на производительность запросов в документной БД?
A) Размер индекса
B) Уровень сериализации
C) Количество реплик
D) Все вышеперечисленное
Ответ: D -
Какой из следующих паттернов проектирования данных используется для оптимизации поиска через обратные ссылки?
A) Bucketing
B) Embedded Documents
C) Inverted Index
D) Graph Pattern
Ответ: C -
Какой механизм в LSM-tree движках объединяет файлы SSTable и удаляет устаревшие данные?
A) Bloom Filter
B) Memtable Flush
C) Compaction
D) Write-ahead Log
Ответ: C -
Какой из следующих принципов CAP-теоремы наиболее важен для банковских транзакций?
A) Consistency
B) Availability
C) Partition Tolerance
D) Все одинаково важны
Ответ: A -
Какой из следующих форматов лучше всего подходит для сериализации схематизированных данных?
A) JSON
B) BSON
C) Avro
D) MessagePack
Ответ: C -
Какой механизм в распределённых системах используется для выбора лидера кластера?
A) Vector Clock
B) Raft
C) Bloom Filter
D) MVCC
Ответ: B -
Какой из следующих параметров определяет время жизни ключа в Redis?
A) LRU
B) LFU
C) TTL
D) Eviction Policy
Ответ: C -
Какой тип отказоустойчивости позволяет системе продолжать работу даже при разделении сети?
A) Active-Passive
B) Quorum-based
C) Partition Tolerant
D) Stateless
Ответ: C -
Какой из следующих подходов используется для обработки больших наборов данных в NoSQL?
A) MapReduce
B) OLTP
C) ACID
D) Normalization
Ответ: A -
Какой из следующих паттернов используется для снижения сетевой нагрузки при частых чтениях?
A) Cache-aside
B) Circuit Breaker
C) Retry Policy
D) Load Balancing
Ответ: A -
Какой механизм в MongoDB обеспечивает автоматическое восстановление после сбоя кластера?
A) Sharding
B) Replica Set
C) Indexing
D) Aggregation
Ответ: B -
Какой из следующих терминов описывает процесс создания физической копии данных для восстановления?
A) Archiving
B) Backup
C) Snapshot
D) B и C
Ответ: D -
Какой из следующих инструментов может использоваться для анализа производительности запросов в MongoDB?
A) Explain()
B) Profiler
C) Compass
D) Все вышеперечисленное
Ответ: D -
Какой из следующих принципов BASE означает, что система в конечном итоге достигнет согласованного состояния?
A) Basically Available
B) Soft state
C) Eventually consistent
D) Elastic
Ответ: C -
Какой тип партиционирования в NoSQL позволяет равномерно распределять данные по ключам?
A) Range-based
B) Hash-based
C) Zone-based
D) List-based
Ответ: B -
Какой из следующих механизмов используется для контроля доступа в NoSQL системах?
A) RBAC
B) MAC
C) DAC
D) Все вышеперечисленное
Ответ: D -
Какой из следующих паттернов проектирования используется для реализации рекомендательных систем?
A) Friend-of-a-friend
B) Bucketing
C) Embedded Documents
D) Super Columns
Ответ: A
Экзаменационный билет №1
Теоретическая часть:
- Опишите основные различия между ACID и BASE подходами в контексте управления транзакциями в базах данных.
- Какие механизмы используются в распределённых NoSQL системах для обеспечения отказоустойчивости?
Ответы:
-
ACID (Atomicity, Consistency, Isolation, Durability) — это строгий набор гарантий, применяемый к транзакциям в реляционных СУБД, обеспечивающий высокую согласованность.
BASE (Basically Available, Soft state, Eventually consistent) — более гибкий подход, характерный для NoSQL-систем, допускающий временную несогласованность ради доступности и масштабируемости. -
Для обеспечения отказоустойчивости в распределённых NoSQL системах применяются:
- Репликация данных (primary-secondary, multi-master),
- Кворумное чтение/запись,
- Heartbeat мониторинг,
- Автоматический failover,
- Использование consensus алгоритмов (Raft, Paxos).
Практическая часть:
- Напишите скрипт на 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
Теоретическая часть:
- Что такое шардинг и какие типы шардинга поддерживаются в MongoDB?
- Какие факторы необходимо учитывать при выборе типа NoSQL базы данных для проекта?
Ответы:
-
Шардинг — это процесс горизонтального разделения данных между несколькими узлами.
Типы шардинга в MongoDB:- Range-based — данные разделяются по диапазонам ключей (подходит для range-запросов).
- Hash-based — равномерное распределение данных через хэширование ключей.
- Zone-based — данные распределяются по зонам, например, регионам или серверным стойкам.
-
При выборе NoSQL БД учитываются:
- Модель данных (документы, графы, колонки, ключ-значение),
- Требования к согласованности (strong/eventual),
- Производительность (read/write throughput),
- Горизонтальная масштабируемость,
- Поддержка транзакций,
- Инфраструктурные требования (облако, on-premise),
- Экосистема и инструменты (мониторинг, бэкапы, миграции).
Практическая часть:
- Напишите запрос на 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
Теоретическая часть:
- Что означает CAP-теорема и как она влияет на проектирование распределённых NoSQL систем?
- Какие механизмы используются в Cassandra для повышения производительности записи?
Ответы:
-
CAP-теорема утверждает, что в распределённой системе можно одновременно реализовать только два из трёх свойств: Consistency (согласованность), Availability (доступность), Partition tolerance (устойчивость к сетевым разрывам).
Это влияет на выбор системы:- CP-системы (Cassandra при QUORUM) — жертвуют доступностью ради согласованности.
- AP-системы (DynamoDB) — жертвуют согласованностью ради доступности.
-
Cassandra оптимизирована под write-heavy нагрузку. Механизмы:
- Write-ahead log (WAL) — для восстановления после сбоев,
- Memtable — временный буфер в памяти,
- SSTable — immutable файлы на диске,
- Compaction — объединяет SSTable и удаляет устаревшие данные,
- Hinted handoff — временное хранение данных при недоступности узла.
Практическая часть:
- Напишите скрипт на 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
Теоретическая часть:
- Что такое eventual consistency и в каких системах она применяется?
- Какие метрики наиболее важны при эксплуатации NoSQL-систем?
Ответы:
-
Eventual consistency — это модель согласованности, при которой все копии данных со временем становятся одинаковыми. Применяется в системах, где важна высокая доступность и масштабируемость, например, Apache Cassandra, Amazon DynamoDB, Riak.
-
Основные метрики:
- Latency (p99, p95) — задержка операций чтения/записи,
- Throughput (RPS/WPS) — количество операций в секунду,
- CPU/Memory usage — загрузка ресурсов,
- Disk I/O — использование дисковой подсистемы,
- Replication lag — задержка репликации,
- GC pauses — время сборки мусора (в JVM-движках),
- Error rate — частота ошибок,
- Connection count — количество активных подключений.
Практическая часть:
- Напишите функцию на 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
Теоретическая часть:
- Что такое TTL-индекс в MongoDB и когда его стоит использовать?
- Какие особенности проектирования схем характерны для Cassandra?
Ответы:
-
TTL-индекс (Time-To-Live Index) автоматически удаляет документы из коллекции после истечения указанного времени.
Используется:- Для временных данных (логи, кэш),
- Чтобы избежать необходимости ручного удаления устаревших записей.
-
Особенности проектирования схем в Cassandra:
- Проектирование «под запросы»,
- Оптимизация под write-heavy нагрузки,
- Использование составных первичных ключей (partition key + clustering columns),
- Денормализация данных,
- Ограничения secondary индексов,
- Учет особенностей партиционирования и распределения данных.
Практическая часть:
- Напишите 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
Теоретическая часть:
- Какие типы индексов поддерживаются в MongoDB и в каких сценариях они применяются?
- Что такое vector clock и где он используется?
Ответы:
-
В MongoDB поддерживаются следующие типы индексов:
- Single Field — для поиска по одному полю.
- Compound Index — для составных запросов, использующих несколько полей.
- Multikey Index — для массивов.
- Text Index — для полнотекстового поиска.
- Geospatial Index (2d / 2dsphere) — для геопространственных данных.
- Hashed Index — для шардинга и равномерного распределения нагрузки.
- TTL Index — для автоматического удаления устаревших документов.
-
Vector clock — это механизм отслеживания причинно-следственных связей между изменениями в распределённых системах. Используется в системах с eventual consistency (например, Riak) для разрешения конфликтов при репликации.
Практическая часть:
- Напишите скрипт на 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
Теоретическая часть:
- Какие особенности проектирования схем характерны для графовых баз данных?
- Какие стратегии используются для обеспечения отказоустойчивости в NoSQL-системах?
Ответы:
-
Проектирование схем в графовых БД основывается на модели "узлы → связи". Узлы представляют объекты, связи — отношения между ними. Ключевые моменты:
- Оптимизация обхода графа,
- Индексирование вершин и рёбер,
- Эффективное представление сложных отношений (социальные графы, рекомендации).
-
Для обеспечения отказоустойчивости в NoSQL-системах применяются:
- Репликация (синхронная/асинхронная),
- Кворумное чтение/запись,
- Heartbeat мониторинг состояния узлов,
- Автоматический failover,
- Cross-region deployment,
- Использование consensus алгоритмов (Raft, Paxos).
Практическая часть:
- Напишите 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
Теоретическая часть:
- Как работает MapReduce в контексте NoSQL?
- Какие проблемы могут возникнуть при масштабировании NoSQL-систем?
Ответы:
-
MapReduce — парадигма обработки больших объёмов данных, позволяющая выполнять агрегации и анализ в распределённой среде. Применяется в MongoDB, Hadoop, Couchbase и других системах. Состоит из двух фаз:
- Map — преобразование входных данных в пары ключ-значение.
- Reduce — группировка и агрегация значений по ключам.
-
При масштабировании NoSQL-систем возможны следующие проблемы:
- Hot partitions (неравномерное распределение нагрузки),
- Network partitioning,
- Потеря согласованности,
- Сложности с миграцией данных,
- Увеличение latency,
- Управление состоянием кластера.
Практическая часть:
- Напишите функцию на 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
Теоретическая часть:
- Что такое MVCC и как он применяется в NoSQL?
- Какие практики используются для тестирования и отладки NoSQL решений?
Ответы:
-
MVCC (Multi-Version Concurrency Control) — механизм управления конкурентным доступом, позволяющий разным транзакциям видеть разные версии данных. Применяется в некоторых документных и колоночных БД (например, Couchbase, PostgreSQL) для повышения параллелизма и снижения блокировок.
-
Для тестирования и отладки NoSQL решений применяются:
- Unit- и интеграционное тестирование,
- Load testing (JMeter, Locust),
- Profiling и explain(),
- Логирование и метрики,
- Использование mock-серверов,
- A/B тестирование с реальными нагрузками.
Практическая часть:
- Напишите 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
Теоретическая часть:
- Что такое hinted handoff и в какой системе он используется?
- Как работают change streams в MongoDB и где они применяются?
Ответы:
-
Hinted handoff — временная запись данных на другом узле в случае недоступности целевого, чтобы восстановить данные после возврата узла в строй. Применяется в Apache Cassandra.
-
Change streams — механизм отслеживания изменений в коллекциях в реальном времени. Применяется для event-driven систем, синхронизации с другими хранилищами и триггеров. Реализован в MongoDB начиная с версии 3.6.
Практическая часть:
- Напишите 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
Теоретическая часть:
- Что такое materialized view в NoSQL и как она применяется?
- Какие особенности проектирования схем характерны для Cassandra?
Ответы:
-
Materialized view — это предрассчитанное представление данных, хранящееся физически. Используется для ускорения сложных запросов, особенно в Cassandra и Couchbase. В отличие от виртуальных представлений, данные хранятся заранее и обновляются при изменении исходных таблиц.
-
Особенности проектирования схем в Cassandra :
- Проектирование под запросы (query-driven),
- Использование составного первичного ключа (
partition key
+clustering columns
), - Денормализация данных,
- Оптимизация под write-heavy нагрузки,
- Ограничения secondary индексов,
- Учет особенностей распределения данных по токенам.
Практическая часть:
- Напишите 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
Теоретическая часть:
- Как работают TTL-коллекции в Redis и как они управляются?
- Какие метрики необходимо отслеживать при эксплуатации NoSQL-баз?
Ответы:
-
TTL (Time To Live) в Redis позволяет задавать время жизни ключа. После истечения этого времени ключ автоматически удаляется. Управление осуществляется через команды:
EXPIRE key seconds
— установить TTL в секундах.PEXPIRE key milliseconds
— установить TTL в миллисекундах.TTL key
— проверить оставшееся время жизни.- Полезно для кэширования, временных данных, сессий.
-
Основные метрики для мониторинга:
- Latency (p99, p95) — время выполнения операций чтения/записи.
- Throughput (RPS/WPS) — количество операций в секунду.
- CPU/Memory usage — использование ресурсов.
- Disk I/O — скорость работы с диском.
- Replication lag — задержка между мастером и репликами.
- Error rate — частота ошибок.
- Connection count — количество активных соединений.
- Compaction stats — в системах типа Cassandra, RocksDB.
Практическая часть:
- Напишите скрипт на 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
Теоретическая часть:
- Какие проблемы могут возникнуть при использовании long-running connections в NoSQL-клиентах?
- Как организовать безопасный удалённый доступ к NoSQL-базе?
Ответы:
-
Проблемы при использовании долгих соединений:
- Сетевые разрывы и таймауты,
- Утечки памяти (memory leaks),
- Застойные (stale) соединения,
- Исчерпание ресурсов (zombie процессы, лимиты на подключения),
- Решаются через keep-alive, connection pooling, health checks, reconnection policies.
-
Для безопасного удалённого доступа к NoSQL базам:
- Использование SSH-туннелей или VPN,
- Шифрование TLS/SSL,
- RBAC (Role-Based Access Control),
- Настройка фаервола и VPC,
- Аудит подключений,
- API gateways с авторизацией,
- Принцип минимальных привилегий (least privilege).
Практическая часть:
- Напишите 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
Теоретическая часть:
- Как реализуется поддержка транзакций в NoSQL-системах?
- Какие практики используются для тестирования отказоустойчивости NoSQL-кластера?
Ответы:
-
Поддержка транзакций в NoSQL:
- MongoDB (4.0+) — многошардовые транзакции с двухфазным коммитом.
- Couchbase — транзакции через SDK.
- DynamoDB — ACID-транзакции на уровне одного элемента или партиции.
- Cassandra — ограниченная поддержка через lightweight transactions (CAS).
- Kafka Streams — event sourcing и stateful processing.
- Saga Pattern — для распределённых транзакций вне БД.
-
Практики тестирования отказоустойчивости:
- Chaos Engineering (например, Chaos Monkey),
- Принудительное отключение узлов,
- Имитация сетевых разрывов,
- Проверка восстановления из backup,
- Stress testing,
- Fault injection.
Практическая часть:
- Напишите 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
Теоретическая часть:
- Какие факторы влияют на производительность write-heavy нагрузки в NoSQL?
- Какие типы шардинга поддерживаются в MongoDB?
Ответы:
-
Факторы, влияющие на write-heavy нагрузку:
- Batch writes,
- Write-ahead log (WAL),
- Memtable/SSTables (LSM-tree),
- Compaction strategy,
- Размер буфера,
- Дисковый IOPS,
- Write concern,
- fsync policy.
-
Типы шардинга в MongoDB:
- Range-based — данные делятся по диапазонам ключей (подходит для range-запросов).
- Hash-based — равномерное распределение данных через хэширование ключей.
- Zone-based — данные распределяются по зонам (например, регионам).
Практическая часть:
- Напишите функцию на 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") за период.
Проблемы, выявленные в процессе эксплуатации:
- Запросы на чтение выполняются медленно , особенно при выборке за длительный период.
- Некоторые узлы перегружены , наблюдается неравномерное распределение нагрузки (hot partitions).
- При увеличении числа пользователей возникают ошибки timeout и повышается latency .
- Некоторые данные теряются или не записываются при сетевых сбоях между клиентом и Cassandra.
Задача:
- Выявите причины проблем в текущем дизайне модели данных и архитектуре.
- Предложите изменения в модель данных, конфигурацию кластера и/или подход к работе с данными.
- Обоснуйте свои решения с точки зрения производительности, масштабируемости и отказоустойчивости.
Решение:
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';
Проблемы, выявленные после анализа:
- Высокая задержка JOIN'ов между несколькими таблицами при увеличении объёма данных.
- Невозможность горизонтального масштабирования PostgreSQL без внешних инструментов.
- Частые блокировки таблиц при параллельных транзакциях.
- Жесткая схема данных , которая затрудняет добавление новых полей или гибкое изменение структуры заказов.
- Нагрузка на один сервер — становится бутылочным горлышком.
Задача:
- Обосновать выбор подходящего типа NoSQL СУБД для задачи.
- Предложить новую модель данных, учитывающую специфику выбранной NoSQL базы.
- Описать процесс миграции с минимальным downtime.
- Указать возможные подводные камни при переходе и способы их минимизации.
Решение:
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. Процесс миграции:
Этапы:
-
Подготовка:
- Создание нового микросервиса
OrdersNoSQL
, работающего параллельно с текущим. - Настройка двойной записи: все новые заказы пишутся в обе БД.
- Создание нового микросервиса
-
Перенос исторических данных:
- Использовать ETL-процесс (Apache NiFi, custom скрипты) для преобразования и переноса старых заказов в MongoDB.
- Добавить флаг
migrated: true
.
-
Тестирование:
- Тестирование новых API и проверка согласованности данных.
- Сравнение времени выполнения запросов.
-
Переключение трафика:
- Перевести клиентов на новый микросервис через API Gateway.
- Отключить PostgreSQL после завершения всех проверок.
4. Возможные подводные камни и решения:
Итог:
После миграции:
- Скорость обработки запросов увеличилась на 40–60%.
- Система стала готова к горизонтальному масштабированию.
- Команда получила гибкость в управлении данными.
- Снизились накладные расходы на обслуживание JOIN'ов и блокировок.
Ролевая игра №1: "Проектирование масштабируемой системы хранения данных для онлайн-игры"
Цель игры:
Научить участников проектировать, обосновывать выбор и настраивать NoSQL-решения в условиях высоких нагрузок и сложных бизнес-требований. Развить навыки командной работы, анализа требований и принятия технических решений под реальные сценарии.
Формат:
- Групповая ролевая игра (4–6 человек в команде)
- Продолжительность: 2–3 академических часа
- Форма проведения: очная или онлайн с использованием досок (Miro, Jamboard), чата и презентаций
- Итог: устная защита решения + техническая документация / диаграммы модели данных
Сеттинг:
Вы — команда разработчиков и архитекторов, работающих в стартапе, который создаёт новую многопользовательскую онлайн-игру. Ваша задача — спроектировать систему хранения пользовательских данных, игровых сессий, инвентаря, достижений и рейтинга игроков.
Компания ожидает:
- Поддержку до 100 000 активных пользователей одновременно,
- Обработку 5000 операций записи и 20 000 операций чтения в секунду,
- Высокую доступность (99.9% uptime),
- Быстрое восстановление после сбоев,
- Гибкость при добавлении новых игровых механик.
Роли в команде:
Этапы игры:
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 занимает слишком много времени.
Вам необходимо:
- Диагностировать проблему,
- Принять экстренные меры для восстановления доступности,
- Предложить долгосрочные решения для предотвращения подобных ситуаций.
Роли в команде:
Этапы игры:
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 систем, проанализировать их соответствие требованиям проекта и представить обоснованное решение на совещании с техническим директором.
Роли в команде:
Этапы игры:
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, перегрузку отдельных шардов.
Вам нужно:
- Проанализировать текущее состояние кластера,
- Выявить узкие места,
- Предложить и реализовать меры по оптимизации производительности.
Роли в команде:
Этапы игры:
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. Включает упражнения по созданию коллекций, написанию запросов, индексированию, шардингу и агрегациям.
Ценность для курса: Может использоваться как задачник для студентов при изучении документно-ориентированных СУБД.
-
NoSQL: Профессиональное проектирование и эксплуатация Курс по углубленному изучению архитектуры, моделированию данных и администрированию NoSQL решений в высоконагруженных системах.
-
Разработка масштабируемых NoSQL решений Научитесь создавать отказоустойчивые и производительные системы хранения данных на основе NoSQL технологий.
-
NoSQL для распределённых систем Изучение особенностей применения NoSQL в микросервисных и cloud-native архитектурах.
-
Профессиональная работа с MongoDB Глубокое погружение в проектирование, оптимизацию и администрирование документных БД на примере MongoDB.
-
Графовые базы данных: от теории к практике Курс по Neo4j и другим графовым СУБД, включая моделирование связей и обработку социальных графов.
-
Cassandra: Масштабирование и отказоустойчивость Подробное изучение Apache Cassandra — от модели данных до управления кластером в production.
-
Redis: Высокопроизводительные решения Применение Redis в качестве кэша, message broker и in-memory хранилища с акцентом на производительность и отказоустойчивость.
-
NoSQL и Big Data: интеграция с Hadoop и Spark Освоение работы с NoSQL в экосистеме больших данных, включая ETL-процессы и аналитику.
-
Использование DynamoDB в облачных архитектурах Практический курс по применению Amazon DynamoDB в облачных решениях с акцентом на шардинг и автоматизацию.
-
Технологии временных рядов и NoSQL Изучение применения Time Series DB (InfluxDB, Cassandra) и их интеграции в IoT и мониторинговые системы.
-
NoSQL и искусственный интеллект Интеграция NoSQL решений в ML-системы, хранение неструктурированных данных и организация data lakes.
-
Администрирование NoSQL кластеров Углублённый курс по управлению кластерами, репликации, балансировке нагрузки и мониторингу производительности.
-
Оптимизация производительности NoSQL Практические методики улучшения скорости чтения/записи, снижения latency и повышения throughput.
-
Сравнительный анализ NoSQL решений Сравнение типов NoSQL СУБД и выбор наиболее подходящего решения под конкретную предметную область.
-
Интеграция NoSQL в DevOps процессы Автоматизация деплоя, миграции схем, бэкапов и восстановления данных в CI/CD pipeline.
-
Безопасность в NoSQL системах Обеспечение конфиденциальности, контроля доступа, шифрования и аудита в NoSQL средах.
-
NoSQL и микросервисная архитектура Использование NoSQL в составе микросервисов: изоляция данных, согласованность, транзакции и интеграция.
-
Построение аналитических систем на NoSQL Создание систем бизнес-аналитики с использованием NoSQL, Elasticsearch и других инструментов.
-
Chaos Engineering и тестирование отказов в NoSQL Методы тестирования отказоустойчивости, fault tolerance и disaster recovery в распределённых NoSQL системах.
-
Разработка API поверх NoSQL Построение RESTful и GraphQL API над NoSQL хранилищами, включая кэширование и обработку ошибок.
-
Моделирование данных в NoSQL Техники проектирования моделей данных для различных типов NoSQL СУБД с учётом требований бизнес-логики.
-
NoSQL в реальном времени Разработка систем обработки событий в реальном времени с использованием stream processing и NoSQL.
-
Работа с геопространственными данными в NoSQL Хранение и обработка геолокационной информации в NoSQL, включая индексирование и пространственные запросы.
-
NoSQL для интернета вещей (IoT) Использование NoSQL в системах сбора, хранения и обработки данных с датчиков и устройств IoT.
-
Экспертный уровень: внутреннее устройство NoSQL Курс о том, как работают движки NoSQL внутри: storage engines, сериализация, MVCC, vector clocks и consensus алгоритмы.
Нет элементов для просмотра