В чем разница между шардированием и репликацией?

Различия между шардированием и репликацией в контексте баз данных

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

Репликация: обеспечение доступности и отказоустойчивости

Репликация — это процесс создания и поддержания копий (реплик) одного и того же набора данных на нескольких серверах (нодах). Основные цели:

• Повышение доступности: При падении основной ноды (мастера) одна из реплик (слейвов) может взять на себя её роль.
• Масштабирование чтения: Запросы на чтение можно распределять по репликам, разгружая мастер.
• Географическое распределение: Реплики можно размещать ближе к пользователям в разных регионах для уменьшения задержки.
• Резервное копирование: Реплика может использоваться как "горячая" резервная копия без остановки основного сервиса.

Чаще всего используется master-slave (primary-replica) репликация:

-- На мастере данные изменяются
INSERT INTO users (name, email) VALUES ('Иван', 'ivan@example.com');

-- На слейве эти данные реплицируются и доступны для чтения
SELECT * FROM users WHERE name = 'Иван'; -- Чтение с реплики

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

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

Шардирование (партиционирование) — это метод разделения одного логического набора данных на более мелкие части (шарды), которые распределяются по разным серверам базы данных. Каждый шард является независимой базой данных.

Основные цели:

• Масштабирование записи и хранения: Нагрузка на запись и объем данных распределяются между множеством серверов.
• Преодоление аппаратных ограничений: Позволяет хранить и обрабатывать объемы данных, превышающие возможности одной машины.

Данные разделяются по определённому ключу (shard key):

// Пример простой стратегии шардирования по диапазону ID пользователя
function getShardForUser(int $userId): string {
    if ($userId >= 1 && $userId <= 1000000) {
        return 'shard_1'; // Сервер 1
    } elseif ($userId >= 1000001 && $userId <= 2000000) {
        return 'shard_2'; // Сервер 2
    }
    // ...
}

// Запрос будет направлен в конкретный шард
$shardConnection = connectToShard(getShardForUser($targetUserId));
$userData = $shardConnection->query("SELECT * FROM users WHERE id = {$targetUserId}");

Ключевой момент: Каждый шард содержит только часть общих данных. Для выполнения запроса, затрагивающего несколько шардов, нужна координация (например, map-reduce), что добавляет сложности.

Сравнительная таблица

Комбинированный подход в реальных системах

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

Мастер Шард 1 (Северо-Запад)  ← Реплика Шард 1
Мастер Шард 2 (Юго-Восток)    ← Реплика Шард 2

Итог: Выбор между технологиями не является взаимоисключающим.

• Используйте репликацию, когда вам нужна отказоустойчивость и масштабирование операций чтения.
• Используйте шардирование, когда вы упираетесь в ограничения одной машины по объему данных или производительности записи.
• Для построения действительно масштабируемой и устойчивой системы будьте готовы применять оба подхода вместе, осознавая прирост операционной сложности.