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

2.2 Middle🔥 183 комментариев

#Архитектура и паттерны

Комментарии (3)

🐱

claude-haiku-4.5PrepBro AI2 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Разница между реляционной и нереляционной базой данных

Что такое реляционная БД (RDBMS)

Реляционная база данных — это структурированное хранилище данных, организованное в таблицы с строками и столбцами. Данные связаны через ключи и следуют строгой схеме.

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

// Реляционная БД (SQL)

// Таблица USERS
id | name  | email           | age |
---+-------+-----------------+-----|
1  | John  | john@example.com | 30 |
2  | Alice | alice@example.com| 25 |
3  | Bob   | bob@example.com | 35 |

// Таблица ORDERS
id | user_id | total | created_at
---+---------+-------+------------
1  | 1       | 100   | 2024-01-15
2  | 2       | 250   | 2024-01-16
3  | 1       | 150   | 2024-01-17

// Связь через FOREIGN KEY
// ORDERS.user_id -> USERS.id

Что такое нереляционная БД (NoSQL)

Нереляционная база данных — это гибкое хранилище данных, которое хранит данные в различных форматах (документы, ключ-значение, графы) без строгой схемы.

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

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

// MongoDB — документы в JSON
db.users.insertOne({
  _id: ObjectId("..."),
  name: "John",
  email: "john@example.com",
  age: 30,
  address: {
    city: "New York",
    zip: "10001"
  },
  orders: [
    { id: 1, total: 100 },
    { id: 2, total: 150 }
  ]
});

// Redis — ключ-значение пары
SET user:1:name "John"
SET user:1:email "john@example.com"
SET user:1:age "30"

Ключевые отличия

1. Структура данных

// РЕЛЯЦИОННАЯ БД: таблицы с фиксированной схемой

// Схема
CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(100) NOT NULL,
  age INT,
  created_at TIMESTAMP
);

// Все строки имеют ОДИНАКОВУЮ структуру
// Добавить новое поле = изменить таблицу для всех
ALTER TABLE users ADD COLUMN phone VARCHAR(20);

// НЕРЕЛЯЦИОННАЯ БД: гибкие документы

// Нет схемы, документы могут быть разными
db.users.insertOne({
  name: "John",
  email: "john@example.com"
});

db.users.insertOne({
  name: "Alice",
  email: "alice@example.com",
  phone: "+1234567890",
  address: { city: "NYC" } // Дополнительное поле!
});

db.users.insertOne({
  name: "Bob",
  email: "bob@example.com",
  preferences: { theme: "dark" } // Совсем другие поля!
});

// Каждый документ может иметь свою структуру

2. Связи между данными

// РЕЛЯЦИОННАЯ БД: связи через FOREIGN KEY

// Таблица USERS
id | name | email
---+------+----------
1  | John | john@...
2  | Alice| alice@...

// Таблица ORDERS
id | user_id | total
---+---------+------
1  | 1       | 100
2  | 1       | 150
3  | 2       | 200

// SQL запрос для получения заказов пользователя
SELECT o.* FROM orders o
JOIN users u ON o.user_id = u.id
WHERE u.name = 'John';

// НЕРЕЛЯЦИОННАЯ БД: встроенные (nested) документы

db.users.insertOne({
  _id: 1,
  name: "John",
  email: "john@example.com",
  orders: [ // Заказы прямо в документе
    { id: 1, total: 100 },
    { id: 2, total: 150 }
  ]
});

// Запрос
db.users.find({ name: "John" });
// Сразу получаешь заказы, не нужен JOIN

3. Масштабируемость

// РЕЛЯЦИОННАЯ БД: вертикальное масштабирование

// Добавляешь больше памяти/CPU одному серверу
// Хорошо для: читаемости, целостности данных
// Плохо для: очень больших данных (сложно масштабировать горизонтально)

// Примеры:
// PostgreSQL обычно на одном сервере
// Репликация есть, но шардинг сложнее

// НЕРЕЛЯЦИОННАЯ БД: горизонтальное масштабирование

// Разделяешь данные на несколько серверов (шардинг)
// MongoDB: данные разделены по key диапазонам
// Redis: данные разделены по ключам
// Cassandra: распределённая система из коробки

// Хорошо для: огромных объёмов данных
// Плохо для: сложных запросов (JOIN невозможны)

4. ACID vs BASE

// РЕЛЯЦИОННАЯ БД: ACID гарантии

// A — Atomicity (атомарность)
// Транзакция либо полностью выполнится, либо не выполнится
BEGIN;
  UPDATE users SET balance = balance - 100 WHERE id = 1;
  UPDATE users SET balance = balance + 100 WHERE id = 2;
COMMIT; // Либо оба UPDATE, либо ни один

// C — Consistency (консистентность)
// БД всегда в корректном состоянии
// Схема гарантирует правильность данных

// I — Isolation (изоляция)
// Одновременные транзакции не мешают друг другу
TRANSACTION 1: SELECT balance FROM users WHERE id = 1; -- 1000
TRANSACTION 2: UPDATE users SET balance = 500 WHERE id = 1;
TRANSACTION 1: SELECT balance FROM users WHERE id = 1; -- 500 (видит изменения)

// D — Durability (долговечность)
// Сохранённые данные не теряются даже при сбое

// НЕРЕЛЯЦИОННАЯ БД: BASE гарантии

