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

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

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

Проверять нужно три слоя:
— путь данных: сколько хопов проходит запись и где формируется задержка;
— метаданные: кто владеет шардом, как быстро обновляется карта кластера;
— восстановление: сколько времени узел тратит на replay, скан и репликацию после сбоя.

Если репликация асинхронная, масштаб упирается в потерю данных при аварии. Если синхронная — в латентность на каждом write path. Поэтому важен не «идеальный» режим, а измеримый баланс: целевой RPO, допустимый RTO и предсказуемая нагрузка на сеть. Рекомендуется обратить внимание на метрику p99 задержки именно в момент перераспределения данных, а не только в штатном режиме.

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

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