NoSQL базы данных
Тема дорожной карты · Backend разработчик
NoSQL базы данных — широкое семейство хранилищ данных, выходящих за рамки жёсткой табличной модели реляционных баз данных в пользу документальных, ключ-значение, ширококолоночных и графовых моделей данных, каждая из которых оптимизирована для различных паттернов доступа и требований к масштабируемости. Документальные базы данных MongoDB и CouchDB хранят JSON-подобные BSON-документы, запрашиваемые с помощью богатых операторов фильтрации (db.collection.find({ status: 'active' })), что делает их популярными для систем управления контентом, профилей пользователей и каталогов товаров со схемами, часто меняющимися со временем. Хранилища ключ-значение — Redis для кеширования в памяти и pub/sub, Amazon DynamoDB для serverless масштабируемого хранения — обеспечивают наибольшую пропускную способность с O(1) поиском по первичному ключу. Ширококолоночные хранилища Apache Cassandra и HBase работают с данными временных рядов и IoT-данными в петабайтном масштабе через интерфейс CQL (Cassandra Query Language), предлагая настраиваемую согласованность через параметр CONSISTENCY QUORUM. NoSQL базы данных жертвуют частью гарантий ACID (большинство предлагают итоговую согласованность) в обмен на горизонтальный шардинг и устойчивость к разделению; для случаев, требующих строгих транзакций между документами, многодокументные ACID-транзакции MongoDB 4.x и транзакции DynamoDB обеспечивают промежуточный вариант без необходимости мигрировать на PostgreSQL или MySQL.
Как это работает
NoSQL базы данных покрывает 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 — преждевременная оптимизация тут реальна.
Типичные ошибки
Ловушки NoSQL базы данных: MongoDB для реляционных данных ("гибкая схема" прячет связи — joins становятся application-side N+1); Redis как единственное durable-хранилище (это в основном память; persistence с оговорками); Elasticsearch как primary-БД (медленные апдейты, нет транзакций — индексируйте из Postgres); выбор NoSQL по хайпу, а не по read/write-паттернам. Определяйте запросы до хранилища.