Репликация и шардирование БД

Как масштабировать саму БД, когда реплик для чтения уже мало, а данные не помещаются.

Репликация — копирование данных на несколько узлов (обычно для масштабирования чтений). Шардирование — разрезание данных по узлам (для масштабирования записи и объёма).

Репликация для чтений

Классическая схема — один master на запись и несколько read-реплик. Чтения распределяются по репликам, снимая нагрузку с мастера. Это решает read-heavy нагрузку, но не помогает с записью: весь поток записи всё ещё идёт в один мастер.

Запись --> Master --(репликация)--> Replica 1 (чтение)
                              \--> Replica 2 (чтение)

Отставание реплики

Реплика обновляется не мгновенно — есть лаг. Поэтому возможна аномалия «прочитал свою же только что сделанную запись и не увидел её». Лечат чтением критичных данных с мастера (read-your-writes) или ждут синхронизации.

Шардирование

Когда запись или объём перерастают один узел, данные режут на шарды по ключу. Запросы маршрутизируются на нужный шард по функции от ключа.

Как работает под капотом

Шардирование платит дорого: запросы, охватывающие несколько шардов, становятся «scatter-gather» (опросить все и собрать), JOIN между шардами почти невозможен, а транзакции через шарды требуют распределённого протокола. Поэтому ключ шардирования выбирают так, чтобы горячие запросы попадали в один шард. Плохой выбор ключа -> hotspot (один шард перегружен) и болезненная ребалансировка при добавлении узлов.

Частые ошибки

• Шардировать раньше времени, когда хватило бы реплик.
• Игнорировать отставание реплики и получать «исчезающие» записи.
• Выбрать ключ шардирования, создающий hotspot (например, по дате).

Итог

• Реплики масштабируют чтение, шардирование — запись и объём.
• У реплик есть лаг: критичные чтения берите с мастера.
• Ключ шардирования определяет всё; плохой выбор даёт hotspot.