Вопросы о ClickHouse®

• Почему стоит использовать ClickHouse® в Managed Service for ClickHouse®, а не собственную установку на виртуальной машине?

• Когда стоит использовать ClickHouse® вместо PostgreSQL?

• Как загружать данные в ClickHouse®?

• Как загрузить в ClickHouse® очень большое количество данных?

• Что случится с кластером, если выйдет из строя одна из нод?

• Можно ли развернуть кластер БД ClickHouse® в нескольких зонах доступности?

• Как устроена репликация для ClickHouse®?

• Почему кластер ClickHouse® занимает на 3 хоста больше, чем должен?

• Как происходит удаление данных по TTL в ClickHouse®?

• Могу ли я использовать тип данных JSON для таблиц в ClickHouse®?

• Почему кластер работает медленно, хотя вычислительные ресурсы использованы не до предела?

Почему стоит использовать ClickHouse® в Managed Service for ClickHouse®, а не собственную установку на виртуальной машине?Почему стоит использовать ClickHouse® в Managed Service for ClickHouse®, а не собственную установку на виртуальной машине?

Managed Service for ClickHouse® автоматизирует рутинное обслуживание БД:

• быстрое развертывание БД с необходимыми доступными ресурсами;

• резервное копирование данных;

• регулярное обновление ПО;

• обеспечение отказоустойчивости кластеров БД;

• мониторинг и статистика использования БД.

Когда стоит использовать ClickHouse® вместо PostgreSQL?Когда стоит использовать ClickHouse® вместо PostgreSQL?

ClickHouse® поддерживает только добавление и чтение данных, так как предназначен прежде всего для аналитики (OLAP). В остальных случаях, скорее всего, удобнее использовать PostgreSQL.

Как загружать данные в ClickHouse®?Как загружать данные в ClickHouse®?

Используйте запрос INSERT, описанный в документации ClickHouse®.

Как загрузить в ClickHouse® очень большое количество данных?Как загрузить в ClickHouse® очень большое количество данных?

Используйте CLI для эффективного сжатия данных при передаче (рекомендуемая частота — не больше 1 команды INSERT в секунду).

Перенос данных с физических носителей пока не поддерживается.

Что случится с кластером, если выйдет из строя одна из нод?Что случится с кластером, если выйдет из строя одна из нод?

Кластеры БД состоят минимум из 2 реплик, поэтому при потере одной ноды кластер продолжит работу.

Данные могут потеряться только если вышла из строя нода с нереплицируемой таблицей.

Можно ли развернуть кластер БД ClickHouse® в нескольких зонах доступности?Можно ли развернуть кластер БД ClickHouse® в нескольких зонах доступности?

Да. Кластер БД может состоять из хостов, расположенных как в разных зонах, так и в разных регионах доступности.

Как устроена репликация для ClickHouse®?Как устроена репликация для ClickHouse®?

Кластеры Managed Service for ClickHouse® используют репликацию с помощью ClickHouse® Keeper или ZooKeeper. В первом случае никаких дополнительных настроек не требуется — репликация и отказоустойчивость включены по умолчанию. Во втором для каждого кластера ClickHouse® создается кластер ZooKeeper минимум из трех хостов.

Для пользователей Yandex Cloud доступ к ZooKeeper и его настройка недоступны.

Почему кластер ClickHouse® занимает на 3 хоста больше, чем должен?Почему кластер ClickHouse® занимает на 3 хоста больше, чем должен?

При создании кластера ClickHouse® из 2 и более хостов Managed Service for ClickHouse® автоматически создает кластер из 3 хостов ZooKeeper для управления репликацией и отказоустойчивостью, если не включена поддержка ClickHouse® Keeper. Эти хосты учитываются в расчете использованной квоты ресурсов в облаке и в расчете стоимости кластера. По умолчанию хосты ZooKeeper создаются с минимальным классом хостов.

Подробнее об использовании ZooKeeper см. документацию ClickHouse®.

Как происходит удаление данных по TTL в ClickHouse®?Как происходит удаление данных по TTL в ClickHouse®?

Удаление данных по TTL выполняется не построчно, а либо целыми кусками (data parts), либо при операциях слияния.

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

Удаление при операциях слияния потребляет больше ресурсов и выполняется либо вместе с обычными фоновыми операциями слияния, либо во время внеплановых слияний. Периодичность операций слияния определяется значением параметра merge_with_ttl_timeout. Этот параметр задается при создании таблицы и указывает минимальное время в секундах перед повторным слиянием для обработки данных с истекшим TTL. По умолчанию — 14400 секунд (4 часа).

Рекомендуется организовывать обработку данных по TTL так, чтобы старые данные всегда удалялись целыми кусками. Для этого при создании таблиц установите для настройки ttl_only_drop_parts значение true.

Могу ли я использовать тип данных JSON для таблиц в ClickHouse®?Могу ли я использовать тип данных JSON для таблиц в ClickHouse®?

Да, но на данный момент JSON является экспериментальным типом данных в ClickHouse®. Чтобы разрешить создание таблиц такого типа, выполните запрос:

SET allow_experimental_object_type=1;

Подробную информацию см. в документации ClickHouse®.

Почему кластер работает медленно, хотя вычислительные ресурсы использованы не до предела?Почему кластер работает медленно, хотя вычислительные ресурсы использованы не до предела?

Вероятно, максимальные значения IOPS и пропускной способности (bandwidth) хранилища недостаточны для обработки текущего количества запросов. В этом случае срабатывает троттлинг и быстродействие всего кластера падает.

Максимальные IOPS и bandwidth прирастают на фиксированную величину при увеличении размера хранилища на определенный шаг. Шаг и прирост зависят от типа дисков:

Чтобы увеличить максимальные значения IOPS и bandwidth и снизить вероятность троттлинга, расширьте размер хранилища при изменении кластера.

Если вы используете хранилище с типом диска network-hdd, рассмотрите возможность перехода на network-ssd или network-ssd-nonreplicated путем восстановления кластера из резервной копии.

ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc.