Базы данных
NoSQL: документы, ключ-значение, колонки, графы
В 2004 году Google опубликовала статью о Bigtable - column-family БД для индексирования веба. В 2007 Amazon опубликовала Dynamo - KV store для корзины покупок. Эти две статьи запустили революцию NoSQL. Сегодня без знания NoSQL невозможно проектировать системы уровня Uber или Netflix.
- **Netflix**: Cassandra для хранения пользовательских данных и истории просмотров - 36 петабайт, 99.99% availability
- **Discord**: перешёл с Cassandra на ScyllaDB (совместимая column-family) для хранения 4 триллионов сообщений при меньших затратах
- **LinkedIn**: Neo4j-подобный граф для 'People You May Know' - анализирует связи 900 млн пользователей в реальном времени
Четыре семейства NoSQL
NoSQL - не один тип БД, а целое семейство с разными trade-offs. Объединяет их одно: отказ от жёсткой реляционной схемы и SQL как единственного интерфейса. Появились из-за конкретных болей: Twitter не мог масштабировать MySQL горизонтально, Amazon хотел предсказуемый latency при любой нагрузке.
| Тип | Модель данных | Примеры | Сильная сторона |
|---|---|---|---|
| Document | JSON/BSON документы | MongoDB, CouchDB | Гибкая схема, вложенные объекты |
| Key-Value | Пары ключ-значение | Redis, DynamoDB | O(1) lookup, горизонтальный шардинг |
| Column-family | Строки + колоночные семейства | Cassandra, HBase | Write-heavy, time-series, аналитика |
| Graph | Узлы + рёбра | Neo4j, Amazon Neptune | Связи между сущностями, рекомендации |
В 2020 году Stack Overflow провёл опрос: 64% компаний используют более одной БД в продакшне (polyglot persistence). PostgreSQL для транзакций, Redis для кешa, Elasticsearch для поиска - типичный стек современного SaaS.
Instagram хранит граф подписок (кто на кого подписан) для 2 миллиардов пользователей. Какой тип NoSQL наиболее подходит?
Document Stores
Document store хранит данные как самодостаточные документы (JSON, BSON, XML). Каждый документ описывает сущность полностью - нет нужды в JOIN. Airbnb хранит листинг апартаментов как один документ: название, описание, фотографии, правила, цены по датам, отзывы - всё в одном месте.
Недостаток document store: денормализация. Если имя хоста изменилось, нужно обновить тысячи документов. MongoDB решает через references (как FK в SQL), но тогда нужны два запроса. Trade-off: скорость чтения vs. простота обновления.
Когда document store НЕ подходит?
Key-Value Stores
Key-value store - простейшая модель: словарь с O(1) get/set. Каждая операция предсказуемо быстрая независимо от размера данных. Amazon DynamoDB гарантирует single-digit milliseconds latency при любой нагрузке - это невозможно с SQL из-за locks и planning.
Redis - самый популярный in-memory KV. Twitter использует Redis для хранения 400 млрд твитов в timeline кешe. Когда ты открываешь Twitter, твой фид уже предварительно собран и лежит в Redis как list - чтение занимает <1ms.
Ограничение KV: нет возможности искать по значению. Можно найти сессию по session_id, но нельзя найти все сессии пользователя без дополнительного индекса. Redis решает через secondary index паттерн: отдельный SET `user_sessions:{user_id}` -> список session_id.
Какой запрос невозможен в чистом key-value store без дополнительных структур?
Column-Family Stores
Column-family store (wide-column) расширяет KV двумя измерениями: row key + column key -> value. В отличие от SQL, каждая строка может иметь разные колонки. Cassandra хранит данные отсортированными по column key - это делает range queries по времени мгновенными.
Apple iCloud хранит данные 782 млн устройств в Cassandra. При записи данных с устройства (контакты, заметки, фото metadata) Cassandra принимает запись мгновенно - write path оптимизирован через LSM-tree. Читается всё по user_id + timestamp.
Cassandra оптимизирована для write-heavy нагрузки. Какая структура данных обеспечивает быстрые записи?
Graph Databases
Graph database хранит данные как узлы (nodes) и рёбра (edges) с атрибутами. Оптимизированы для traversal - обхода связей. В реляционной БД найти 'друзей друзей пользователя' требует N JOIN-ов. В Neo4j - один Cypher запрос, выполняется за миллисекунды независимо от глубины графа.
Где graph DB реально используется: PayPal использует Neo4j для fraud detection - находит подозрительные паттерны в сети транзакций за реальное время. NASA - для управления зависимостями между компонентами миссий. eBay - для knowledge graph товаров.
NoSQL быстрее SQL - это и есть причина его использовать
NoSQL быстрее только для специфических access patterns. MongoDB медленнее PostgreSQL для complex joins. Redis быстрее любой БД, но только для простых операций в памяти.
Скорость NoSQL достигается за счёт упрощений: нет транзакций, нет joins, нет гарантий консистентности. Это trade-off, а не бесплатный обед. Выбор БД должен основываться на access patterns, а не мифах о скорости.
Какой запрос graph database выполняет эффективнее реляционной БД?
Ключевые идеи
- **Document store** (MongoDB): гибкая схема, вложенные объекты, идеально для контента с непредсказуемой структурой
- **Key-value** (Redis, DynamoDB): O(1) операции, горизонтальный шардинг, предсказуемый latency - основа кеширования и сессий
- **Column-family** (Cassandra): write-heavy через LSM-tree, range queries по времени, масштаб петабайт
- **Graph** (Neo4j): traversal по связям за O(depth), fraud detection, рекомендации, knowledge graphs
Связанные темы
NoSQL - семейство решений, каждое из которых раскрыто в отдельном уроке:
Вопросы для размышления
- Приложение для доставки еды (как Delivery Club) имеет: рестораны, меню, заказы, статусы, пользователей. Какие данные хранить в SQL, какие в NoSQL?
- Почему polyglot persistence (несколько разных БД) стало нормой, а не аномалией?
- CAP теорема говорит, что нельзя иметь Consistency, Availability и Partition tolerance одновременно. Как каждый тип NoSQL делает этот выбор?