Какие проблемы возникают при решардинге?

Решардинг нужен, когда меняется число шардов, меняется стратегия распределения или появился перекос нагрузки. Это одна из самых “дорогих” операций в жизни системы.

Основные проблемы решардинга

1) Большие объемы данных и длительность

Перенос данных означает:

1. чтение из исходного шарда

2. запись в целевой шард

3. проверку целостности

Даже если все автоматизировано, это:

• нагрузка на сеть

• нагрузка на диски

• влияние на латентность продакшена

2) Консистентность во время переноса

Ключевой риск: данные продолжают меняться, пока идет миграция.

Типовые сложности:

1. запись пришла в старый шард, а чтение уже идет в новый

2. часть данных скопирована, часть еще нет

3. “потерянные” апдейты при неправильной синхронизации

Чтобы уменьшить риск, применяют:

• журналирование изменений

• догоняющую синхронизацию (catch-up)

• фиксацию точки (cutover point)

3) Смена роутинга без простоя

Во время решардинга нужно управлять маршрутизацией запросов.

Часто делают так:

1. добавить поддержку “старой” и “новой” схемы

2. постепенно переводить трафик

3. держать возможность отката

Если роутинг меняется резко:

• часть запросов начнет ходить “не туда”

• возрастет число ошибок и таймаутов

4) Dual write и его риски

Один из распространенных подходов — некоторое время писать в две схемы:

1. запись в старый шард

2. запись в новый шард

Это снижает риск потери данных, но добавляет проблемы:

1. двойная нагрузка на запись

2. сложнее транзакционная целостность

3. возможны расхождения при частичных сбоях

5) Уникальные ключи и ограничения

Проблема: уникальность на уровне “всего кластера” сложнее обеспечить, когда данные физически в разных местах.

Например:

• уникальный email по всей базе

• глобальный order_number

При решардинге может понадобиться:

1. централизованный сервис генерации ID

2. глобальный индекс (дорого)

3. изменение бизнес-ограничений

6) Отладка и наблюдаемость

Решардинг требует:

1. метрик прогресса миграции

2. метрик ошибок

3. сравнения контрольных сумм/количеств

Без этого вы можете “успешно” завершить перенос с тихими потерями данных.

Типичный безопасный план (упрощенно)

Обычно делают последовательность:

1. подготовить новый набор шардов

2. начать фоновую миграцию данных

3. включить запись изменений (лог или dual write)

4. догнать расхождения

5. переключить чтение

6. переключить запись

7. оставить период наблюдения и возможность rollback

8. выключить старую схему

Вывод

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