Добрый день!
Есть 2 запроса SELECT с Distributed таблиц, решил оптимизировать сделать один запрос через GLOBAL IN, после этого очень выросла нагрузка на CPU.
Подскажите почему так?

А какбы это отдебажить?

вы можете это воспроизвести? или это была однократная ошибка?

Была однократно

ну так запрос изменился, что тут удивительного-то?
Плюс GLOBAL IN создает временную таблицу и рассылает ее в другие ноды.

Спасибо, я вас понял

ну так это все что угодно, вплоть до солнечной радиации

Как-то оптимизировать это можно или забить и оставить 2 запроса?

а вы монетку киньте

🙂
Я про то, есть ли какие-то настройки, корректирующие потребление ресурсов для  GLOBAL IN

конечно все есть и настройки, и запрос можно написать чтобы был один, а не два и при этом без GLOBAL IN, т.е. 488 вариантов перед вами.

Доброго времени суток!
Подскажите пожалуйста, в ClickHouse есть выражение UPDATE для модификации данных
https://clickhouse.tech/docs/ru/sql-reference/statements/alter/update/

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

нет, не планируется.
планируется совершенно иная реализация update/delete, но в далеком будущем, не все доживут.

Мутации это не UPDATE и DELETE. Это такой способ переложить/пережать всю таблицу, всю колонку, чтобы раз в году 31 декабря что-нибудь поправить (типа GDPR), их невозможно использовать в ежедневной бизнес-логике.

По сути для этих целей и интересуюсь.
Есть табличка (под 4Tb)  на 3х шардах.

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

И идеально подошло бы сбросить до значений по умолчанию некоторые очень вариативные колонки, за исключением некоторых значений (т.к. нужны бизнесу)

UPDATE col1 = ‘empty_line’ WHERE col1 NOT IN (…excluded items…) and date <= toDate(now() - toIntervalYear(1))

UPDATE col1 = ‘empty_line’ WHERE col1 NOT IN (…excluded items…) and date <= toDate(now() - toIntervalYear(1))

какой движок у таблицы?

SummingMergeTree
Партиционирование по дню (toYYYYMMDD)
Примерно 15Гб в день

Всем привет!
Подскажите как быть в следующей ситуации:

Есть таблица, куда будут сыпаться очень много событий(типы известны заранее(7шт)), объединеных 4-мя столбцами.
Схема:

datetime | event | id1 | id2 | id3 | id 4
———————————————————
datetime | 1        | 2      | 3   | 4     | 5

События могут повторяться, но по ним можно сагрегировать конечное состояние объекта cityHash(id1, id2, id3, id4)

Хотелось бы иметь MaterializedView, который хранил бы в себе конечное состояние и массив уникальных событий(уникальное - последнее по дате и типу),
что бы в итоге поедставление имело следующий вид:

cityHash(id1, id2, id3, id4)         | events
—————————————————————————
111211212312321312123        | [event1, event2]

Подготовил MaterializedView на основе AggregatingMergeTree, и вроде бы всё хорошо, но только при создании с POPULATE.
Когда события начинают сыпаться в реалтайме - массив events принимает последнее событие.

Ищу подсказки, как быть. Может быть кто - нибудь сталкивался с подобным?
Заранее спасибо.

это вообще из другой оперы. Вам нужно использовать clear column in partition. Или новый ttl group by.
из-за  партиционирования по дню toYYYYMMDD , конечно ничего работать не будет, записи не перепрыгивают из партиции в партицую, и никогда, вообще никогда такого не будет.

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

clear column / ttl group by, я так понимаю не дает возможности сохранить некоторые из значений, он хардкорно сетит дефолт всей колонке в партиции.

AggregatingMergeTree с агрегирующей функцией groupArrayState

https://gist.github.com/den-crane/048ce66bc59f5577d56e42d76934682e
это старый gist.

сейчас можно использовать SimpleAggregateFunction (GroupUniqArray)-- они быстрее.