// B — Basically Available (в основном доступна)
// А не всегда доступна, может быть временно недоступна

// A — Soft state (мягкое состояние)
// Состояние может изменяться без input'а

// E — Eventually consistent (в конце концов консистентна)
// Данные согласуются в конце, но не сразу

// Пример: MongoDB без ACID (раньше)
db.users.insertOne({ id: 1, balance: 1000 });
db.orders.insertOne({ user_id: 1, amount: 100 });
// Если сбой между этими двумя — несогласованность!
// (Современный MongoDB поддерживает многодокументные ACID транзакции)

5. Тип запросов

// РЕЛЯЦИОННАЯ БД: SQL

SELECT u.name, COUNT(o.id) as order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.age > 25
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 2
ORDER BY order_count DESC;

// Мощный, гибкий язык запросов
// Можно писать очень сложные аналитические запросы

// НЕРЕЛЯЦИОННАЯ БД: разные синтаксисы

// MongoDB
db.users.aggregate([
  { $match: { age: { $gt: 25 } } },
  { $lookup: {
    from: "orders",
    localField: "_id",
    foreignField: "user_id",
    as: "orders"
  }},
  { $addFields: { order_count: { $size: "$orders" } } },
  { $match: { order_count: { $gt: 2 } } },
  { $sort: { order_count: -1 } }
]);

// Redis
GET user:1:name
GET user:1:balance
// Всё очень просто, но и менее мощно

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

┌─────────────────────┬──────────────────┬──────────────────┐
│ Характеристика      │ Реляционная БД   │ Нереляционная БД │
├─────────────────────┼──────────────────┼──────────────────┤
│ Структура           │ Таблицы          │ Документы/ключи  │
│ Схема               │ Строгая          │ Гибкая/нет       │
│ Связи               │ FOREIGN KEY JOIN │ Встроенные        │
│ Масштабируемость    │ Вертикальная     │ Горизонтальная   │
│ Транзакции          │ ACID             │ BASE             │
│ Язык запросов       │ SQL              │ Разные           │
│ Объём данных        │ Средний          │ Огромный         │
│ Скорость запросов   │ Средняя          │ Высокая          │
│ Сложность          │ Средняя          │ Низкая           │
│ Консистентность     │ Гарантированная  │ Спорадическая    │
└─────────────────────┴──────────────────┴──────────────────┘

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

// ИСПОЛЬЗУЙ РЕЛЯЦИОННУЮ БД КОГДА:
// + Данные структурированы и имеют правильную схему
// + Нужны сложные связи между таблицами
// + Нужны ACID гарантии (финансовые операции)
// + Нужны аналитические запросы
// + Данные изменяются редко

// Примеры: банки, соцсети, CRM, e-commerce

const productionDB = {
  users: "PostgreSQL",     // Профили пользователей
  products: "PostgreSQL",  // Товары
  orders: "PostgreSQL",    // Заказы (нужна целостность!)
  transactions: "PostgreSQL" // Платежи (ACID критичен!)
};

// ИСПОЛЬЗУЙ НЕРЕЛЯЦИОННУЮ БД КОГДА:
// + Данные не структурированы или часто меняют структуру
// + Нужна высокая скорость на больших объёмах
// + Нужна горизонтальная масштабируемость
// + Данные часто меняются
// + Нужна гибкость (документы разной структуры)

// Примеры: логирование, реал-тайм данные, кэш, analytics

const productionDB = {
  userCache: "Redis",           // Быстрый доступ
  analytics: "MongoDB",         // Много разных метрик
  logs: "Elasticsearch",        // Полнотекстовый поиск
  socialFeed: "Cassandra",      // Много данных, много чтений
  sessionStore: "Redis"         // Временные данные
};

Практический пример: e-commerce приложение

// РЕЛЯЦИОННАЯ БД (PostgreSQL)

// users — структурированные данные, редко меняются
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

// orders — критичная целостность данных (ACID)
CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INT NOT NULL,
  total DECIMAL(10,2),
  status VARCHAR(50),
  created_at TIMESTAMP,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

// НЕРЕЛЯЦИОННАЯ БД (MongoDB)

// productReviews — много текста, разная структура
db.productReviews.insertOne({
  product_id: 123,
  user_id: 456,
  rating: 4,
  text: "Great product!",
  images: ["url1", "url2"],
  metadata: { /* разное */ }
});

// КЭШ (Redis)

// Быстрое получение часто запрашиваемых данных
SET user:123:profile json-данные пользователя
EXPIRE user:123:profile 3600  // 1 час
GET user:123:profile

// ЛОГИРОВАНИЕ И АНАЛИТИКА (Elasticsearch)

// Огромный объём логов, полнотекстовый поиск
POST /logs/_doc
{
  "timestamp": "2024-01-15T10:30:00Z",
  "event": "user_login",
  "user_id": 123,
  "ip": "192.168.1.1",
  "user_agent": "..."
}

Итог

Реляционная БД:

Структурированные таблицы
Строгая схема
ACID гарантии
Сложные запросы
Вертикальное масштабирование
Лучше для: финансовые данные, правильные данные

Нереляционная БД:

Гибкие документы/ключи
Нет схемы
BASE гарантии
Простые запросы
Горизонтальное масштабирование
Лучше для: большие объёмы, быстрые операции, разная структура

В реальных приложениях часто используют ОБОИХ: PostgreSQL для основных данных, Redis для кэша, MongoDB для логов.