DC
а почему партиции иммутабельны?
Size: a a a
2021 March 10
S
а почему партиции иммутабельны?
;) ну ... пока еще да...
delete \ update введут, перестанут ими быть....
delete \ update введут, перестанут ими быть....
DC
парты иммутабельны, но они и останутся иммутабельны, даже с delete/update
партиции как раз мутабельны, любой инсерт их изменяет.
партиции как раз мутабельны, любой инсерт их изменяет.
DC
это как раз вообще никак не related к вопросу move
S
тьфу =) сорян, что-то спать надо больше
DC
move якобы атомарен на уровне партиции, если move не прерывать посередине.
MM
в документации написано, что КХ не предназначен для запросов к данным по их ID . Я верно понимаю, что основная причина - это гранулярность индекса большая единицы? Или есть ещё какие-то причины?
DT
в документации написано, что КХ не предназначен для запросов к данным по их ID . Я верно понимаю, что основная причина - это гранулярность индекса большая единицы? Или есть ещё какие-то причины?
размер блока сжатия от 65к строк,
те даже при учете что нужна 1 гранула, кх в худшем случае прочтет 65к строк
те даже при учете что нужна 1 гранула, кх в худшем случае прочтет 65к строк
MM
размер блока сжатия от 65к строк,
те даже при учете что нужна 1 гранула, кх в худшем случае прочтет 65к строк
те даже при учете что нужна 1 гранула, кх в худшем случае прочтет 65к строк
а каким параметром это регулируется ?
DT
SELECT * FROM system.settings WHERE name LIKE '%compress_block_size%';
SELECT * FROM system.merge_tree_settings WHERE name LIKE '%compress_block_size%';
SELECT * FROM system.merge_tree_settings WHERE name LIKE '%compress_block_size%';
MM
спасибо!
RK
Ребят, может подсказать кто-нибудь? Есть табличка ReplacingMergeTree, есть в ней дубли. При чём дубли в неожиданных местах, раз в несколько месяцев просто появляются и никуда не исчезают. Запись в таблицу постоянно происходит, ну и схлопывание более-менее нормально отрабатывает, а тут столкнулись с дублями. Подскажите куда копать, как исправить, если возможно, и почему старые записи не оптимизируются одновременно с новыми. Спасибо
Причин, почему в Replacing таблицах дубли много.
Самый первый вопрос, - имеете ли вы дело с дублями потому что они ЕЩЁ не схлопнулись, или потому что для некоторых записей дубли и НЕ ДОЛЖНЫ схлопнуться.
Соответственно, приостановить запись в таблицу, затем либо успешный OPTIMIZE FINAL, либо добавить FINAL к SELECTу, считающему uniqExact по ключу (ну или как вы выявляете дубли). И если дублей после этого не будет - значит по каким-то причинам они ЕЩЁ не схлопывались. ("Ещё" в обычном состоянии может затянуться до бесконечности).
Но если после этого всё равно дубли - значит либо всё-таки предыдущий случай (у кликхауса могли быть причины не до предела мерджить (превышение максимального размера парта, например), либо другая группа причин: эти дубли не могли и не должны были схлопнуться.
Например, не схлопываются, если записи, образующие дубль попали в разные партишны.
Также в случае ReplicatedReplacing таблиц, поверх которых Distributed, с которым мы и работаем, дубли могут получаться, когда записи на разных серверах (т.е. шардирование должно учитывать потребности Replacing таблиц)
Самый первый вопрос, - имеете ли вы дело с дублями потому что они ЕЩЁ не схлопнулись, или потому что для некоторых записей дубли и НЕ ДОЛЖНЫ схлопнуться.
Соответственно, приостановить запись в таблицу, затем либо успешный OPTIMIZE FINAL, либо добавить FINAL к SELECTу, считающему uniqExact по ключу (ну или как вы выявляете дубли). И если дублей после этого не будет - значит по каким-то причинам они ЕЩЁ не схлопывались. ("Ещё" в обычном состоянии может затянуться до бесконечности).
Но если после этого всё равно дубли - значит либо всё-таки предыдущий случай (у кликхауса могли быть причины не до предела мерджить (превышение максимального размера парта, например), либо другая группа причин: эти дубли не могли и не должны были схлопнуться.
Например, не схлопываются, если записи, образующие дубль попали в разные партишны.
Также в случае ReplicatedReplacing таблиц, поверх которых Distributed, с которым мы и работаем, дубли могут получаться, когда записи на разных серверах (т.е. шардирование должно учитывать потребности Replacing таблиц)
DC
размер блока сжатия от 65к строк,
те даже при учете что нужна 1 гранула, кх в худшем случае прочтет 65к строк
те даже при учете что нужна 1 гранула, кх в худшем случае прочтет 65к строк
кмк 65kb не строк
DC
в документации написано, что КХ не предназначен для запросов к данным по их ID . Я верно понимаю, что основная причина - это гранулярность индекса большая единицы? Или есть ещё какие-то причины?
это скорее про то что mysql позволит сделать 100krps сделать, а КХ только 10krps
DT
кмк 65kb не строк
D
в документации написано, что КХ не предназначен для запросов к данным по их ID . Я верно понимаю, что основная причина - это гранулярность индекса большая единицы? Или есть ещё какие-то причины?
это еще от ширины строки прилично зависит
если делаете лукапы типа where ID IN (x,y,z)... будет плохо.
уменьшать гранулярность до одного - можно по памяти не влезть.
в целом работать будет ок, но если у вас платформа которая лукапит данные из таблицы КХ построчно - лучше не надо )
если делаете лукапы типа where ID IN (x,y,z)... будет плохо.
уменьшать гранулярность до одного - можно по памяти не влезть.
в целом работать будет ок, но если у вас платформа которая лукапит данные из таблицы КХ построчно - лучше не надо )
D
https://github.com/ClickHouse/ClickHouse/issues/21607
все, надоело., вот подогнал к митапу =)
все, надоело., вот подогнал к митапу =)
S
Подскажите, нужно сгруппировать по строке до последнего дефиса
DT
Slawka
Подскажите, нужно сгруппировать по строке до последнего дефиса
Ну так с помощью функции для строк вырежьте часть по которой нужно группировать
DT
https://github.com/ClickHouse/ClickHouse/issues/21607
все, надоело., вот подогнал к митапу =)
все, надоело., вот подогнал к митапу =)
https://github.com/ClickHouse/ClickHouse/issues/19320 можно подлинковать :)