Коллеги, подскажите можно ли собрать “сложный” кластер? Например, часть таблиц

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

Да, ноды в кх полностью независимы, одна и та же нода может участвовать в нескольких кластерах

а какой профит пытаетесь достичь? какое у вас окружение? облака? bare-metal? сколько у вас серверов в кластере планируется? обычно несбалансированные кластера получаются когда bare-metal и железо просто докупается по мере необходимости и новые данные просто льются на новые сервера, а старые данные хранятся на старых но это надо пару лет чтобы кластер рос линейно если сразу делать "не сбалансированный кластер", может проще сделать multi volume storage policy по дискам? https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-multiple-volumes_configure ?

Идея такая чтобы иметь горячие данные на одной группе серверов с ssd и холодные данные которые нужны редко на 2х серверах с большими дисковыми полками. Железо, не облака.

тут проблема в том как вы данные будете между серверами переливать с горячего на холодное всякие storage_policy они в рамках одного сервера работают между разными дисками... можно конечно изголяться и делать что-то типа INSERT INTO slow_distributed_table SELECT ... FROM hot_local_table WHERE _partition_id='YYYYMM' + ALTER TABLE hot_local_table DROP PARITITION 'YYYYMM' но это не транзакционно и будет окно когда в медленных дисках и в быстрых данные дублирются ну как немного костыльный вариант "медленные сервера с полками" на них можно minio поднять и в горячих серверах сделать s3 диски https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-s3 но будет хуже data locality, CPU на дисковых полках обсчетами никакими заниматься не будет и будет простаивать лучший вариант "экономить на железе" это пара NVMe на 1-2Tb в JBOD storage_policy под быстрые данные и пара HDD на 5Tb+ тоже в JBOD под холодные но я так понимаю "сервера" у вас уже давно есть?

данных у вас живых уже сколько?

Как раз размышлял над этой проблемой Пришел к мысли, что возможно не S3 делать на "дешёвых серверах с HDD", а прокидывать блочное устройство по iSCSI в сервер, и по storage_policy туда переливать. В случае заполнения холодного - делаем новые сервера с iscsi, добавляем в виде диска в кликхаус. А на старом сервере, где был iSCSI-target поднимаем кликхаус, добавляем его в кластер и аттачим данные с локального диска, которые ранее по iscsi экспортили на другой хост. Получается полноценный clickhouse сервер с холодными данными с практически моментальной миграцией При этом основные сервера кликхауса , на которые идёт вставка и горячие запросы, останутся довольно мощными машинками, с SSD. А холодные данные через полгода-год уедут на дешёвые hdd/cpu Плюсы в сравнении с s3 - можно переподключить данные впоследствии как обычный диск. Ну и работать мне кажется должно побыстрее s3, как минимум будет работать дисковый кэш Задача - смигрировать старые данные на дешёвый сторадж Сейчас холодной хранилки нет вообще, в существующее железо добавить нельзя HDD (все слоты 2.5 и забиты SSD максимального объема) Можно было бы взять серверов с HDD, сделать на старых серверах detach старых партиций, переместить их на новые дешёвые сервера с hdd и там аттачнуть, но это полу-ручная работа, которую нужно контролировать

да, если железо позволяет, можно iSCSI, но тут тоже наверное надо беспокоиться можно или нет делать ReadWriteMany режим доступа или надо нарезать диски через thin provisioning опять же балансировка нагрузки в кубах iSCSI CSI пока малость сырой https://github.com/kubernetes-csi/csi-driver-iscsi можно наверное через kubernetes и https://github.com/minio/directpv CSI сделать но там под капотом XFS и опять же непонятно что с ReadWriteMany чтобы CPU на HDD полках можно было бы задейтвовать...

тут нет задачи с readWriteMany, холодная хранилка будет не на одной машине хотим к каждому серверу клика (dell powerage 8x4Tb SSD) докинуть сторадж, просто добавив нод с 4x16Tb HDD

а какой сетап? puppet/ansible/salt? или кубы? просто потом переключение этого самого storage, не видится чем то легким ну и ваш CPU на cold storage IMHO будет обслуживать iSCSI довольно шустро

в кубы это не потащили из-за размера данных, достался сетап на дедиках к примеру на pvc в цефе это не выживет, малейшая ребалансировка - и перемещение сотни теребайт данных положит цеф можно конечно сделать отдельные ноды с локал-стораджем под кликхаус в любом случае миграция такого объема данных - довольно затратная операция, что по времени, что по серверам (и деньгам соответственно) поэтому нарастить cold storage через сетевое блочное устройство показалось меньшим из зол

А может есть какой-то способ вытеснять парты на другой сервер CH, с медленными дисками, отличны от detach/scp/attach ? Аналогично как они вытесняются на другой сторадж.

Скорее нет, чем есть Можете чуть подсластить пилюлю с помощью ALTER TABLE xxx FETCH PARTITION FROM или попробовать https://github.com/ClickHouse/ClickHouse/pull/17871