Масштабирование БД: Репликация или Шардирование?

Ваш стартап взлетел. Но радость сменяется паникой: база данных "задыхается". CPU в полке, запросы висят по 5 секунд. Просто "добавить RAM" уже не помогает. Пришло время выбирать архитектурную пилюлю: Репликация или Шардирование?

Дилемма архитектора

Выбор стратегии зависит от того, где именно у вас "узкое место": в чтении (Read) или записи (Write).

1. Репликация (Replication): Масштабируем Чтение

Суть: У вас есть один "Босс" (Master), который принимает все изменения, и много "Подчиненных" (Slaves), которые только отдают данные.

• Когда применять: 80-90% нагрузки — это чтение (Read-heavy). Типично для СМИ, блогов, e-commerce каталогов.
• Плюсы: Легко настроить (PostgreSQL Streaming Replication, MySQL Binlog). Данные дублируются (бэкап).
• Минусы: Задержка репликации (Replication Lag). Вы записали данные на Master, но на Slave они появятся через 100мс. Пользователь может не увидеть свой комментарий сразу.

2. Шардирование (Sharding): Масштабируем Запись

Суть: Master не справляется с записью. Мы режем базу на куски. Пользователи A-M едут на Сервер 1, N-Z на Сервер 2.

• Когда применять: Данных так много, что они не влезают на один диск. Или когда один Master не успевает писать (Write-heavy).
• Плюсы: Теоретически бесконечное масштабирование.
• Минусы: Это больно. Вы теряете транзакции ACID между шардами. Вы теряете JOIN (как соединить таблицу с Сервера 1 и Сервера 2?). Бэкапы становятся ночным кошмаром.

Вердикт NineLab

Золотое правило: Откладывайте шардирование до последнего. Это "ядерная кнопка".

Сначала — индексы. Затем — кэширование (Redis). Затем — репликация. И только если у вас трафик уровня Telegram или Uber — шардирование. Не усложняйте архитектуру раньше времени.