ключ сортировки - record_id.
Два запроса:
select record_id
from RCMT
where ...
group by record_id
having sum(Sign) > 0
и
select record_id
from RCMT FINAL
where ...
Т.е. разница только в том, что вместо рекомендуемой в документации группировки по record_id с отбором по sum(Sign) > 0 используется нерекомендуемый, но приводимый там же модификатор FINAL. Условие не меняется.
Ожидаю одинаковый результат, однако количество получаемых строк (считал через uniqExact()) может отличаться в десятки раз.
Т.е. FINAL только запускает внеочередное схлопывание и не гарантирует получение результата из схлопнутой таблицы? Или я делаю что-то совсем не так?
final не влияет на Distributed , т.е. если один тот же record_id на разных шардах, то результат Final и sum(Sign) > 0 будет разный
Денис, спасибо за ответ. Чтобы исключить фактор распределённости данных я создал обычную CollapsingMergeTree на одном сервере и скопировал туда данные из одной из боевых ReplicatedCollapsingMergeTree таблиц. Далее сравниваю количество записей разными способами: select count() from CMT - 340 млн записей select count() from CMT FINAL - 160 млн записей select count() from (select record_id from CMT group by record_id having sum(Sign) > 0) - 104 млн записей Это нормально? Причём за полтора часа ни одной записи в этой копии CMT не схлопнулось. Мне кажется, что что-то тут не так, но не понимаю в какую сторону копать. Ключ сортировки record_id имеет тип UUID, ошибочных дублей нет - на все парные записи есть одна с Sign=1 и одна с Sign=-1.
если порядок неправильный -1 1 то CollapsingMergeTree from final дает 1 вроде в VersionedCollapsingMergeTree это по другому, не силен в этих движках если записи в разных партициях, то схлопываний при мержах не будет
Обсуждают сегодня