NoSQL — итоги
Кратко — что стоит унести из раздела "NoSQL". Если пункт кажется туманным — откройте указанную главу или оглавление.
FAQ — Часто задаваемые вопросы
Типичные ситуации при выборе и эксплуатации NoSQL: с чем сталкиваются новички и junior-разработчики. Здесь — что проверить и куда смотреть в главах; формулировки для самопроверки — в чек-листе.
Вопрос. Руководство просит "перейти с PostgreSQL на MongoDB, потому что NoSQL быстрее". С чего начать аргументированный ответ?
Ответ. Сначала опишите паттерны запросов и требования к целостности: транзакции, отчёты с JOIN, жёсткие связи — сильная сторона SQL; гибкие документы, горизонтальный масштаб записи, кэш — зоны NoSQL. Часто нужен гибрид, а не замена одного другим. Подробнее здесь — Основы NoSQL, NewSQL.
Вопрос. Храним данные в JSON-файлах на диске — "это же почти MongoDB". Что сломается в production?
Ответ. Файлы не дают конкурентной записи, репликации, индексов, атомарных обновлений и мониторинга под нагрузкой. При росте команды и трафика появятся гонки, потери данных и невозможность восстановления. Подробнее здесь — MongoDB, Основы NoSQL.
Вопрос. Запрос в MongoDB возвращает пустой массив, хотя документ в Compass виден. Где искать ошибку?
Ответ. Частые причины — опечатка в имени поля, обращение к вложенному полю без точечной нотации (address.city), фильтр по типу (строка "1" вместо числа 1) или запрос к другой базе/коллекции. Сверьте фильтр с реальным BSON. Подробнее здесь — Синтаксис запросов, практикум MongoDB.
Вопрос. При insertOne MongoDB падает с E11000 duplicate key error. Что это значит?
Ответ. Нарушено уникальное ограничение — чаще всего индекс на _id или явный unique index. Проверьте, не вставляете ли вы тот же ключ повторно, и совпадает ли генерация _id в приложении. Подробнее здесь — справочник MongoDB.
Вопрос. Коллекция небольшая, а find() тормозит секундами. С чего начать диагностику?
Ответ. Выполните explain() на запросе: COLLSCAN означает полный обход. Добавьте индекс под поля в $match и $sort, уберите лишние поля из выборки. На больших коллекциях глубокий skip() тоже даёт задержку — переходите на курсорную пагинацию. Подробнее здесь — MongoDB, справочник § индексы.
Вопрос. Записали документ в MongoDB, сразу читаем с другой реплики — старое значение. Это баг?
Ответ. При read preference на secondary и без write concern majority реплика может отставать — это ожидаемое поведение при eventual consistency. Для "прочитать своё" используйте primary или readConcern: "majority". Подробнее здесь — Основы NoSQL, репликация в справочнике.
Вопрос. Ошибка "document exceeds maximum size 16MB" при сохранении отчёта или лога.
Ответ. Один BSON-документ в MongoDB ограничен 16 МиБ. Крупные бинарники и длинные потоки событий выносите в GridFS или храните ссылку на объектное хранилище, а в документе — метаданные и fileId. Подробнее здесь — GridFS, практикум GridFS.
Вопрос. Дублировать имя автора в каждый пост или хранить только authorId — как выбрать на старте проекта?
Ответ. Смотрите на частые запросы: лента "пост + имя автора без второго запроса" → денормализация; частые переименования автора → ссылка и $lookup или дубли с явной стратегией обновления. Подробнее здесь — проектирование схемы, MongoDB.
Вопрос. После перезагрузки сервера Redis "пустой", хотя вчера там были сессии.
Ответ. По умолчанию Redis держит данные в памяти; без RDB/AOF после рестарта ключи пропадают. Для сессий и кэша закладывайте восстановление из основной БД или включайте персистентность с пониманием компромиссов по latency. Подробнее здесь — Redis, справочник Redis.
Вопрос. Redis отвечает OOM command not allowed when used memory > maxmemory.
Ответ. Достигнут лимит maxmemory. Проверьте политику вытеснения (maxmemory-policy), TTL на ключах, "вечные" кэши без срока и утечки имён ключей. В production задайте лимит осознанно, а не "сколько ОЗУ останется". Подробнее здесь — Redis, справочник.
Вопрос. В скрипте обслуживания вызвали KEYS * — Redis "завис" на минуты.
Ответ. KEYS блокирует однопоточный event loop на всём объёме ключей. В production используйте SCAN с курсором и лимитом COUNT. Подробнее здесь — справочник Redis, подсказки в чек-листе.
Вопрос. Хотим хранить заказы только в Redis — "он же быстрый". Почему архитектор против?
Ответ. Redis оптимален как кэш, сессии, очереди, счётчики, а не как единственный источник финансовых и юридически значимых данных без продуманной персистентности и модели восстановления. Заказы требуют долговременного хранения, отчётности и транзакционной дисциплины — смотрите SQL или MongoDB с репликацией. Подробнее здесь — Redis, Memcached.
Вопрос. Два инстанса приложения сняли одну Redis-блокировку — оба думают, что владеют ресурсом.
Ответ. Блокировка должна ставиться через SET key token NX EX, а сниматься Lua-скриптом "удали, только если значение мой token". Слепой DEL или истечение TTL без продления даёт гонки. Подробнее здесь — практика Redis, Lua и транзакции.
Вопрос. Cassandra ругается на запрос и предлагает ALLOW FILTERING. Можно добавить и забыть?
Ответ. ALLOW FILTERING заставляет узлы сканировать лишние партиции — на больших таблицах это таймауты и нагрузка на весь кластер. Перепроектируйте таблицу под запрос: partition key и clustering columns должны совпадать с фильтрами. Подробнее здесь — Cassandra, практикум CQL.
Вопрос. Запись в Cassandra быстрая, а чтение "по email пользователя" невозможно без полного скана.
Ответ. В wide-column модели запрос задаёт схему, а не наоборот. Для поиска по вторичному полю нужна отдельная таблица под этот access pattern или материализованное представление, а не "добавим индекс как в SQL". Подробнее здесь — Cassandra, справочник CQL.
Вопрос. Удалили строку в Cassandra, а через месяц чтения стали медленными и растёт диск.
Ответ. Удаления оставляют tombstones; их накопление тормозит compaction и чтения. Планируйте TTL, избегайте массовых DELETE по неключевым полям, следите за gc_grace_seconds и repair. Подробнее здесь — Cassandra, Основы NoSQL.
Вопрос. Один узел Cassandra после сбоя "отстаёт" — сервис уже пишет, а на нём старые данные.
Ответ. Нужен repair и проверка consistency level на запись/чтение. Долго недоступный узел без repair расходится с кластером; при возврате может отдавать устаревшие строки до синхронизации. Подробнее здесь — Cassandra, уровни консистентности.
Вопрос. Задача "найти друзей друзей" в PostgreSQL через рекурсивные JOIN уже на 10 секунд. Neo4j обязателен?
Ответ. При глубоких обходах связей и частых path-запросах графовая СУБД даёт выигрыш; для плоских справочников и редких связей SQL достаточно. Оцените объём рёбер, глубину обхода и частоту запросов до введения Neo4j в стек. Подробнее здесь — Графовые БД, мини-практикум Cypher.
Вопрос. Memcached или Redis для кэша страниц — что выбрать на учебном проекте?
Ответ. Memcached — простой RAM-кэш по ключу без структур данных и персистентности. Redis — структуры, TTL, pub/sub, streams, Lua; сложнее, но гибче. Для "положить HTML по URL" часто хватит Memcached; для сессий, лимитов и очередей — Redis. Подробнее здесь — Memcached, первые шаги Memcached, Redis.
Вопрос. Подняли Cassandra на трёх маленьких VM "на будущее" — кластер тяжёлый, а данных мало.
Ответ. Cassandra рассчитана на распределённую запись и отказоустойчивость; на малых объёмах overhead JVM, gossip и repair может превышать выгоду. Для прототипа часто достаточно PostgreSQL или MongoDB, Cassandra — когда измеримый поток событий и требования к multi-DC. Подробнее здесь — История NoSQL, Cassandra.
Вопрос. Каждый микросервис получил свою NoSQL — отчёт "сколько клиентов купили X" стал кошмаром.
Ответ. Распределённые данные без согласованности и интеграции (CDC, event bus, read-model, ETL) ломают сквозную аналитику. Заранее решите, где источник истины, как синхронизировать справочники и нужен ли отдельный аналитический контур. Подробнее здесь — Основы NoSQL, NewSQL.
Вопрос. Миграция "выгрузили таблицы в JSON и импортировали в MongoDB" — что обычно забывают?
Ответ. Индексы, уникальность, связи, транзакционные инварианты и отчёты, которые в SQL шли одним JOIN. Спланируйте схему под запросы, валидацию на коллекции, стратегию идемпотентного импорта и rollback. Подробнее здесь — проектирование схемы, MongoDB.
Вопрос. Собираем фильтр MongoDB строкой из параметров URL — опасно ли это?
Ответ. Да: пользователь может передать операторы вроде $gt в JSON и расширить выборку. Используйте типизированные фильтры драйвера, whitelist полей и валидацию входа — аналог SQL-инъекции для документных запросов. Подробнее здесь — Синтаксис запросов, MongoDB.
Вопрос. Как сделать бэкап MongoDB на живой системе без "остановить всё на ночь"?
Ответ. Для replica set — mongodump с secondary или snapshot диска на hidden node с oplog; для sharded — согласованная процедура по shard'ам. Проверяйте восстановление на стенде, а не только наличие файла .archive. Подробнее здесь — справочник § репликация, MongoDB.
Вопрос. После шардирования MongoDB один shard постоянно на 100% CPU, остальные простаивают.
Ответ. Типичный hot shard из-за монотонного shard key (timestamp, auto-increment). Используйте hashed key или compound prefix с высокой кардинальностью. Подробнее здесь — шардирование в справочнике, MongoDB.
Вопрос. Пользователь видит "старый" баланс бонусов сразу после оплаты — "база сломалась"?
Ответ. При eventual consistency UI может читать реплику до репликации записи. Для денег и балансов задайте strong read/write concern, читайте с primary или показывайте optimistic UI с подтверждением. Подробнее здесь — Основы NoSQL, NewSQL.
Вопрос. Во время сетевого разделения дата-центров сервис "и пишет, и читает" — потом данные расходятся. Что произошло?
Ответ. Кластер выбрал доступность при partition (AP в терминах CAP); конфликты решаются политикой LWW, версиями или ручным merge. На этапе проектирования зафиксируйте допустимые потери и сценарий слияния. Подробнее здесь — Основы NoSQL, Cassandra.
Вопрос. Нужны распределённые транзакции и SQL-совместимость — смотреть только MongoDB 4+?
Ответ. Multi-document transactions в MongoDB закрывают часть OLTP-сценариев, но для горизонтального SQL с ACID смотрите NewSQL (CockroachDB, Spanner). Они дополняют Redis/Cassandra, а не заменяют их в кэше и потоках событий. Подробнее здесь — NewSQL, практикум CockroachDB.
Вопрос. В документе MongoDB поле иногда отсутствует, иногда null — фильтр { status: null } ведёт себя странно.
Ответ. В MongoDB нет поля и явный null — разные случаи. Для "поля нет" используйте { status: { $exists: false } }; унифицируйте схему на этапе записи. Подробнее здесь — практикум, справочник.
Вопрос. Primary MongoDB недоступен — приложение падает, хотя "есть же реплики".
Ответ. Строка подключения должна указывать весь replica set и корректный replicaSet=…; драйвер ждёт выбор нового primary после failover (обычно секунды). Проверьте majority и сценарий partition без кворума. Подробнее здесь — справочник § репликация, Основы NoSQL.
Вопрос. Что такое NoSQL простыми словами?
Ответ. NoSQL (Not Only SQL) — семейство СУБД для масштаба, гибкой схемы и распределённых нагрузок: документы, ключ-значение, wide-column, графы. Это дополнение к SQL, а не одна замена PostgreSQL. Подробнее здесь — Основы NoSQL, история.
Вопрос. NoSQL или SQL — что выбрать для нового проекта?
Ответ. SQL — транзакции, отчёты, жёсткие связи; NoSQL — высокая запись, гибкие документы, кэш, потоки событий, графы. Часто берут оба слоя в одной архитектуре. Подробнее здесь — Основы NoSQL, SQL — о разделе.
Вопрос. Чем MongoDB отличается от PostgreSQL и MySQL?
Ответ. MongoDB хранит BSON-документы без фиксированной таблицы, масштабируется шардированием и replica set; PostgreSQL/MySQL — реляционные таблицы, JOIN, ACID "из коробки". Подробнее здесь — MongoDB, PostgreSQL.
Вопрос. Redis для чего используется и чем отличается от базы данных?
Ответ. Redis — in-memory хранилище ключ-значение: кэш, сессии, очереди, rate limit, pub/sub. Основные данные заказов и пользователей обычно лежат в SQL или MongoDB, Redis ускоряет доступ. Подробнее здесь — Redis, первые шаги.
Вопрос. Redis или Memcached — что выбрать для кэша сайта?
Ответ. Memcached — простой get/set/delete по ключу для HTML и объектов. Redis — структуры данных, TTL, Lua, Streams; сложнее, но нужен для сессий и очередей. Подробнее здесь — Memcached, Redis.
Вопрос. Когда нужна Apache Cassandra и для каких задач?
Ответ. Cassandra — миллионы записей в секунду, multi-DC, append-only потоки: IoT, логи, телеметрия, event sourcing. Схему проектируют под запрос, а не под ER-диаграмму. Подробнее здесь — Cassandra, практикум CQL.
Вопрос. Neo4j и графовые базы — для каких задач подходят?
Ответ. Когда важны связи: рекомендации, соцграф, fraud, shortest path, knowledge graph. Запросы на Cypher обходят граф быстрее, чем многоуровневые JOIN в SQL. Подробнее здесь — Графовые БД, справочник Cypher.
Вопрос. Что такое документоориентированная база данных с примером?
Ответ. Данные — JSON/BSON-документ в коллекции: профиль пользователя с адресом и настройками в одном объекте. Типичный представитель — MongoDB. Подробнее здесь — MongoDB, синтаксис запросов.
Вопрос. Как работает шардирование в MongoDB?
Ответ. Данные делят по shard key между shard'ами; mongos маршрутизирует запросы. Неверный ключ даёт hot shard — один узел на всю нагрузку. Подробнее здесь — шардирование, MongoDB.
Вопрос. Eventual consistency — что это значит на практике?
Ответ. После записи реплики сходятся со временем; чтение с другого узла может вернуть старое значение секунды или дольше. Для баланса и инвентаря нужны stronger guarantees. Подробнее здесь — Основы NoSQL, Cassandra — consistency level.
Вопрос. Что такое CAP-теорема и при чём тут NoSQL?
Ответ. В распределённой системе при сбое сети (Partition) выбирают между согласованностью (C) и доступностью (A). Большинство NoSQL в partition ближе к AP с eventual consistency. Подробнее здесь — Основы NoSQL.
Вопрос. NewSQL и CockroachDB — что это и зачем, если есть MongoDB?
Ответ. NewSQL даёт горизонтальный масштаб плюс SQL и распределённые транзакции (CockroachDB, Spanner). MongoDB закрывает документы; NewSQL — когда нужен привычный SQL и ACID на кластере. Подробнее здесь — NewSQL.
Вопрос. Как начать учить MongoDB с нуля — куда зайти первым делом?
Ответ. Маршрут: основы NoSQL → MongoDB → 15-минутный практикум → справочник. Сначала CRUD и индексы, потом агрегация и репликация.
Вопрос. Как подключить Redis к приложению на Python, Node.js или Java?
Ответ. Через клиентские библиотеки (redis-py, ioredis, Lettuce): host, port, password, db index. Паттерн cache-aside — get → при промахе SQL → set с TTL. Подробнее здесь — Redis, справочник.
Вопрос. MongoDB бесплатная или платная — Community vs Atlas?
Ответ. Community Edition — open source, ставите сами. Atlas — managed-облако MongoDB Inc. с бэкапами и мониторингом. Для учёбы достаточно локального Community или free tier Atlas. Подробнее здесь — MongoDB, облачное администрирование.
Вопрос. Что такое wide-column store и чем Cassandra похожа на Bigtable?
Ответ. Модель partition key + clustering columns: строки сгруппированы в партиции на узлах; внутри партиции — сортировка по clustering key. Cassandra и HBase — типичные wide-column СУБД. Подробнее здесь — Cassandra, оглавление раздела.
Вопрос. Как сделать JOIN в MongoDB — есть ли аналог SQL?
Ответ. Через $lookup в aggregation pipeline или денормализацию в документе. Частые JOIN на больших коллекциях — сигнал пересмотреть схему под access pattern. Подробнее здесь — MongoDB, практикум с $lookup.
Вопрос. DynamoDB аналог open source — что выбрать?
Ответ. Близкие идеи — Cassandra (wide-column, partition key), MongoDB (документы), managed — MongoDB Atlas, CockroachDB. Выбор зависит от облака, модели данных и нужды в SQL. Подробнее здесь — Cassandra, NewSQL.
Вопрос. Elasticsearch — это NoSQL и чем отличается от MongoDB?
Ответ. Elasticsearch — поисковый и аналитический движок по инвертированному индексу; MongoDB — primary store для документов приложения. Часто идут вместе: MongoDB — источник истины, ES — полнотекстовый поиск. Подробнее здесь — MongoDB, анализ данных.
Вопрос. Как хранить сессии пользователей — Redis, MongoDB или PostgreSQL?
Ответ. Для web-сессий с TTL типичен Redis (быстро, expires). PostgreSQL — если нужна долговременная аудируемая история; MongoDB — реже, для document-сессий. Подробнее здесь — Redis, Memcached.
Вопрос. Что такое CQRS и Event Sourcing в контексте NoSQL?
Ответ. Event Sourcing пишет события в append-only log (Cassandra, Kafka); CQRS разделяет модель записи и чтения — read-model часто в Redis или денормализованном MongoDB. Подробнее здесь — Cassandra, Основы NoSQL.
Вопрос. NoSQL базы данных список — какие главные типы и продукты?
Ответ. Четыре модели: документы (MongoDB), ключ-значение (Redis, Memcached), wide-column (Cassandra), граф (Neo4j); плюс NewSQL (CockroachDB). Обзор и маршрут — оглавление раздела, основы.
Вопрос. Как выбрать NoSQL базу под стартап или pet-проект?
Ответ. Начните с одной понятной задачи: кэш → Redis; гибкий каталог → MongoDB; поток событий → Cassandra позже. SQL (PostgreSQL) часто достаточен на старте; NoSQL добавляйте по измеренному bottleneck. Подробнее здесь — основы, выбор СУБД.
Вопрос. GraphRAG и векторный поиск — как NoSQL связан с LLM и RAG?
Ответ. Векторные индексы и граф знаний (Neo4j, MongoDB Atlas Vector Search) дополняют RAG: эмбеддинги для similarity, граф — для связей между сущностями (GraphRAG). Подробнее здесь — Графовые БД, MongoDB.
Что запомнить
NoSQL — это семейство подходов к хранению и обработке данных, возникшее в ответ на ограничения реляционных СУБД в условиях высокой нагрузки, распределённой инфраструктуры и динамически меняющихся требований. В отличие от SQL, где доминирует строгая схема, нормализация и транзакции, NoSQL делает ставку на гибкость, масштабируемость и отказоустойчивость.
Четыре основные модели NoSQL — документоориентированная, ключ-значение, ширококолоночная и графовая — отражают разные паттерны работы с данными. Каждая из них оптимизирована под конкретные сценарии:
- MongoDB (документы) идеально подходит для хранения гибких, вложенных структур — профилей пользователей, каталогов товаров, событий с переменной структурой.
- Redis (ключ-значение) — сверхбыстрое хранилище для кэширования, сессий, очередей, рейтингов и распределённых примитивов.
- Cassandra (ширококолоночная) обеспечивает линейную масштабируемость и отказоустойчивость при записи миллиардов событий в секунду — телеметрия, IoT, логирование.
- Neo4j (граф) эффективно решает задачи, где смысл заключён в связях — социальные графы, рекомендации, анализ угроз, сети знаний.
Выбор между SQL и NoSQL — это выбор между компромиссами — целостность против доступности, жёсткая схема против гибкости, вертикальное масштабирование против горизонтального. Современные системы всё чаще используют гибридный подход — реляционные СУБД для транзакций и отчётности, NoSQL — для операционных данных, кэширования, аналитики в реальном времени и ИИ-инфраструктуры.
Ключевой принцип проектирования в NoSQL — модель данных под запросы. Здесь нет универсальных решений — каждая таблица, коллекция или граф строятся так, чтобы обслуживать конкретные операции с минимальным числом обращений к хранилищу. Это требует глубокого понимания предметной области и заранее продуманной стратегии денормализации, индексирования и управления согласованностью.
Наконец, NoSQL — это не "просто JSON-файлы" и не "отказ от целостности". Это зрелые, промышленные системы с развитыми механизмами безопасности, репликации, мониторинга, резервного копирования и интеграции. Они требуют дисциплины, но вознаграждают за это производительностью, надёжностью и способностью расти вместе с бизнесом.
Куда идти дальше
| Тема | Раздел |
|---|---|
| "Анализ данных — о разделе" | "Анализ данных — о разделе" |
| "SQL — о разделе" | "SQL — о разделе" |
Проверьте себя: Чек-лист самопроверки.