да так должно быть, потому что .mrk файлы весят меньше и кешируются в памтяи и позволяют быстрее parts для чтения отбросить

INSERT INTO ... SELECT remote() ...
https://clickhouse.tech/docs/en/sql-reference/table-functions/remote/

спасибо!

...

Ch не грузится 🙂 как поднять?

сори проблема была в том что metadata грузилась от 20.5 на версии 20.3

;) я бы оставил сообщения, только поправил бы текст обшики без стектрейсов

всем привет, можно ли как-то организовать архивировние более старой информации и сбрасывать на сервер с медленными дисками? и если да, то можно какие-то рабочие примеры, только начинаю админить clickhouse

поищите в документации clickhouse TTL

Скорее tieried storage, ссылка та же, но чуть ниже по тексту

Привет! Есть такой вопрос:
Версия Clickhouse 20.5. Есть таблица mergetree. Делаю select и вижу, что таблица пустая. Смотрю в system.parts и вижу, что имеется два парта. На таблицу настроен ttl, парты должны были потереться. Делаю alter table materialize ttl, в таблице system.mutations вижу, что операция завершена. При этом старые парты всё равно не удалились. Аналогично если делаю операцию alter table modify ttl, а затем optimize final. Также пробовал system start ttl merges для этой таблицы, не помогло. Почему так?

какой status у parts стоит? 1?

Да, активные

думаю что это хороший повод завести issue в github и подождать ответа разработчиков
возможно мы с вами не понимаем в какой момент должны отрабатывать удаления по TTL

в system.mutations
есть вообще  в перечне партов парты которые в system.parts видите?

ну либо у вас все таки TTL не так настроен как вы думаете...

В system.mutations есть колонки parts_to_do и parts_to_do_names, как вы и говорите. Там эти парты были указаны. Всё так. Но фактического удаления всё равно не произошло.

Смотрю сейчас DDL, там:
...
ENGINE = MergeTree()
PARTITION BY toYYYYMM(TimeStamp)
ORDER BY TimeStamp
TTL TimeStamp + toIntervalMonth(6)
...

При этом партиции, которые не удаляются, следующие: 201903 и 201904. То есть явно прошло 6 месяцев.

Не понимаю 🙂 issue заведу, спасибо

Если я выполняю system start ttl merges или optimize table final, чтобы форсировать удаление старых партов, процессы удаления сразу запускаются фоном ведь? Нет необходимости ждать таймаут, указанный настройкой merge_with_ttl_timeout?

коллеги такой вопрос по функциям агрегации. Я вылетел с Sizes of columns doesn't match, распечатал блок, что мы имеем? media_source String String(size = 9565051), а потом SUM(launches_count) AggregateFunction(sum, Int64) AggregateFunction(size = 8427764),. т.е. падает он обоснованно, но как получается что функция возвращает меньше результатов? это какая то особенность работы с зануленными полями?

Здравствуйте, столкнулись с аналогичной ситуацией, после апдейта на 20.5.3.27, перестал работать боевой запрос. Что самое интересное, подзапросы отрабатывают по отдельности нормально, а UNION ALL сыпет такой ошибкой даже если взять два идентичных подзапроса.
Структурно запрос выглядит так:

SELECT ... FROM data.table_a
  INNER JOIN (
             SELECT ...
             FROM data.table_b
             WHERE ...
             ) cur USING (a, b)
WHERE ...
         
UNION ALL

SELECT ... FROM data.table_a
  INNER JOIN (
             SELECT ...
             FROM data.table_b
             WHERE ...
             ) cur USING (a, b)
WHERE ...

Падает даже с идентичными частями до и после UNION ALL. При чем если убрать в любой части один INNER JOIN начинает отрабатывать без ошибки. Есть какие-то workaround или придется откатываться назад?

Привет! мы не нашли решения и откатили назад. Ситуация идентичная