в 2019 году в issue: https://github.com/ClickHouse/ClickHouse/issues/7895
den crane отвечал на него.
У меня есть похожая ситуация, но чуть другая:
Есть таблица на 200 млн. строк. В ней есть поле ID с типом UUID (это важно). При попытке посчитать количество уникальных ID (требуется именно точное значение)
select uniqExact(ID) from table
запрос либо выполнится (от 30 до 40 сек), либо просто упадет по нехватке памяти буквально через секунду после старта. Если же делать отбор по строке, или числовому полю - все отрабатывает без out-of-memory,
Собственно, вопрос - uniqExact так и остался медленным и нет никакого "импортозамещения" от него? :)
ver: version 22.3.2.1
@den_crane, подскажите, ничего не изменилось с тех пор? Особенно интересует момент с UUID, уж очень медленно по нему считается uniqExact....
нет, ничего, и планов менять нет. Зачем вам Exact? Для того чтобы побороть проблему памяти можно считать кусками select uniqExactIf(a, cityHash64(a)%5=0) from + select uniqExactIf(a, cityHash64(a)%5=1)from .. select uniqExactIf(a, cityHash64(a)%5=4)from
У нас поступают данные и заказчику нужны именно точные количества присланных данных...
Ну это все равно недопустимо долго.....
никто uniqExact не использует для UUID( это же оверкил для аналитики
есть небольшой хак которым иногда пользуемся select uniqExact(device) from ... => 5.2 sec select uniqExact(cityHash64(device)) from ... => 3.4 sec
пробовали его в UInt128 переводить, и прочие бубны - все равно долго...
это коллизии, и неверный результат, проще сразу uniq
это сколько данных должно быть для колизии, пока за 3 года было 0, около 20 млрд уников
в смысле? хеш 64 бит это 50% вероятность коллизии на 2 млрд.
Обсуждают сегодня