В чем разница между реляционными и нереляционными БД?

Реляционные vs Нереляционные базы данных

Это принципиально разные подходы к хранению и управлению данными. Выбор между ними зависит от характера данных, масштаба и требований к производительности.

Реляционные БД (RDBMS)

Примеры: PostgreSQL, MySQL, Oracle, SQL Server, MariaDB

Характеристики

1. Структурированные данные Данные организованы в таблицы с заранее определённой схемой (columns, types).

CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(100) UNIQUE,
  created_at TIMESTAMP,
  role_id INT FOREIGN KEY
);

2. ACID гарантии

• Atomicity: транзакция либо полностью выполняется, либо откатывается
• Consistency: данные всегда в корректном состоянии
• Isolation: транзакции не влияют друг на друга
• Durability: сохранённые данные не теряются

BEGIN TRANSACTION
  UPDATE accounts SET balance = balance - 100 WHERE id = 1
  UPDATE accounts SET balance = balance + 100 WHERE id = 2
COMMIT -- обе операции либо выполнены, либо откачены

3. Связи между таблицами Данные в разных таблицах связаны через foreign keys (referential integrity).

CREATE TABLE orders (
  id INT PRIMARY KEY,
  user_id INT FOREIGN KEY REFERENCES users(id) ON DELETE CASCADE,
  total DECIMAL(10, 2)
);

4. Нормализация Данные разбиваются по таблицам, чтобы избежать дублирования (1NF, 2NF, 3NF).

❌ Денормализовано (дублирование):
users: id, name, department_name, department_budget

✅ Нормализовано (без дублирования):
users: id, name, department_id
departments: id, name, budget

5. SQL запросы Полнофункциональный язык для сложных запросов с JOIN, GROUP BY и т.д.

SELECT u.name, COUNT(o.id) as order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.created_at > '2025-01-01'
GROUP BY u.id
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC;

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

✅ Финансовые системы (банки, платежи) — нужны ACID гарантии ✅ ERP/CRM — структурированные данные с связями ✅ Административные системы — зарплата, учёт, отчёты ✅ Системы с изменяющимися данными — транзакции, аудит

Минусы

❌ Масштабирование — горизонтальное масштабирование сложное ❌ Гибкость схемы — изменение структуры требует миграции ❌ Производительность при big data — медленные на terrabyte-scale ❌ Несоответствие объектам — нужно "flattenить" объекты в таблицы

---

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

Примеры: MongoDB, Redis, Cassandra, DynamoDB, Elasticsearch

Характеристики

1. Слабо структурированные данные Данные хранятся как документы, графы, key-value без фиксированной схемы.

// MongoDB - документ может иметь разные поля
db.users.insertOne({
  _id: ObjectId("507f1f77bcf86cd799439011"),
  name: "John",
  email: "john@example.com",
  tags: ["vip", "early-adopter"],
  metadata: {
    lastLogin: ISODate("2025-03-28"),
    loginCount: 42
  }
  // Другие документы могут иметь другие поля
});

2. BASE вместо ACID

• Basically Available: система доступна
• Soft state: состояние может изменяться без input
• Eventual Consistency: консистентность в конечном итоге

Записываем в node1, читаем из node2:
- Может быть небольшая задержка (eventual consistency)
- Но система остаётся доступной (trade-off)

3. Горизонтальное масштабирование Данные распределяются на несколько серверов (sharding).

Nodes:
- Node1: users a-m
- Node2: users n-z
- Node3: backup

Применение запроса к нескольким nodes в параллель

4. Разные типы хранения

Document store (MongoDB)

db.posts.find({author: "John", likes: {$gt: 100}})

Key-Value store (Redis)

SET user:123 '{"name": "John", ...}'
GET user:123

Graph DB (Neo4j)

MATCH (a:Person)-[:KNOWS]->(b:Person)
WHERE a.name = "John"
RETURN b.name

Time Series (InfluxDB)

INSERT cpu_usage,host=server1,region=us-east value=42.5 1609459200000000000

5. Гибкость схемы Можно добавить новые поля без migration.

// Старый документ
{_id: 1, name: "John", email: "john@example.com"}

// Новый документ с дополнительным полем
{_id: 2, name: "Jane", email: "jane@example.com", phone: "+1234567890"}

// Обе версии сосуществуют в одной коллекции

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

✅ Big Data / Analytics — Elasticsearch, Cassandra для миллиардов записей ✅ Real-time приложения — Redis для кэша, сессий, leaderboards ✅ Nested/Hierarchical данные — MongoDB для объектов с вложением ✅ Быстро изменяющиеся схемы — startups, прототипирование ✅ Социальные сети — граф-ориентированные запросы ✅ Кэширование и сессии — Redis, Memcached

Минусы

❌ Отсутствие ACID — возможны данные в несогласованном состоянии ❌ Дублирование данных — разные коллекции могут хранить одно и то же ❌ Сложные JOIN-подобные операции — нужна денормализация ❌ Отсутствие referential integrity — no foreign keys

---

Сравнительная таблица

---

Гибридный подход (Polyglot Persistence)

В современных системах часто используют обе БД:

Архитектура:
- PostgreSQL: учётные записи, финансовые транзакции (ACID)
- MongoDB: профили пользователей, контент (гибкость)
- Redis: кэш, сессии, счётчики (скорость)
- Elasticsearch: поиск и аналитика (индексирование)

Пример проекта:

1. User регистрируется
   → Сохраняем в PostgreSQL (ACID)
   
2. User добавляет товары в корзину
   → Redis для быстроты
   
3. User ищет товары
   → Elasticsearch для full-text search
   
4. Профиль пользователя (любые поля)
   → MongoDB для гибкости

Рекомендации

PostgreSQL, если:

• Нужна надёжность (финансы, критичные операции)
• Сложные запросы (reporting, analytics)
• Структурированные данные

MongoDB/NoSQL, если:

• Высокий throughput (миллионы запросов)
• Неопределённая схема
• Горизонтальное масштабирование критично
• Nested/иерархические данные

Redis, если:

• Кэш, сессии, счётчики
• Очень низкая latency (<1ms)

Заключение

Нет "лучшей" БД. Выбор зависит от задачи:

• Финансы → RDBMS
• Социальная сеть → Graph + NoSQL
• Analytics → Data warehouse + OLAP
• Кэш → Redis
• Полнотекстовый поиск → Elasticsearch