Какие плюсы и минусы шардирования БД?

Плюсы и минусы шардирования базы данных

Шардирование — это горизонтальное разделение данных по нескольким серверам. Я использовал его в проектах с миллионами записей.

ПЛЮСЫ шардирования

1. Масштабируемость (Scalability)

Распределяем нагрузку горизонтально вместо вертикального масштабирования:

# Без шардирования — одна БД
users_db = "postgresql://server1:5432/users"

# С шардированием — несколько БД
shards = {
    0: "postgresql://server1:5432/users_shard_0",
    1: "postgresql://server2:5432/users_shard_1",
    2: "postgresql://server3:5432/users_shard_2",
    3: "postgresql://server4:5432/users_shard_3",
}

def get_shard(user_id: int) -> str:
    shard_id = user_id % 4  # Модульное шардирование
    return shards[shard_id]

# user_id=10 → shard_1
# user_id=15 → shard_3

2. Повышение производительности

Каждый шард меньше и быстрее:

# Без шардирования: 1B records × медленные запросы
query = "SELECT * FROM users WHERE age > 25 ORDER BY created_at LIMIT 1000"
# Это затронет большой индекс, медленно

# С шардированием: каждый шард имеет ~250M records
# Запрос против меньшего набора данных — быстрее

Пример производительности:

• 1 billion records: 5-10 сек запрос
• 250M на каждом из 4 шардов: 200-500 мс на каждом
• Параллельно: ~500 мс (вместо 5-10 сек)

3. Изолированность отказов (Fault Isolation)

Отказ одного шарда не влияет на другие:

from concurrent.futures import ThreadPoolExecutor

def query_all_shards(query: str):
    results = {}
    
    with ThreadPoolExecutor(max_workers=4) as executor:
        futures = {}
        for shard_id, conn_str in shards.items():
            future = executor.submit(query_shard, shard_id, conn_str, query)
            futures[shard_id] = future
        
        for shard_id, future in futures.items():
            try:
                results[shard_id] = future.result(timeout=5)
            except Exception as e:
                print(f"Shard {shard_id} failed: {e}")
                results[shard_id] = []  # Failover
    
    return results

# Если shard_2 упал, остальные продолжают работать

4. Локальность данных (Data Locality)

Данные одного "региона" на одном сервере:

# Географическое шардирование
shards = {
    "US": "postgresql://aws-us-east:5432/users",
    "EU": "postgresql://aws-eu-west:5432/users",
    "ASIA": "postgresql://aws-ap:5432/users",
}

def get_shard(region: str) -> str:
    return shards.get(region, shards["US"])

# Выигрыш: низкая латенция, соответствие GDPR

5. Независимое масштабирование

Дорогие шарды масштабируем отдельно:

# shard_0 (US, большой трафик) → большой сервер
# shard_1 (EU, средний трафик) → средний сервер
# shard_2 (ASIA, малый трафик) → малый сервер

# Можем добавлять ресурсы только где нужно

МИНУСЫ шардирования

1. Сложность операций между шардами (Cross-Shard Queries)

Запросы, требующие данных из нескольких шардов, сложны:

# Простой запрос (в одном шарде)
query = "SELECT * FROM users WHERE user_id = 10"
# Шард: 10 % 4 = 2

# Сложный запрос (несколько шардов)
query = "SELECT * FROM users WHERE age > 25 ORDER BY created_at"
# Нужно запросить ВСЕ 4 шарда, потом объединить результаты

def query_all_shards(age_threshold: int):
    all_users = []
    
    for shard_id, conn_str in shards.items():
        query = f"SELECT * FROM users WHERE age > {age_threshold}"
        users = execute_query(conn_str, query)
        all_users.extend(users)
    
    # Сортировка только в памяти приложения
    all_users.sort(key=lambda u: u['created_at'])
    return all_users[:1000]  # LIMIT

# Это медленнее, чем один запрос в БД

2. Перебалансировка данных (Resharding)

Добавление нового шарда требует миграции:

# Было 4 шарда
def old_shard(user_id: int) -> int:
    return user_id % 4

# Добавили 5-й шард — нужна перестановка
def new_shard(user_id: int) -> int:
    return user_id % 5  # 75% пользователей переместятся!

# Миграция:
# 1. Новый шард пуст
# 2. Мигрируем 20% данных в новый шард
# 3. Обновляем маршрутизацию
# 4. Проверяем консистентность
# 5. Удаляем дубли

# Это дорого и рискованно!

Решение — consistent hashing:

from hashlib import md5

def consistent_hash(key: str, ring_size: int = 360) -> int:
    hash_value = int(md5(key.encode()).hexdigest(), 16)
    return hash_value % ring_size

# При добавлении шарда нужно перемещать только ~25% данных

3. Транзакции между шардами

Транзакции ACID работают только внутри одного шарда:

# Транзакция в одном шарде (OK)
with db.transaction():
    user = get_user(user_id=10)  # Шард 2
    user.balance -= 100
    user.save()

# Транзакция между шардами (ПРОБЛЕМА)
with db.transaction():
    sender = get_user(user_id=10)  # Шард 2
    recipient = get_user(user_id=25)  # Шард 1
    
    sender.balance -= 100
    recipient.balance += 100
    
    sender.save()  # ОК
    recipient.save()  # Может упасть!
    # Деньги потеряны (sender уменьшился, но recipient не увеличился)

