Что такое NoSQL?

NoSQL: Нереляционные базы данных

NoSQL ("Not Only SQL") — это категория баз данных, которые отступают от традиционной реляционной модели (таблицы, строки, колонки, SQL-запросы). Вместо этого они используют различные модели хранения данных, оптимизированные для конкретных сценариев.

Отличие от SQL

SQL (реляционные БД):

• Данные в таблицах с фиксированной схемой
• Строки связаны через foreign keys
• Транзакции ACID (Atomicity, Consistency, Isolation, Durability)
• Нормализация данных
• Универсальность (подходят для большинства задач)

NoSQL (нереляционные БД):

• Гибкая или динамическая схема
• Горизонтальная масштабируемость (sharding)
• Часто слабые транзакции (BASE: Basically Available, Soft state, Eventual consistency)
• Денормализация для быстрого доступа
• Специализация под конкретные паттерны

Основные типы NoSQL

1. Document-oriented (документные БД)

Хранят полусструктурированные данные (JSON, BSON).

MongoDB, CouchDB, Firebase — примеры инструментов.

Плюсы:

• Гибкость схемы (разные документы могут иметь разные поля)
• Встроенные подструктуры (не нужны join'ы)
• Естественно подходят для веб-приложений

Минусы:

• Сложнее выполнять сложные join'ы
• Дублирование данных

Применение: CMS, e-commerce, user profiles, content management

2. Key-Value (ключ-значение)

Наиболее простая структура: ключ связывается со значением.

Redis, Memcached, DynamoDB — популярные примеры.

Плюсы:

• Экстремально быстро (часто in-memory)
• Простая архитектура
• Отличный кэш для данных

Минусы:

• Нельзя запрашивать по значениям (только по ключам)
• Ограниченные возможности выборки

Применение: кэширование, сессии, real-time analytics, leaderboards

3. Column-family (столбцовые)

Данные организованы по столбцам, не по строкам.

HBase, Cassandra, ClickHouse — столбцовые хранилища.

Плюсы:

• Очень хороши для аналитики (агрегация по столбцам)
• Компрессия (похожие значения в столбце)
• Масштабируемость на петабайты

Минусы:

• Сложнее для CRUD операций
• Обычно read-only после загрузки

Применение: OLAP, time-series data, аналитические хранилища, логирование

4. Graph (графовые)

Данные представлены как граф (узлы и рёбра).

Neo4j, ArangoDB — графовые базы.

Плюсы:

• Наложение дорогих запросов (друзья друзей)
• Быстрые traversal'ы по отношениям

Минусы:

• Специализированность (не универсальны)
• Сложнее в разработке и изучении

Применение: social networks, recommendation engines, knowledge graphs

5. Search-oriented (поисковые)

Оптимизированы для полнотекстового поиска и фасетирования.

Elasticsearch, Solr, Algolia — поисковые индексы.

Плюсы:

• Быстрый полнотекстовый поиск
• Морфология и анализ текста
• Фасеты и фильтры

Минусы:

• Не подходят как primary store
• Требуют sync с основной БД

Применение: search, log analysis, analytics

Когда использовать NoSQL

Основные сценарии:

• Большие объёмы данных — когда реляционная БД не масштабируется
• Высокая скорость записи — IoT, real-time events
• Гибкая схема — быстро меняющиеся требования
• Горизонтальная масштабируемость — распределённые системы
• Специализированные задачи — полнотекстовый поиск, графы
• Высокая доступность — когда консистентность менее критична

Когда остаться на SQL

Оставайся с реляционными БД, если нужно:

• Сложные транзакции — ACID требуется
• Много связей между данными — графы отношений
• Ad-hoc запросы — SQL очень гибкий
• Compliance — финансы, медицина требуют строгих гарантий
• Маленький датасет — SQL проще в операционировании

CAP Theorem

Consistency, Availability, Partition tolerance — выбери два из трёх.

Большинство NoSQL выбирают Availability + Partition tolerance (AP), жертвуя сильной консистентностью:

• Eventual consistency — данные синхронизируются через время
• Strong consistency — дороже, требует координации

Практический пример: выбор БД для социальной сети

• MongoDB — user profiles, posts (гибкая схема, документы)
• Redis — кэш, сессии, счётчики (быстро меняющиеся данные)
• Neo4j — граф дружеских отношений (рекомендации)
• Elasticsearch — поиск постов и пользователей
• PostgreSQL — платежи, финансы (нужна ACID)

Нет универсального решения — BA должен понимать trade-offs каждой БД и выбирать правильный инструмент под задачу.