-> MV -> ReplicatedReplacingMergeTree table.
В kafka могут попадать дублирующиеся записи, которые не нужно записывать в CH.
Нужно построить над конечной таблицей несколько ReplicatedSummingMergeTree MV, сейчас при попадении дубликатов в таблицу данные в MV дублируются.
MV с argMaxState работает медленно ((
Как можно избежать вставки дублирующих записей из kafka?
КХ тут не поможет. Надо делать до.
Дублирующие записи в разных батчах прилетают в кх? Если в одном, то разве в первом mv их нельзя исключить? Если в разных, то только конечным запросом их убирать (даже если и появилась возможность вешать mv над mv, но replacingmergetree работает в фоне, поэтому поставив над ним summingmergrtree, туда в любом случае улетят дубликаты, так как фон не успеет отработать)
Да, прилетают в разных батчах. Как можно отфильтровать уникальные записи по PK в рамках одного батча с помощью MV?
Какой фон? Mv над mv над mv получает записи от инсерта. Не важно сколько там глубина. Не от таблицы.
Сорри, с общим принципом наврал, но с конечным результатом нет.
В mv поставить group by.
Спасибо!
Сейчас меня опять поругают,) но я бы попробовал (а вдруг сработает) сделать в mv not in из view над таблицей (которая после mv) . Если все оттюнить и вставка не очень масштабная, то есть вероятность, что может помочь.
Ага сработает если один инсерт в день. Ну нельзя проверить есть такой ключ в таблице или нет. Это слишком медленно. И не работает для многопоточности. Два одновременных инсерта навставляют дубликаты.
Я не решение предлагал, а вариант, который стоит рассмотреть. Мы не знаем какие данные, какие дубликаты, какой трафик льётся. Поэтому есть вероятность, что дубликаты по дате, и если групбаем убирать внутри батча, то останутся только в соседних. Есть вероятность, что там же и ключи, то выборка двух-трех батчей по ключам будет не слишком дорогая. Ну и есть вероятность, что там один поток на шард.)
Обсуждают сегодня