Перейти к основному содержанию
Масштабирование — это возможность изменять доступные ресурсы в соответствии с потребностями клиентов. Сервисы уровней Scale и Enterprise (со стандартным профилем 1:4) можно масштабировать горизонтально, программно вызывая API или меняя настройки в интерфейсе для изменения системных ресурсов. Эти сервисы также можно автоматически масштабировать по вертикали в соответствии с потребностями приложения.
Уровни Scale и Enterprise поддерживают сервисы как с одной, так и с несколькими репликами, тогда как уровень Basic поддерживает только сервисы с одной репликой. Сервисы с одной репликой имеют фиксированный размер и не поддерживают ни вертикальное, ни горизонтальное масштабирование. Чтобы масштабировать сервисы, вы можете перейти на уровень Scale или Enterprise.

​
Как работает масштабирование в ClickHouse Cloud

В настоящее время ClickHouse Cloud поддерживает вертикальное автомасштабирование и ручное горизонтальное масштабирование для сервисов уровня Scale. Для сервисов уровня Enterprise масштабирование работает следующим образом:
  • Горизонтальное масштабирование: Ручное горизонтальное масштабирование доступно для всех стандартных и пользовательских профилей на уровне Enterprise.
  • Вертикальное масштабирование:
    • Стандартные профили (1:4) поддерживают вертикальное автомасштабирование.
    • Пользовательские профили (highMemory и highCPU) не поддерживают вертикальное автомасштабирование и ручное вертикальное масштабирование. Однако для таких сервисов вертикальное масштабирование возможно через обращение в поддержку.
В ClickHouse Cloud масштабирование выполняется по модели “Make Before Break” (MBB). Сначала добавляется одна или несколько реплик нового размера, и только потом удаляются старые, что позволяет избежать потери производительности во время масштабирования. Благодаря отсутствию разрыва между удалением существующих реплик и добавлением новых MBB делает процесс масштабирования более плавным и менее disruptive. Это особенно полезно при масштабировании вверх, когда высокая загрузка ресурсов требует дополнительной мощности, поскольку преждевременное удаление реплик только усугубило бы нехватку ресурсов. В рамках этого подхода мы ждем до одного часа, чтобы все текущие запросы на старых репликах успели завершиться, прежде чем удалять их. Это позволяет, с одной стороны, дождаться завершения текущих запросов, а с другой — не допустить, чтобы старые реплики оставались слишком долго.

​
Подробнее

Последнее изменение 10 июня 2026 г.