MongoDB
Тема дорожной карты · Backend разработчик
MongoDB — документо-ориентированная NoSQL база данных, хранящая данные в виде гибких BSON-документов, что делает её популярным выбором для бэкенд-разработчиков, нуждающихся в схемно-гибком уровне данных для систем управления контентом, профилей пользователей, каталогов товаров и аналитики в реальном времени. Конвейер агрегации MongoDB, движок индексирования и нативная поддержка геопространственных запросов дают ей выразительные возможности запросов, превосходящие простые хранилища ключ-значение, тогда как горизонтальное масштабирование через встроенный шардинг и репликацию базы данных через replica sets обеспечивает высокую доступность «из коробки». Бэкенд-сервисы на Node.js, Python, Java или Go подключаются к MongoDB через официальные драйверы или Mongoose (Node.js ODM); управляемый сервис Atlas или самостоятельно развёртываемые Docker/Kubernetes-деплои оба поддерживают один и тот же API драйвера. MongoDB органично интегрируется с Elasticsearch для выгрузки полнотекстового поиска и с Apache Kafka через MongoDB Kafka Connector для событийно-ориентированных микросервисных архитектур. При проектировании с MongoDB важно понимать импликации теоремы CAP — replica sets MongoDB по умолчанию используют итоговую согласованность для вторичных чтений — и применять правильные стратегии индексирования во избежание полного сканирования коллекций в масштабе.
Как это работает
MongoDB покрывает document (MongoDB, CouchDB), key-value (Redis, DynamoDB, etcd), wide-column (Cassandra, HBase, ScyllaDB), graph (Neo4j, ArangoDB), search (Elasticsearch, OpenSearch). Каждая торгует ACID-гарантиями за конкретное свойство производительности или масштаба. Redis — универсальный швейцарский нож в памяти (кеш, очередь, pub/sub, distributed lock). Elasticsearch доминирует в full-text. MongoDB подходит для гибких JSON-данных, но требует дисциплины денормализации.
Когда применять
Redis — для кеша + rate limit + простых очередей: окупается в большинстве стеков. Elasticsearch / OpenSearch — когда нужен full-text за пределами LIKE %x%. MongoDB или DynamoDB — только если access-паттерн реально не ложится в реляционную модель (высокая частота записи на айтем, очень разнородные документы). Избегайте NoSQL "ради масштаба" до измерения боттлнека в Postgres — преждевременная оптимизация тут реальна.
Типичные ошибки
Ловушки MongoDB: MongoDB для реляционных данных ("гибкая схема" прячет связи — joins становятся application-side N+1); Redis как единственное durable-хранилище (это в основном память; persistence с оговорками); Elasticsearch как primary-БД (медленные апдейты, нет транзакций — индексируйте из Postgres); выбор NoSQL по хайпу, а не по read/write-паттернам. Определяйте запросы до хранилища.