CAS разделяет вычисления и хранение в ClickHouse

Altinity добавила Content Addressed Storage в Antalya 26.6. Новая функция даёт возможность перенести данные MergeTree-таблиц в общее объектное хранилище и масштабировать вычислительные узлы независимо от объёма данных. Для российских команд это способ снизить затраты на железо при работе с крупными on-premise кластерами без перестройки архитектуры. MergeTree — это семейство движков таблиц в ClickHouse, предназначенных для хранения и обработки больших объёмов данных с поддержкой сортировки, слияния частей и эффективных запросов по диапазонам. Content Addressed Storage позволяет обращаться к данным по их содержимому, а не по имени файла, что упрощает совместное использование одной копии несколькими узлами.

Ограничения shared-nothing архитектуры

Классический ClickHouse построен по принципу shared-nothing: каждый узел хранит свою копию данных и обрабатывает запросы самостоятельно. При росте объёма приходится добавлять и CPU, и память, и диски пропорционально. Это быстро упирается в пределы одного сервера и приводит к избыточному копированию данных между репликами. Shared-nothing означает полную независимость узлов: нет общего хранилища, поэтому отказ одного сервера не влияет на другие, но и масштабирование требует дублирования всего объёма. В результате компании вынуждены закупать больше серверов, чем необходимо только для вычислений, и тратить ресурсы на синхронизацию копий.

Альтернативу предложили Snowflake и Databricks: данные лежат в одном месте на объектном хранилище, а вычислительные ноды подключаются по требованию. ClickHouse начал движение в эту сторону ещё в 2020 году через S3-диски, но сохранил модель «каждый шард и реплика — своя копия». Zero-copy replication пыталась исправить ситуацию, однако требовала синхронизации трёх независимых источников: локальных метаданных, самих файлов в S3 и состояния репликации в Keeper. На практике это приводило к потерянным файлам и отсутствию нормальной сборки мусора. При принятии решения о переходе важно учитывать, что zero-copy replication уже показала риски потери данных при несогласованности метаданных, поэтому CAS может стать более надёжным вариантом, если текущая нагрузка требует частого масштабирования без добавления дисков.

Что меняет CAS

CAS хранит данные по содержимому, а не по пути, и позволяет нескольким узлам работать с одной копией без репликации. Включение требует только обновления до Antalya 26.6 и правки конфигурации — схема таблиц и запросы остаются прежними. Функция распространяется на все движки семейства MergeTree. Главное отличие от предыдущих попыток — отказ от координации трёх систем в транзакционном режиме. Данные адресуются по хешу содержимого, поэтому удаление и очистка становятся проще. Это устраняет основную причину нестабильности zero-copy replication. Производительность по-прежнему зависит от кэшей и prefetch, но базовая модель уже не требует дублирования данных на каждом узле. При оценке стоит проверить, насколько текущие запросы зависят от локального доступа: если преобладают сканирования больших объёмов, CAS даёт экономию на дисках, но требует настройки кэширования для сохранения скорости отклика.

Ограничения и риски при внедрении

CAS не отменяет необходимость в локальных кэшах: объектное хранилище всё равно имеет высокую задержку. При частых мелких запросах или обновлениях часть данных придётся держать в памяти или на быстрых дисках узлов. Кроме того, пока нет публичных данных о поведении при массовых удалениях или при сбоях сети между кластером и хранилищем. Ещё один момент — совместимость с существующими инструментами резервного копирования и мониторинга. Метаданные теперь распределены иначе, поэтому скрипты, рассчитанные на локальные пути, потребуют доработки. Перед промышленным использованием стоит проверить поведение на тестовом кластере с реальной нагрузкой. Для решения о внедрении важно оценить риски: отсутствие данных о массовых удалениях означает, что команды должны сами провести тесты на очистку и восстановление, а также обновить процессы мониторинга, чтобы избежать неожиданных проблем с доступностью.

Как это ложится на российские кластеры

В отечественных компаниях ClickHouse чаще всего стоит на собственном железе из-за ограничений доступа к облачным сервисам. CAS позволяет увеличить объём хранилища, не наращивая количество серверов и их конфигурацию. Это снижает затраты на закупку и обслуживание оборудования при импортозамещении. При этом остаётся возможность использовать проверенные on-premise объектные хранилища, такие как Ceph или MinIO. Главное — оценить, насколько текущая схема запросов допускает разделение compute и storage. Если большинство аналитики работает с большими диапазонами и допускает кэширование, переход даёт заметную экономию. В противном случае придётся оставить часть таблиц на локальных дисках. Подробнее — в оригинальной публикации Altinity. При планировании миграции российским командам следует учитывать, что on-premise хранилища требуют отдельной настройки отказоустойчивости, а экономия на серверах окупается только при стабильной сети между вычислительными узлами и хранилищем.

Источник

Это краткий разбор материала Altinity. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: CAS разделяет вычисления и хранение в ClickHouse.

Курс по теме — Построение DWH на ClickHouse