Шардирование, репликация, партиционирование в БД

Шардирование, репликация и партиционирование в базах данных

Это три фундаментальных подхода к масштабированию и обеспечению отказоустойчивости баз данных. Часто их путают, хотя решают они разные задачи.

Партиционирование (секционирование)

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

Как работает:

• Данные распределяются по партициям на основе ключа партиционирования (range, list, hash)
• Все партиции находятся на одном сервере
• Для приложения таблица выглядит как единое целое

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

• Таблицы с миллиардами строк
• Необходимость быстрого удаления устаревших данных (DROP PARTITION быстрее DELETE)
• Улучшение производительности запросов с фильтрацией по ключу партиционирования

Типичные проблемы:

• Неравномерное распределение данных (перекос партиций)
• Ограничение на количество партиций (зависит от СУБД)
• Сложности с изменением схемы партиционирования на лету

Репликация

Суть: Синхронное или асинхронное копирование данных между несколькими серверами БД.

Виды:

• Master-Slave (leader-follower): Один мастер на запись, несколько реплик на чтение
• Multi-master: Несколько узлов, каждый может писать
• Synchronous vs Asynchronous: Синхронная гарантирует консистентность, но медленнее

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

• Отказоустойчивость (если упал мастер, реплика берет на себя)
• Распределение нагрузки на чтение
• Географическая близость к пользователям

Подводные камни:

• Replication lag: Асинхронная репликация может отставать, что приводит к чтению устаревших данных
• Split-brain: При сетевых проблемах в multi-master могут возникнуть конфликты
• DDL операции: Изменение схемы на мастере может сломать репликацию

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

Суть: Горизонтальное разделение данных между несколькими независимыми серверами (шардами).

Как работает:

• Каждый шард содержит часть данных и работает как самостоятельная БД
• Нужен механизм маршрутизации запросов (шард-ключ)
• Часто используется прокси-слой (например, Vitess, ProxySQL)

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

• Когда данные не помещаются на один сервер
• Когда нагрузка на запись превышает возможности одного инстанса
• Когда нужно географическое распределение данных

Сложности:

• Cross-shard запросы: JOIN'ы и транзакции между шардами — боль и тормоза
• Resharding: Перераспределение данных при добавлении новых шардов — сложная операция
• Выбор шард-ключа: Неудачный выбор приводит к "горячим" шардам
• Глобальные индексы: Уникальность ключей между шардами требует дополнительных механизмов

Сравнение и комбинирование

На практике эти техники часто комбинируют:

• Партиционирование + Репликация: Каждая партиция реплицируется на несколько серверов
• Шардирование + Репликация: Каждый шард имеет свои реплики для отказоустойчивости

Рекомендации для Go-разработчика

1. Не спешите с шардированием — это последнее средство. Сначала оптимизируйте запросы, добавьте индексы, попробуйте партиционирование и репликацию.

2. Используйте библиотеки с поддержкой шардинга — например, для работы с PostgreSQL через pgx можно использовать паттерн Repository с выбором шарда на уровне приложения.

3. Учитывайте CAP-теорему — в распределенных системах нужно выбирать между консистентностью и доступностью.

4. Мониторьте ключевые метрики: replication lag, распределение данных по шардам/партициям, время cross-shard запросов.