Какие характеристики бывают у баз данных?

Характеристики баз данных

Базы данных имеют множество характеристик, которые определяют их пригодность для различных задач. Это могут быть структурные, функциональные и операционные характеристики.

ACID характеристики

Данные четыре свойства являются фундаментом надёжных баз данных:

Atomicity (Атомарность) — транзакция либо полностью выполнена, либо не выполнена вообще.

# Без атомарности
try:
    transfer_money(from_account=100, to_account=200, amount=1000)
except:
    # Деньги могут быть списаны со счёта 100
    # но не поступили на счёт 200 (потеря данных!)
    pass

# С ACID гарантией (транзакция)
with db.transaction():
    source.balance -= 1000
    target.balance += 1000
    # Либо оба изменения применены, либо оба откачены

Consistency (Согласованность) — данные всегда в валидном состоянии, все constraints соблюдены.

-- Constraint: balance не может быть отрицательным
ALTER TABLE accounts ADD CONSTRAINT check_balance CHECK (balance >= 0);

-- Попытка нарушить констрейнт будет отклонена
UPDATE accounts SET balance = -100 WHERE id = 1;  -- Error!

Isolation (Изоляция) — одновременные транзакции не влияют друг на друга.

# Уровни изоляции транзакций
# 1. READ UNCOMMITTED — можно прочитать не закомиченные изменения (dirty reads)
# 2. READ COMMITTED — можно прочитать только закомиченные данные
# 3. REPEATABLE READ — в пределах транзакции данные не меняются
# 4. SERIALIZABLE — транзакции выполняются как последовательно

# PostgreSQL
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
  -- Операции
COMMIT;

Durability (Долговечность) — закомиченные данные сохранены даже при сбое.

-- После COMMIT, данные гарантированно сохранены на диск
BEGIN;
  UPDATE users SET name = 'John' WHERE id = 1;
COMMIT;  -- После этого данные в безопасности

-- Даже если сервер упадёт в следующую миллисекунду
-- данные восстановятся при перезагрузке

CAP Теорема

Нелюбая распределённая база данных не может одновременно гарантировать все три свойства:

C — Consistency (Согласованность)

• Все узлы видят одинаковые данные
• Пример: PostgreSQL с синхронной репликацией

A — Availability (Доступность)

• Система всегда доступна для чтения и записи
• Пример: Redis, Cassandra

P — Partition Tolerance (Устойчивость к разделению сети)

• Система работает при разделении сети между узлами
• Пример: любая распределённая система

       /- CA: PostgreSQL (single node)
CAP -<- CP: HBase, MongoDB (consistency over availability)
       \- AP: Cassandra, DynamoDB (availability over consistency)

SCALABILITY (Масштабируемость)

Vertical Scaling (вертикальное масштабирование)

• Добавить больше мощности одному серверу
• Простая в реализации, но есть аппаратные лимиты

# До
server_config = {
    'CPU': 4,
    'RAM': 16,
    'storage': 1
}

# После
server_config = {
    'CPU': 32,
    'RAM': 256,
    'storage': 10
}

Horizontal Scaling (горизонтальное масштабирование)

• Добавить больше серверов
• Сложнее, но неограниченная масштабируемость

# Распределение данных
servers = [
    'db1.example.com',  # Данные 0-25%
    'db2.example.com',  # Данные 25-50%
    'db3.example.com',  # Данные 50-75%
    'db4.example.com',  # Данные 75-100%
]

def get_server_for_user(user_id):
    hash_value = hash(user_id) % len(servers)
    return servers[hash_value]

PERFORMANCE (Производительность)

Throughput (Пропускная способность) — количество операций в секунду (QPS)

MySQL: 1,000-10,000 QPS
PostgreSQL: 5,000-50,000 QPS
Redis: 100,000-1,000,000 QPS (in-memory)
Cassandra: 100,000+ QPS (distributed)

Latency (Задержка) — время ответа на один запрос

import time

start = time.time()
result = db.query("SELECT * FROM users WHERE id = 1")
latency = (time.time() - start) * 1000  # в миллисекундах

print(f"Задержка: {latency:.2f}ms")

# Типичные значения
# SSD: 1-10ms
# HDD: 10-100ms
# Сетевая задержка: 0.5-100ms

RELIABILITY (Надёжность)

Availability (Доступность) — процент времени, когда система работает

99.9% (three nines): 8.76 часов простоя в год
99.99% (four nines): 52.6 минут простоя в год
99.999% (five nines): 5.26 минут простоя в год (требует очень больших инвестиций)

Backup & Recovery (Резервная копия и восстановление)

-- PostgreSQL
-- Полная резервная копия
pg_dump database > backup.sql

-- Восстановление
psql database < backup.sql

-- Инкрементальная резервная копия (WAL archiving)
archive_mode = on
wal_level = replica

SCHEMA FLEXIBILITY (Гибкость схемы)

Schema-full (Строгая схема) — требуется заранее определить структуру

-- Реляционные БД: MySQL, PostgreSQL
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE,
    created_at TIMESTAMP DEFAULT NOW()
);

-- Строго: нельзя добавить строку без email без изменения схемы

Schema-less (Гибкая схема) — можно хранить любую структуру

# MongoDB
db.users.insert_one({
    'name': 'John',
    'email': 'john@example.com',
    'preferences': {'theme': 'dark', 'notifications': True},
    'extra_field': 'can be anything'
})

db.users.insert_one({
    'name': 'Jane',
    'phone': '+1234567890'  # Нет email, но это OK
})

DATA MODEL (Модель данных)

Relational (Реляционная) — таблицы с связями

SELECT u.name, COUNT(p.id) as posts
FROM users u
LEFT JOIN posts p ON u.id = p.user_id
GROUP BY u.id, u.name;

Document-oriented (Документоориентированная) — иерархические документы

# MongoDB
user = {
    '_id': 1,
    'name': 'John',
    'posts': [
        {'title': 'Post 1', 'content': '...'},
        {'title': 'Post 2', 'content': '...'}
    ]
}

Key-Value (Ключ-значение) — простые пары

# Redis
db.set('user:1:name', 'John')
db.set('user:1:email', 'john@example.com')
db.get('user:1:name')  # 'John'

Graph (Графовая) — узлы и связи

# Neo4j
CREATE (john:User {name: 'John'})
CREATE (jane:User {name: 'Jane'})
CREATE (john)-[:FOLLOWS]->(jane)
MATCH (u:User)-[:FOLLOWS]->(f:User) RETURN u, f

INDEXING (Индексирование)

-- B-tree индекс (стандартный)
CREATE INDEX idx_email ON users(email);

-- Составной индекс
CREATE INDEX idx_name_email ON users(last_name, first_name);

-- Полнотекстовый индекс
CREATE FULLTEXT INDEX idx_content ON articles(content);

-- GiST индекс для геопространственных данных
CREATE INDEX idx_location ON users USING GIST(location);

TRANSACTION SUPPORT (Поддержка транзакций)

# ACID транзакции
with db.transaction():
    user = db.users.get(id=1)
    user.balance -= 100
    other_user = db.users.get(id=2)
    other_user.balance += 100
    # Атомарно: либо оба изменения, либо ни одного

# NoSQL часто не поддерживают полные ACID
# Но MongoDB 4.0+ поддерживает мульти-документные транзакции

SUMMARY TABLE (Сравнение БД по характеристикам)

Выбор базы данных зависит от приоритизации этих характеристик под конкретную задачу.