11238
Обсуждаем ClickHouse
ну как обычно: сон разума рождает чудовищ
Читать полностью…
короче, у вас таблица партиционирована по дате, всего разных дат 2984, в каждой партиции по 2-3 парта
2984 * 2.5 = 7460 партов, т.е. все ровно как задумано, они не смержатся никогда, потому что парты мержатся внутри партиции, т.е. в лучшем случае вместо 2-3 - будет 1.
тот кто создавал таблицу должен был подумать об этом и сделать например месячные, квартальные или годовые партиции - partition by toYYYYMM(stat_dt)
и само использование stat_dt в партициях скорее всего тоже просчет, скорее всего у вас такое же поле с типом DateTime и в запросах используется оно, и партиционировать надо было типа partition by toYYYYMM(stat_time)
order by у таблицы тоже корявый и бессмысленный
select uniq(partition) from system.parts where active and table = ....
Читать полностью…
ну вы и партизан
что показывает
select partition, count() cnt from system.parts
where active and table = ....
group by table, partition
order by cnt desc limit 20
just in case: CoalescingMergeTree пока в нерабочем состоянии
Читать полностью…
вторая черепашка пиздитPARTITION BY stat_dt а колонки stat_dt нету в таблице
не понял, зачем делать фильтрации по датам
если в таблице А все "orders", в таблице B события оплаты "orders", и вам надо в для данных таблицы А проставить условный "payment_date" (например, использовав новый CoalescingMergeTree), то зачем что-то дополнительно проверять? в таблице B могут быть "orders", которых вообще нет в таблице A?
и например вот запрос который показывает проблемные таблицы
Читать полностью…
select database, table, partition, count() cnt from system.parts
where active
group by database, table, partition
order by cnt desc limit 20
а еть дока как правильно смотреть эти ddl?вот я не разраб. как мне понять где ошибка в ддл чтобы показать разрабу что менять?
Читать полностью…
ну типа склеить парты. я в кассандре понимаю как компакшен идёт. в клике пока смотрю, у нас это пишет кафка инжин как я понял и там часто мало строк
Читать полностью…
это в part_log надо смотреть по query_id и new_part и rows
Читать полностью…
system.query_thread_log'
как то отдельно включается в настройках?
вот если я хочу вывести топ запросов. которые пораждают мерджи иза мелких и частных вставок. как это сделать?
да, как вариант, обычный апдейт через инсерт
но так как Replacing тут не подходит, то можно сэмулировать Coalescing через Aggregating
а в чём был смысл такого партиционирования для таблиц весом в меньше гб зачастую?
Читать полностью…
т.е. в данном контексте вы предлагаете использовать AggregatingMergeTree как обход относительно нерабочего подхода CoalescingMergeTree - чтобы данные, которые сходятся по ключу, обновляли значения в остальных столбцах (меняя 0 в флаге is_in_table_B на 1), верно?
Читать полностью…
ок, подливайте каждую ночь данные за вчерашний день из таблицы B в AggregatingMergeTree
раз прилететь могут только orders, которые есть в таблице A, то скан на "вхождение значения" и фокусы с индексами вообще не нужны
понял, тогда ручками через AggregatingMergeTree )
Читать полностью…
В таблице B не может быть orders, которые есть в таблице А - там могут быть только данные из таблицы А
Дополнительная проверка нужна для того, чтобы при проверке на наличие UUID из таблицы A в таблице B забрать меньше данных, отфильтровав какую-то часть по дате (тут как раз я добавил order_by по toYYYYMMDD(timestamp))
(При первичном прогоне это будут крупные блоки данных, но чем ближе к ежедневному инкременту, тем меньше данных надо будет отсмотреть, так как отфильтруется по дате большая часть вещей)
Всем привет!
Стоит такая задача - есть крупная табличка A ReplicatedMergeTree в клике с UUID измерений, которые еще не оплачены.
Есть другая табличка B ReplicatedMergeTree, в которой хранятся уже оплаченные измерения (доп инфа по транзакциям и тд).
Хочется обогатить табличку А информацией из таблицы B (и записать результат в таблицу C), чтобы получить флаг того, что оплата прошла, для дальнейших бизнес-нужд (использовать только табличку B нельзя, так как нужно иметь информацию о том, что измерение не было оплачено). Из-за специфики данных дата оплаты может быть в непредсказуемом промежутке после даты транзакции, то есть фильтрацию тут можно делать только такую, что из таблицы B берем все, что больше или равно по дате минимуму из таблицы A (нет никакого ограничения на сутки/2 недели/месяц).
Так как все измерения имеют уникальные UUID, то хотелось бы узнать, если кто-то встречался с такой проблемой:
1) Как лучше делать проверку на вхождение значения - накинул на таблицу B bloom_filter по полю ID, по которому идет поиск, но мб есть более умный подход по тюнингу (мб тут также кто-то крутил index_granularity для таблицы)
2) order_by по ID не выглядит хорошей идеей, так как UUID значения с высокой кардинальностью.
Заранее спасибо за ответы!
show create table T
смотрим на секцию partition by , если она есть
они могут не компактится по миллиарду причин, надо смотреть ddl таблицы и логи
Читать полностью…
что убрать?
может partitiion by millisecond
у меня разраб говорит что он даже кодом пытался убрать часть партом из таблицы где их 11к на 10 гб. и они не уменьшаются
Читать полностью…
Возможно хватит и квери лога, обычно я беру просто written_rows и count() из query_log и сразу видно мелковставку. Группируясь чаще по пользователю и временным интервалам типа 5/15/60 минут.
Ещё там есть колонка normalized_query_hash, но мне обычно хватает просто пользователя, писатель когда страдает мелковставкой, чаще всего он это делает со всеми запросами.
Но вообще где включаются эти и другие логи не сложно найти в докуметации https://clickhouse.com/docs/operations/server-configuration-parameters/settings
Только trace_log не включайте, на нагруженных кластерах может CPU в полку отправить.