Чем отличается SQL от NoSQL баз данных? Когда лучше использовать каждый тип?

SQL vs NoSQL базы данных

Выбор между SQL и NoSQL — это критическое архитектурное решение, влияющее на производительность, масштабируемость, консистентность и способность системы справляться с растущими требованиями. Это не вопрос что лучше, а что оптимально для данного сценария.

SQL (Relational) базы данных

Определение

SQL базы данных (реляционные) хранят данные в структурированных таблицах с предопределённой схемой, связях между таблицами и строгих правилах консистентности (ACID).

Основные характеристики

Структурированные данные — фиксированная схема

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE,
    age INT CHECK (age >= 0)
);

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;
-- Либо оба UPDATE выполнены, либо оба откачены

Связи и нормализация — таблицы связаны

CREATE TABLE orders (
    id INT PRIMARY KEY,
    user_id INT FOREIGN KEY REFERENCES users(id),
    amount DECIMAL(10,2)
);

Мощные запросы — сложные SELECT с JOIN

SELECT u.name, COUNT(o.id) as order_count, SUM(o.amount) as total
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id
HAVING COUNT(o.id) > 5
ORDER BY total DESC;

Примеры SQL БД

• PostgreSQL (самая powerful)
• MySQL (популярная)
• Oracle
• Microsoft SQL Server

Плюсы SQL

Консистентность — ACID гарантии

• Данные всегда корректны
• Нет inconsistencies
• Идеально для финансовых операций

Мощные queries — можем делать complex операции

• JOINs
• Aggregations
• Subqueries
• Window functions
• Аналитика без доп систем

Нормализация — минимизируем дубликацию

• Изменяем данные в одном месте
• Нет redundancy
• Экономия storage

Гибкость — можем запрашивать по-разному

• Одна таблица, много способов запроса
• Не нужно предопределять access patterns
• Эффективна для exploratory queries

Экосистема — зрелые tools и practices

• 40+ лет истории
• Много tools для backup, replication, monitoring
• Developers знают SQL

Структура помогает — schema enforces quality

• Гарантирует правильность данных
• Типы fields enforced
• Constraints enforced

Минусы SQL

Масштабируемость — сложно масштабировать horizontally

• Легко масштабировать вертикально (большая machine)
• Горизонтальное масштабирование (sharding) очень сложно
• Распределённые транзакции очень сложны

Verticle scaling (легко):
┌─────────────────────┐
│  PostgreSQL server  │ 16GB RAM → 32GB RAM → 64GB RAM
└─────────────────────┘

Horizontal scaling (сложно):
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│   Shard 1    │  │   Shard 2    │  │   Shard 3    │
│ (users 0-33%)│  │(users 33-66%)│  │(users 66-100%)│
└──────────────┘  └──────────────┘  └──────────────┘
Сложная логика для routing, consistency, transactions

Гибкость схемы — сложнее менять схему

• ALTER TABLE на большой таблице может заблокировать
• Миграции требуют planning
• Downtime возможен

Не подходит для unstructured — требует schema

• JSON хранить можно (в некоторых БД), но не ideal
• Иерархические данные громоздко
• Полнотекстовый поиск требует доп инструментов (ElasticSearch)

Зависимости между таблицами — сложность растёт

• Много JOINs = медленные queries
• N+1 problem
• Требует оптимизации

Стоимость — лицензии дорогие

• PostgreSQL бесплатная
• MySQL бесплатная
• Oracle дорогая
• SQL Server дорогая

NoSQL (Non-Relational) базы данных

Определение

NoSQL базы данных хранят данные в гибких форматах (документы, key-value, графы, временные ряды) без предопределённой схемы, обычно с eventual consistency вместо ACID.

Типы NoSQL

1. Document NoSQL (MongoDB, CouchDB, Firebase)

// Структура как JSON
{
  "_id": "user123",
  "name": "John",
  "email": "john@example.com",
  "orders": [
    { "id": "order1", "amount": 100 },
    { "id": "order2", "amount": 50 }
  ],
  "profile": {
    "age": 30,
    "city": "NYC"
  }
}

2. Key-Value NoSQL (Redis, Memcached, DynamoDB)

User:123 → {name: "John", email: "john@example.com"}
Order:456 → {user_id: 123, amount: 100}

3. Graph NoSQL (Neo4j)

User ──[PLACED]──> Order
 User ──[KNOWS]──> User
 Order ──[CONTAINS]──> Product

4. Time-Series NoSQL (InfluxDB, Prometheus)

metric: cpu_usage
timestamp: 2024-01-15 10:00:00
value: 78.5
tags: server=server1, region=us-east

Примеры NoSQL БД

• Document: MongoDB, Firebase, Couchbase
• Key-Value: Redis, Memcached, AWS DynamoDB
• Graph: Neo4j
• Time-Series: InfluxDB, Prometheus
• Search: Elasticsearch, Solr

Плюсы NoSQL

Горизонтальная масштабируемость — можем распределить

