Одного сервера уже недостаточно. Что дальше: репликация или шардинг?

https://www.youtube-nocookie.com/embed/qdNlt8wR_84

Автор: Listen IT · YouTube · статья Highload Today

---

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

Ролик Listen IT даёт короткое введение в оба подхода. Реплики можно использовать для резервирования и переноса части чтений с основного узла. Шардинг нужен, когда объём данных или нагрузка перестают помещаться на одном сервере: система выбирает shard key и по нему определяет, где должна находиться каждая запись.

Разница становится особенно важной при отказе. Реплика может заменить основной узел только при наличии механизма failover. У шарда замены вообще может не быть, если его не реплицировать отдельно. Поэтому production-система часто сочетает оба подхода: данные разделены на шарды, а внутри каждого шарда есть несколько копий.

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

Из этого можно взять в работу: перед добавлением новых узлов точно определить ограничение системы — не хватает производительности чтения, доступности, диска или пропускной способности записи.

---

При репликации основной узел принимает изменения, после чего они передаются на другие узлы. Реплики могут обслуживать чтение и использоваться для восстановления после отказа primary. Но наличие копии ещё не гарантирует автоматическую доступность: система должна обнаружить отказ, выбрать новый primary и перенаправить клиентов.

Асинхронная репликация создаёт дополнительный компромисс. Реплика может отставать, поэтому чтение с неё не всегда видит последнюю запись. Если primary отказал до передачи изменений, часть уже подтверждённых данных тоже может быть потеряна.

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

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

Шардинг не обязательно реализуется условными блоками в приложении. Маршрутизацию может выполнять proxy или компонент самой СУБД. Однако абстракция не устраняет цену распределения: остаются cross-shard запросы и транзакции, горячие ключи, перенос данных и rebalancing.

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