Как стать автором
Обновить

Комментарии 13

По поводу виртуальных машин. Почему вы решили использовать виртуальные машины, а не отдельные инстансы clickhouse (или даже контейнеры) со своим IP-адресом? В общем случае миграция инстанса виртуалки (с данными) и миграция каталога с данными между двумя серверами практически одно и то же, но меньше слоёв операционных систем.

Мы хотели использовать отдельные инстансы ClickHouse, но на тот момент у нас в наличии не было необходимого количества серверов и мы смогли бы реализовать только круговую репликацию, что нас не устраивало. В обозримом будущем мы планируем переехать на отдельные инстансы ClickHouse. Из-за этого ограничения мы как раз и пытались уместить все на существующем железе.
Контейнеры не рассматривали изначально, для подготовки стабильного решения с их использованием, потребовалась бы дополнительное время на аналитику, к сожалению которого у нас не было. Мы уперлись в ограничения прошлой инсталляции кластера и нужно было быстрее переезжать в новый.

Он имел в виду запустить два Кликхауса на одной ОС с разными конфигами, IP и данными в разных директориях. В данном случае не нужно рулить дополнительной ОС и платить цену виртуализации.

Также использование памяти будет более гибким если вдруг один инстанс получит тяжелый запрос. В случае ВМ он будет ограничен только тем что ей выделили...

Да, не так понял вопрос…

Такой вариант не рассматривался. Это связано с нашей организацией работы с конфигурацией виртуалок. Для поддержки такого вида инсталляции нужно было переделать ansible-роль, и поддерживать ее отдельно. Это привело бы к отличиям этой инсталляции от других, а работать с ней может коллега из другой команды.

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

По памяти у нас стоят ограничения в самом ClickHouse, как дополнительный этап отлова не оптимальных запросов на раннем этапе.

в моих тестах с 2tb пожатых данных виртуализация давала +20% скорости итогового просчета, найти секрет такого непонятного тюнинга я не смог в короткое время

Для понимания упираюсь только в процессор, диски m2 в простое

А 1.2 тб — это сырых или пожатых данных? Если пожатых — то сколько ж там ссд, если это хранится хоть сколько-то долго?

Одним из больших минусов что дефолтной круговой, что вашей, схемы я вижу кросс влияние шардов друг на друга — запись на шард 2 тормозит чтение на шарде 1. А учитывая то, что клик считает (и это в плане дизайна вполне разумно) что он на машине один и все ресурсы его — на hdd я бы такое точно не стал делать, а на ssd не чувствуете эффекта конкуренции между шардами?

1.2 Tб сырых данных, на одну ноду/шард приходится ~4Тб SSD.

Храним по-разному, есть потоки данных которые хранятся постоянно и данные просто дописываются, есть с ограниченным временем жизни от пары недель и больше. Пока соблюдается баланс по тому за какой период могут быть нужны данные, но это тоже все обсуждаемо и изменяемо, появится потребность хранить дольше, начнем хранить дольше. Для каких-то данных используется репликация, есть данные, где она не нужна. В этом кстати есть своя сложность и гибкость одновременно, кластер можно настроить именно так как нам нужно, но для этого нужно потратить какое-то время на изучение документации.

Про размещение на HDD я с Вами полностью согласен. Прошлая инсталляция как раз и жила на HDD с SSD кешем и там были замечены странности и влияние на другие виртуалки. Пришлось добавлять лимиты по IOps, что конечно сыграло не в лучшую сторону для ClickHouse. С SSD были опасения, что можем упереться, но пошли на этот шаг, на данный момент эффекта не заметили. У нас есть понимание как можно расширить кластер, увеличить ему ресурсов и в дальнейшем переехать на отдельные инстансы. Скорее сейчас ловим какие-то другие проблемы из-за увеличения объема данных и количества запросов, но вот в SSD пока не упираемся.

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

Думается что с быстрыми NVMe SSD КХ упирается в процессор на распаковке партов из LZ4/ZSTD а не в диск уже... у LZ4 вроде около нескольких Гб/с на ядро. И 500мб на сжатие, а SSD уже умеют в 5-7Гб/с

То есть в принципе вы сейчас пришли к тому, что альтинити кликхауз оператор дает из коробки :)

Не все используют и любят k8s

Как альтернатива это интересное решение, но потребовало бы дополнительного времени на стабилизацию и готовность предоставить как стабильный сервис. Это один из вариантов дальнейшего развития нашего кластера и мы доберемся до его аналитики.

Хотел спросить, зачем сделано по несколько виртуалок, но понял, что @blind_oracleуже указал на альтернативный способ управления, который кажется более приемлимым, когда несколько инстансов CH запущено с разными --config. Так действительно выглядит более гибко, если один из шардов случайно начал перевешивать по нагрузке.

/*offtopic*/ Когда зашёл прокомментировать, а тут уже все знакомые лица...

Хочу поинтересоваться, возможно что-то не допонимаю. А RAID1 на нодах не решал вопрос сохранности и быстрого восстановления в случае выхода ноды из строя?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.