Какие знаешь способы масштабирования реляционных баз данных?

Масштабирование реляционных баз данных

Масштабирование БД — критическая задача при растущем объёме данных и пользователей. Рассмотрю основные стратегии масштабирования реляционных БД.

Вертикальное масштабирование (Scale Up)

Увеличение ресурсов одного сервера БД (CPU, RAM, SSD):

# Это решается на уровне инфраструктуры, но влияет на код
# Например, увеличение connection pool при большем объёме памяти
from sqlalchemy import create_engine

engine = create_engine(
    'postgresql://user:pass@localhost/db',
    pool_size=50,  # увеличиваем пул соединений
    max_overflow=100,
    pool_timeout=30,
)

Плюсы:

• Простое решение, нет изменений в коде
• Нет необходимости в сложной синхронизации
• Шифрование и безопасность проще

Минусы:

• Есть потолок (максимальные характеристики серверов)
• Дороговато
• Single point of failure
• Время простоя при апгрейде

Горизонтальное масштабирование (Scale Out)

1. Репликация (Replication)

Дублирование данных на несколько серверов:

# Master-Slave репликация
# Написание на Master, чтение на Slave

from sqlalchemy import create_engine

# Для записи
master_engine = create_engine('postgresql://user:pass@master-db/db')

# Для чтения (load balancing между несколькими slave)
read_engines = [
    create_engine('postgresql://user:pass@slave1/db'),
    create_engine('postgresql://user:pass@slave2/db'),
    create_engine('postgresql://user:pass@slave3/db'),
]

import random

def get_read_engine():
    return random.choice(read_engines)

# Использование
with master_engine.connect() as conn:
    conn.execute('INSERT INTO users (name) VALUES (%s)', ('John',))

with get_read_engine().connect() as conn:
    result = conn.execute('SELECT * FROM users')

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

• Улучшает производительность чтения
• Высокая доступность (failover)
• Небольшая задержка репликации (lag)

2. Шардирование (Sharding)

Разделение данных между несколькими БД по ключу (hash, range, directory):

# Hash sharding по user_id
def get_shard_id(user_id, num_shards=4):
    return hash(user_id) % num_shards

shards = {
    0: create_engine('postgresql://user:pass@shard0/db'),
    1: create_engine('postgresql://user:pass@shard1/db'),
    2: create_engine('postgresql://user:pass@shard2/db'),
    3: create_engine('postgresql://user:pass@shard3/db'),
}

def get_user(user_id):
    shard_id = get_shard_id(user_id)
    engine = shards[shard_id]
    with engine.connect() as conn:
        return conn.execute(
            'SELECT * FROM users WHERE id = %s',
            (user_id,)
        ).fetchone()

# Range sharding по дате
def get_shard_by_date(date, date_ranges):
    for shard_id, (start, end) in enumerate(date_ranges):
        if start <= date < end:
            return shard_id
    raise ValueError('Date out of range')

Плюсы:

• Горизонтальное масштабирование
• Линейный рост производительности
• Распределённая нагрузка

Минусы:

• Сложная логика (cross-shard queries)
• Миграция при изменении числа шардов (resharding)
• Может быть дисбаланс данных

3. Партиционирование (Partitioning)

Разделение таблицы на физические части внутри одной БД:

# Range partitioning в PostgreSQL
# SQL миграция:
# CREATE TABLE orders_2024 PARTITION OF orders
#     FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

from sqlalchemy import create_engine, text

engine = create_engine('postgresql://user:pass@localhost/db')

# Автоматическое распределение по партициям
with engine.connect() as conn:
    conn.execute(text(
        'INSERT INTO orders (order_date, amount) VALUES (:date, :amount)',
        {"date": "2024-06-15", "amount": 100}
    ))

# Запрос автоматически идёт в нужную партицию
result = engine.execute(
    'SELECT * FROM orders WHERE order_date >= "2024-01-01"'
)

Типы:

• Range partitioning (по диапазонам)
• List partitioning (по списку значений)
• Hash partitioning (по хешу)
• Composite partitioning (комбинация)

Оптимизация запросов

Индексирование

from sqlalchemy import create_engine, Index, Column, Integer, String
from sqlalchemy.orm import declarative_base

Base = declarative_base()

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    email = Column(String, unique=True, index=True)  # Index
    name = Column(String)
    created_at = Column(DateTime, index=True)  # Для range queries

# Составной индекс для часто используемых фильтров
__table_args__ = (
    Index('idx_user_created_status', 'created_at', 'status'),
)

Query optimization

from sqlalchemy.orm import joinedload, selectinload

# N+1 проблема - плохо
users = session.query(User).all()
for user in users:
    print(user.posts)  # N дополнительных запросов

# Решение 1: Eager loading с joinedload
users = session.query(User).options(joinedload(User.posts)).all()

# Решение 2: selectinload (для one-to-many)
users = session.query(User).options(selectinload(User.posts)).all()

# Кэширование часто запрашиваемых данных
from functools import lru_cache

@lru_cache(maxsize=1000)
def get_user_by_id(user_id):
    return session.query(User).filter(User.id == user_id).first()

Денормализация и кэширование

# Redis для кэширования горячих данных
import redis
from json import dumps, loads

cache = redis.Redis(host='localhost', port=6379, db=0)

def get_user_with_cache(user_id):
    cache_key = f'user:{user_id}'
    cached = cache.get(cache_key)
    
    if cached:
        return loads(cached)
    
    user = session.query(User).filter(User.id == user_id).first()
    cache.setex(cache_key, 3600, dumps(user.to_dict()))  # 1 час
    return user

Выбор стратегии

В реальных проектах обычно комбинируют несколько подходов: репликация для высокой доступности, индексирование и кэширование для скорости, и шардирование только если действительно нужен глобальный масштаб.