b
а можно как-то закверить графитовые правила роллапа? А то я не уверен что они применились
Size: a a a
2020 August 26
DC
а можно как-то закверить графитовые правила роллапа? А то я не уверен что они применились
Применяются при рестарте.
И Кх не мержит старые партиции сам. Точнее шедулер мержей не знает что надо делать rollup, он просто исходит из обычного алгоритма мержей. Поэтому optimize
И Кх не мержит старые партиции сам. Точнее шедулер мержей не знает что надо делать rollup, он просто исходит из обычного алгоритма мержей. Поэтому optimize
ZZ
Добрый вечер, а вот у меня ReplacingMergeTree, и в нем указан и primary key на пару ключей, и ордер бай на ту же пару, а в таблице дупликаты. Optimize отрабатывает быстро и безрезультатно.
b
Применяются при рестарте.
И Кх не мержит старые партиции сам. Точнее шедулер мержей не знает что надо делать rollup, он просто исходит из обычного алгоритма мержей. Поэтому optimize
И Кх не мержит старые партиции сам. Точнее шедулер мержей не знает что надо делать rollup, он просто исходит из обычного алгоритма мержей. Поэтому optimize
Дело в том что я правила заимпортил вот так из отдельного файла, но не уверен есть ли от этого какой-то эффект:
Вот и хочу спросить у запущенного сервера, какие у него там правила на конкретной таблице.
<include_from>/home/user/var/clickhouse-server/rollup.xml</include_from>
<graphite_rollup incl="graphite_rollup" replace="replace"></graphite_rollup>
Вот и хочу спросить у запущенного сервера, какие у него там правила на конкретной таблице.
b
А так то я дефолтную ф-ю поменял с max на sum, так что это и так был мусор.
b
Внутри
rollup.xml вот такое:<yandex>
<graphite_rollup>
<pattern>
...
</pattern>
<pattern>
...
</pattern>
<default>
...
</default>
</graphite_rollup>
</yandex>
ZZ
Добрый вечер, а вот у меня ReplacingMergeTree, и в нем указан и primary key на пару ключей, и ордер бай на ту же пару, а в таблице дупликаты. Optimize отрабатывает быстро и безрезультатно.
Что делать, должно ли быть так?
DC
Добрый вечер, а вот у меня ReplacingMergeTree, и в нем указан и primary key на пару ключей, и ордер бай на ту же пару, а в таблице дупликаты. Optimize отрабатывает быстро и безрезультатно.
Ну primary key тут вообще не при делах, учитывается только orderby. Мержи идут только в рамках партиции. Схлопывания побочный продукт мержей.
ZZ
партишн по дате. Дупликаты соответственно принадлежат к одной дате.
ZZ
мержи идут во время инсерта? - не случились видать. Почему?
DC
мержи идут во время инсерта? - не случились видать. Почему?
мержи случаются evetual, т.е. возможно никогда
DC
инсерт подталкивает шедулер мержей проверить не пора ли мержить
ZZ
и оптимайз подталкивает. Но не смержилось.
DC
шедулер мержей просыпается раз в 5 сек и проверяет не пора ли мержить
ZZ
данные несмерженные много дней
DC
и оптимайз подталкивает. Но не смержилось.
сколько партов в партции?
ZZ
селект возвращает 2 куска одинаковых, кусками.
DC
данные несмерженные много дней
вот 300 партов в партиции это несмерженные парты, а дубликаты это не то
DC
селект возвращает 2 куска одинаковых, кусками.
where active!
ZZ
ага...