Решение:

# Eventual consistency + коммит-логи
class TransactionLog:
    def log_transfer(self, sender_id, recipient_id, amount):
        # Логируем намерение
        self.db.insert('transaction_log', {
            'sender': sender_id,
            'recipient': recipient_id,
            'amount': amount,
            'status': 'pending'
        })
    
    def commit_transfer(self, tx_id):
        # Гарантируем оба обновления
        try:
            sender_shard = get_shard(sender_id)
            recipient_shard = get_shard(recipient_id)
            
            sender_shard.execute("UPDATE users SET balance = balance - ? WHERE id = ?", ...)
            recipient_shard.execute("UPDATE users SET balance = balance + ? WHERE id = ?", ...)
            
            self.db.update('transaction_log', {'status': 'committed'}, where={'id': tx_id})
        except:
            self.db.update('transaction_log', {'status': 'failed'}, where={'id': tx_id})
            raise

4. Дублирование логики (Code Duplication)

Все приложения должны знать о шардировании:

# Все сервисы должны делать это
def get_user(user_id: int):
    shard_id = user_id % 4
    db = get_connection(shards[shard_id])
    return db.query(f"SELECT * FROM users WHERE id = {user_id}")

# Сервис заказов
def get_order(order_id: int):
    # Нужно знать, что заказы шардируются по user_id!
    user_id = get_user_id_from_order(order_id)
    shard_id = user_id % 4
    db = get_connection(shards[shard_id])
    return db.query(f"SELECT * FROM orders WHERE id = {order_id}")

# Логика дублируется везде

Решение — middleware:

class ShardingMiddleware:
    def __init__(self, shards):
        self.shards = shards
    
    def get_connection(self, resource_type: str, id: int):
        shard_key = self.get_shard_key(resource_type, id)
        shard_id = shard_key % len(self.shards)
        return self.shards[shard_id]
    
    def execute(self, resource_type: str, id: int, query: str):
        conn = self.get_connection(resource_type, id)
        return conn.execute(query)

middleware = ShardingMiddleware(shards)
middleware.execute('users', 10, "SELECT * FROM users WHERE id = 10")

5. Hot Shards (неравномерное распределение)

Некоторые шарды получают больше трафика:

# Бизнес-лидеры (user_id = 1, 2, 3) генерируют 50% трафика
# Обычные пользователи распределены равномерно

def get_shard(user_id: int) -> int:
    return user_id % 4

# user_id = 1 → shard_1 (лидер, 50% трафика)
# user_id = 2 → shard_2 (лидер, 50% трафика)
# user_id = 1000000 → shard_0 (обычный)

# Shard_1 и shard_2 становятся узкими местами

Решение:

# Выделить отдельное хранилище для лидеров
vip_users = {1, 2, 3}
shard_map = {}

def get_shard(user_id: int) -> str:
    if user_id in vip_users:
        return "vip_server"  # Отдельный высокомощный сервер
    else:
        return shards[user_id % 4]

6. Сложность разработки и тестирования

Каждый разработчик должен понимать шардирование:

# Новый разработчик пишет запрос
def get_recent_posts():
    # ОШИБКА: запрос ко всем таблицам users через все шарды
    return db.query("SELECT p.* FROM posts p JOIN users u ON p.user_id = u.id LIMIT 100")

# Это выполнит 4 запроса и объединит результаты в памяти
# Дорого и медленно

# Правильно:
def get_recent_posts_for_user(user_id: int):
    shard = get_shard(user_id)
    return shard.query("SELECT * FROM posts WHERE user_id = ? LIMIT 100", user_id)

Когда использовать шардирование

✅ Используй, если:

• Данные > 500 GB
• QPS > 10,000
• Латенция критична
• Имеешь бюджет на инженерию

❌ Не используй, если:

• Данные < 100 GB
• QPS < 1,000
• Бюджет на опер очень ограничен
• Команда < 5 инженеров

Альтернативы шардированию

# 1. Вертикальное масштабирование (проще)
# Добавить RAM, CPU, диск серверу (до лимита)

# 2. Read replicas
# Одна write-primary, несколько read-replicas
db_write = "postgresql://server1:5432/main"
db_read = [
    "postgresql://server2:5432/replica_1",
    "postgresql://server3:5432/replica_2",
]

# 3. Кэширование (Redis, Memcached)
# Избежать многих запросов в БД

# 4. NoSQL (MongoDB, Cassandra)
# Встроенное шардирование, но trade-offs

Best Practices

1. Выбери правильный shard key — стабильный, равномерно распределённый
2. Начни с одного шарда, масштабируй когда нужно
3. Используй consistent hashing для уменьшения перебалансировки
4. Логируй все cross-shard запросы — они дорогие
5. Мониторь hot shards — добавляй ресурсы неравномерно
6. Имей plan для resharding — это будет нужно
7. Используй миграции с двойной записью при добавлении шардов

Шардирование — последний шаг масштабирования. Сначала оптимизируй запросы, добавь кэш, потом читай реплики, и только потом шардируй.