MongoDB Sharding:
┌────────────────┐  ┌────────────────┐  ┌────────────────┐
│   Shard 1      │  │   Shard 2      │  │   Shard 3      │
│ users A-H      │  │ users I-P      │  │ users Q-Z      │
└────────────────┘  └────────────────┘  └────────────────┘
      ↓                    ↓                    ↓
  Easy write              Easy write          Easy write
  distributed             distributed         distributed

Гибкая схема — no schema enforcement

• Документы могут различаться
• Легко добавить новое поле
• Не нужна миграция
• Zero downtime updates

// v1
{"_id": 1, "name": "John"}

// v2 (без миграции!)
{"_id": 2, "name": "Jane", "email": "jane@example.com"}

// Оба документа в одной collection, без миграции

Быстрые writes — нет сложных transact консистентности

• Write может быть очень быстрым
• Не нужно ждать консистентности
• Отлично для high-write workloads

Хорошо для big data — распределённые по дизайну

• Построены для масштабирования
• Hadoop compatible
• Streaming data friendly

Структуры соответствуют код — JSON match JavaScript

• Natural mapping между code objects и БД
• Меньше boilerplate
• Developer friendly

Специализированные возможности — оптимизированы

• Full-text search (Elasticsearch)
• Graph traversal (Neo4j)
• Time-series queries (InfluxDB)
• Real-time analytics

Минусы NoSQL

Eventual consistency — данные не всегда консистентны

• Распределённая система
• Когда узел упадёт, другие узлы имеют старые данные
• Временное окно inconsistency

MongoDb write:
Writing node writes → Replicates to other nodes
Before replication completes, you can read old value

Сложные queries — нет JOINs

• Аналитика сложнее
• Нужно denormalize
• Application-level joins
• Более медленные complex operations

Дублирование данных — denormalization

• Одно и то же данные может быть в разных документах
• Update требует update всех copies
• Risk of inconsistency

Нет transactions (или limited)

• Сложно обеспечить atomic operations
• Нет multi-document ACID (в некоторых БД есть, но ограниченно)
• Compensation logic нужна на приложении

# SQL: Atomic
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  # Всё or nothing

# NoSQL: Может быть несинхронный
db.accounts.update({id: 1}, {$inc: {balance: -100}})  # Success
# Если следующее упадёт, первое уже выполнилось!
db.accounts.update({id: 2}, {$inc: {balance: 100}})   # Fails

Экосистема меньше — не столько tools

• Меньше third-party integrations
• Меньше опыта в industry
• Требует специального знания каждой БД

Неоптимально для queries — нужно denormalize

• Если нужны complex queries, нужна optimization
• Может потребоваться ElasticSearch для search
• Multi-system architecture

SQL vs NoSQL таблица

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

✓ Структурированные данные — чётко определённый schema ✓ Реляционные данные — много связей между таблицами ✓ ACID критична — финансовые операции ✓ Complex queries — нужны JOINs и aggregations ✓ Data integrity — важна консистентность ✓ Exploratory queries — нужна гибкость запросов ✓ Transactions — multi-step atomic operations ✓ Analytics — сложная аналитика ✓ Бизнес-системы — ERP, CRM, Accounting ✓ Regulated — HIPAA, PCI, где нужна audit trail

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

✓ Неструктурированные данные — JSON, documents ✓ Высокая нагрузка — millions queries/sec ✓ Horizontal scaling — нужна масштабируемость ✓ Big data — petabytes of data ✓ Real-time — fast writes and reads ✓ Schema evolution — часто меняется структура ✓ Flexible queries — нет predefined access patterns ✓ Content storage — documents, media ✓ User profiles — много полей, varied structure ✓ Caching — session storage, cache layer ✓ Search — full-text search (Elasticsearch) ✓ Time-series — metrics, logs (InfluxDB) ✓ Graph — социальные сети (Neo4j)

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

Использование разных БД для разных задач — это норма в современных системах

Смешанная архитектура:

PostgreSQL (ACID для orders)
      ↓
Elasticsearch (full-text search по products)
      ↓
MongoDB (flexible documents для user profiles)
      ↓
Redis (caching and sessions)
      ↓
InfluxDB (time-series metrics)
      ↓
Neo4j (graph for recommendations)

Примеры:

1. Финансовые операции → PostgreSQL (ACID)
2. User profiles → MongoDB (flexible)
3. Product search → Elasticsearch (full-text)
4. Analytics → InfluxDB (time-series)
5. Cache → Redis (fast)
6. Recommendations → Neo4j (graph)

Современный тренд: NewSQL

NewSQL databases — комбинируют SQL + NoSQL

• CockroachDB — distributed SQL
• Google Spanner — global SQL
• Cassandra — distributed SQL-like

Они дают ACID и horizontal scaling (чего раньше не было).

Вывод

SQL: Power, consistency, proven. Для большинства business applications.

NoSQL: Scale, flexibility, speed. Для big data и high-throughput.

Reality: Используйте обе. SQL для основного data store, NoSQL для специальных cases.

Системный аналитик должен выбирать БД на основе requirements, не идеологии.