Кратко: Шардирование и репликация — два главных приёма для масштабирования баз данных. Репликация — копирование одних и тех же данных на несколько серверов. Шардирование — разбиение одной большой базы на много маленьких частей, разложенных по разным серверам. Репликация даёт надёжность, шардирование — масштаб.

▫️Репликация — копии спасут мир · Что это: один мастер (primary) принимает запросы на запись, слейвы (replicas) подхватывают данные и обслуживают чтение. Все хранят одно и то же · Типы репликации: — Синхронная — мастер ждёт подтверждения от слейва. Надёжно, но медленно — Асинхронная — мастер записал и забыл. Быстро, но риск потери данных — Полусинхронная — один слейв подтверждает, остальные асинхронно · Схемы: — Master-Slave — один пишет, много читают. Классика — Master-Master — несколько узлов принимают запись. Сложно, но есть решения — Group Replication — группа узлов с консенсусом · Зачем: отказоустойчивость (при падении мастера слейв подхватит), масштабирование чтения (разгружаем мастер), бекапы без остановки сервиса · Проблемы: задержка репликации (слейвы могут отставать), сложный failover (ручной или через внешние инструменты)

▫️Шардирование — делить и властвовать · Что это: база горизонтально разрезается на куски (шарды). Каждый шард — отдельная база со своей частью данных. Все шарды вместе образуют логически единую базу · Ключ шардирования — поле, по которому решаем, куда отправить запись. От ключа зависит равномерность распределения нагрузки · Стратегии шардирования: — Диапазонная — данные делятся по диапазонам ключа (id 1–1000 в шард 1). Просто, но возможен перекос — Хеш-шардирование — хеш от ключа отправляет запись в один из шардов. Равномерно, но сложнее менять количество шардов — Географическая — данные из Европы в европейский шард. Для регуляторики и задержек · Зачем: масштабирование записи (пишем в разные шарды), сверхбольшие объёмы (один сервер не тянет), географическая близость · Проблемы: сложные запросы (JOIN между шардами почти не работают), решардинг (менять количество шардов — боль), транзакции между шардами сложны

▫️Как дружат репликация и шардирование В больших системах они работают вместе: · Шардирование — разбиваем данные на шарды · Репликация — внутри каждого шарда делаем master-slave Пример: шард 1: мастер в Европе, слейв в резервном ДЦ. Шард 2 — аналогично. Система получается и масштабируемой, и надёжной. Так живут Google, Facebook, Amazon, любые крупные сервисы.

▫️Где какая технология живёт · Репликация — MySQL, PostgreSQL, MongoDB, Redis, Cassandra · Шардирование — MongoDB, Cassandra, ClickHouse, MySQL (через Vitess), PostgreSQL (через Citus), Redis Cluster

▫️Культурный феномен · "Шардировать всё" — мантра архитекторов, когда база тормозит. Часто проблема не в объёме, а в индексах · "Репликация спасёт" — вера, что реплики решат все проблемы. Но failover надо тестировать · Перекос шардов — один шард переполнен, остальные пустые. Главная боль неправильного выбора ключа

▫️Современное положение (2026) · Репликация — есть во всех базах. Стандарт: несколько читающих реплик, автоматический failover (Patroni, Orchestrator) · Шардирование — перестало быть экзотикой. Базы "из коробки" умеют шардироваться (MongoDB, Cassandra, ClickHouse, CockroachDB) · Cloud-native — базы, где шардирование и репликация зашиты в архитектуру (Aurora, Spanner, YDB). Пользователь даже не знает, где шарды · Российские решения — YDB от Яндекса, Postgres Pro с расширениями для шардирования

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