─name──────────────────────────┐ │ 20130101_20130131_1_89_16 │ │ 20130131_20130131_90_90_0 │ │ 20130101_20130101_1070_1070_0 │ │ 20130201_20130227_91_166_14 │ │ 20130227_20130228_167_171_1 │ │ 20130301_20130331_172_261_16 │ │ 20130331_20130331_262_262_0 │ │ 20130401_20130429_263_344_15 │ │ 20130429_20130430_345_349_1 │ │ 20130501_20130529_350_431_15 │ │ 20130529_20130531_432_439_2 │ │ 20130601_20130629_440_521_15 │ │ 20130629_20130630_522_527_1 │ │ 20130701_20130731_528_617_16 │ │ 20130801_20130831_618_707_16 │ │ 20130901_20130929_708_789_15 │ │ 20130929_20130930_790_795_1 │ │ 20131001_20131031_796_884_16 │ │ 20131031_20131031_885_885_0 │ │ 20131101_20131129_886_967_15 │ │ 20131129_20131130_968_972_1 │ │ 20131201_20131231_973_1062_16 │ │ 20131231_20131231_1063_1063_0 │ │ 20140101_20140101_1064_1073_3

я же делал optimize table hit

он не сработал

как зафорсить merge?

OPTIMIZE FINAL можно попробовать

Да, не можете, ClickHouse вам об этом намекает своим Exception

вижу. думал, может хитрость какая есть

вижу. думал, может хитрость какая есть

Есть, можно движок дописать чтоб он с ALTER работал ;)

??? :) rename table offers to old_offers, new_offers to offers; RENAME TABLE offers TO old_offers, new_offers TO offers Received exception from server (version 1.1.54343): Code: 48. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Method rename is not supported by storage Dictionary. 0 rows in set. Elapsed: 0.033 sec.

??? :) rename table offers to old_offers, new_offers to offers; RENAME TABLE offers TO old_offers, new_offers TO offers Received exception from server (version 1.1.54343): Code: 48. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Method rename is not supported by storage Dictionary. 0 rows in set. Elapsed: 0.033 sec.

а что тогда с таблицей будет при рестарте КХ? там же руками всё прописано в конфиге

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

пришлось дропнуть старую и создать новую с нужными колонками

OPTIMIZE TABLE hit FINAL Received exception from server (version 1.1.54362): Code: 36. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: FINAL flag for OPTIMIZE query is meaningful only with specified PARTITION. 0 rows in set. Elapsed: 0.038 sec.

нужно указывать конкретное имя партиции

для optimize final

а можете скинуть ссылку

где подробно описывается механизм схлопывания?

для CollapsingMergeTree

где подробно описывается механизм схлопывания?

https://clickhouse.yandex/docs/en/table_engines/collapsingmergetree/

При слиянии, для каждой группы идущих подряд одинаковых значений первичного ключа

вот это смущает

"группы идущих подряд"

то есть если запись была вставлена после миллиона записей

она не схлопнется?

с первой записью

которая имеет такой же pk

Чтобы схлопнулось, надо вставить 2 записи, старую и новую

смотрите

запись под номером 1, pk x, sign 1, lead_id null

затем миллион записей вставлено

затем 2 записи:

pk x, sign -1, lead_id null

pk x sign 1, lead_id y

у меня почему-то не схлопывается

в базе так и висят три записи

если в миллионе записей ее не было, то по идеи все ок должно быть. проблем никаких не было

Записи все в одной партиции?

) ENGINE = CollapsingMergeTree(created_date, (stream_uuid, created_time, user_id, id), 8192, sign)

если created_date одинаковая, то да

вот такое я сейчас наблюдаю

вот запрос который показывает что у записей pk одинаковый

я хотел обновить lead_id у первой

делал optimize table hit

Но не схлопнулись они

Но не схлопнулись они

Надо сделать optimize партиции

И с final

Можно делать 100 оптимайзов таблицы, но каждый оптимайз мерджит часть данных

А не все данные

Я так почти несколько часов мерджил таблицу на 9 ярдов строк

Дубликаты чистил, подчистилось до 6 ярдов строк

select distinct name from system.parts where active and table = 'hit'

а как узнать в какой именно партиции

находится запись

optimze table hits partition 201301 final по идеи так

SELECT DISTINCT name FROM system.parts WHERE active AND (table = 'hit') AND (name LIKE '20130101%') ┌─name──────────────────────────┐ │ 20130101_20130131_1_89_16 │ │ 20130101_20130101_1070_1070_0

вот две таких партиции нашел

сейчас попробую

optimize table hit final '20130101_20130131_1_89_16' Syntax error: failed at position 26: optimize table hit final '20130101_20130131_1_89_16' Expected DEDUPLICATE

см. выше, поправил сообщение

optimize table hit partition '201301' final

ух ты

вот так он отработал

optimize table hit final '20130101_20130131_1_89_16' Syntax error: failed at position 26: optimize table hit final '20130101_20130131_1_89_16' Expected DEDUPLICATE

Это не партиции, а куски в них, выше правильно написали

ну и славненько)

и схлопнул)

счастье было рядом)

а по крону

optimize не вызывается?

с какой периодичностью будут идти схлопывания

не надо OPTIMIZE по крону.

optimize не вызывается?

У нас частый optimize полгода назад стабильно приводил к падению КХ. Если сейчас не так - это было бы круто

Схлопывание кусков не гарантируется и нужно всегда брать с доаггрегацией

я понимаю что в запросах нужно использовать * sign

и having

а как часто идет схлопывание

У нас частый optimize полгода назад стабильно приводил к падению КХ. Если сейчас не так - это было бы круто

Это если реаликация есть. Я делал следующий оптимайз только после завершения предыдущего

Никакого крона :)

а как часто идет схлопывание

Как кх посчитает нужным

Если вставки нет вообще, то может раз в 30 минут например сработать

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

Я вот не совсем понимаю, зачем вам постоянный OPTIMIZE? Почему не делать все как рекомендует дока?

то есть кх сам будет схлопывать

а мы будем просто запросы правильные писать

да, схлопывание происходит при мерже

время мержа не гарантируется

спасибо ребят!

Я вот не совсем понимаю, зачем вам постоянный OPTIMIZE? Почему не делать все как рекомендует дока?

Тяжелый случай :) скажу так, есть таблица в которой после полного схлапывания не больше 100к строк. Но она оооочень жирная. 130 колонок из них 120 - nested колонки.

И скорость обработки запроса должна быть высокая. А несхлопнутые данные убивают скорость

В нашем случае

спасибо ребят!

запросы главное с доаггрегацией, будто никакого схлапывания и нет.

да я понял идею

И скорость обработки запроса должна быть высокая. А несхлопнутые данные убивают скорость

а перед схлопыванием много в ней? Это какая то часто обновляющаяся таблица?

Привет. Кто-то делал запросы в кликхаус из pandas?

Привет. Кто-то делал запросы в кликхаус из pandas?

у меня ребята делали, а чего такое?

а перед схлопыванием много в ней? Это какая то часто обновляющаяся таблица?

Данные туда летят постоянно. Перед схлапыванием там порядка 500к строк

у меня ребята делали, а чего такое?

У меня какие-то разные ошибки, то 500, то хочет создать дата базу в ридонли режиме

У меня какие-то разные ошибки, то 500, то хочет создать дата базу в ридонли режиме

создание базы это sql алхимия делает. Есть у нее бага такая. про 500 надо в логи смотреть

Достаточно ведь скачать библиотеку sqlalcheny-clickhouse, и она автоматом будет использоваться в pandas?