Может ли репликация быть без шардирования?

Да, репликация может быть без шардирования

Репликация и шардирование — это два независимых механизма масштабирования баз данных, которые решают разные задачи. Их можно использовать как вместе, так и по отдельности.

Что такое репликация?

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

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

Что такое шардирование (партиционирование)?

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

• Горизонтальное масштабирование записи и хранения: Нагрузка на запись и объем данных распределяются по кластеру.

Ключевое отличие

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

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

1. Традиционная Master-Slave (Primary-Secondary) репликация

-- На Primary
INSERT INTO users (name, email) VALUES ('Ivan', 'ivan@example.com');

-- На Secondary реплике данные появятся автоматически
SELECT * FROM users WHERE name = 'Ivan'; -- Запрос можно выполнить здесь

В этой схеме все данные есть на каждом узле. Шардирования нет.

2. Кластер на основе консенсус-алгоритма (Raft)

Популярный подход для современных распределенных баз данных (etcd, Consul, некоторые конфигурации MongoDB и Redis). Все узлы равноправны (peer-to-peer), данные реплицируются на все узлы, обеспечивая высокую доступность при отказе меньшинства серверов.

// Упрощенная концепция: клиент отправляет запрос любому узлу Raft-кластера.
// Данные реплицируются на кворум узлов.
type SimpleRaftStore struct {
    data map[string]string
    nodeID string
}

func (s *SimpleRaftStore) Set(key, value string) error {
    // Операция будет реплицирована на большинство узлов кластера
    // перед тем как считаться выполненной
    return s.replicateToQuorum("SET", key, value)
}

3. Синхронная мульти-мастер репликация

Некоторые СУБД (например, PostgreSQL с бидирекциональной репликацией (BDR), Galera для MySQL) позволяют писать на любой узел, а изменения синхронно или асинхронно реплицируются на все остальные. Весь датасет присутствует на каждом узле.

Преимущества репликации без шардирования

• Простота: Архитектура, конфигурация и код приложения намного проще. Не нужно заботиться о выборе шард-ключа и маршрутизации запросов.
• Предсказуемость производительности: Любой запрос можно выполнить на любой реплике, так как там есть все данные.
• Упрощенное согласование данных (consistency): Проще достичь строгой согласованности (strong consistency) в пределах одного датацентра.

Ограничения репликации без шардирования

• Ограничение на объем данных: Размер базы не может превышать возможности одного сервера (диск, RAM, CPU).
• Ограничение на запись: Вся нагрузка на запись по-прежнему приходится на один основной узел (в асинхронных схемах) или делится между ограниченным числом мастеров. Пропускная способность записи не масштабируется горизонтально.
• Задержка репликации: В асинхронных схемах реплики могут отставать, что приводит к чтению устаревших данных (чтение своего запроса, read-after-write consistency).

Когда это оптимальный выбор?

Репликация без шардирования идеально подходит для:

1. Сервисов с нагрузкой "чтение >> запись". Например, каталоги товаров, блоги, CMS.
2. Сервисов, где данные должны полностью помещаться на одном узле (например, до сотен ГБ или нескольких ТБ).
3. Систем, требующих простой и надежной архитектуры без сложной логики шардирования в приложении.
4. Обеспечения отказоустойчивости и высокой доступности в рамках одного или нескольких датацентров.

Итог

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