Масштабируемость хранилища ломается не на объеме, а на перекосах доступа

Масштабируемость хранилища ломается не на объеме, а на перекосах доступа

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

Рассмотрим архитектурный срез по данному узлу. Для проверки масштабируемости полезно смотреть не на среднюю загрузку, а на распределение:
• latency по p95/p99;
• долю rebalance и repair;
• размер очереди на запись;
• частоту конфликтов при консенсусе или лидере шарда.
Если одна из метрик растет быстрее линейного графика объема данных, масштабирование уже неэффективно.

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

Рекомендуется обратить внимание на метрику tail latency: именно она показывает, когда хранилище еще отвечает, но уже теряет способность масштабироваться без деградации сервиса.