это не нормально

ъуъ... надо будет в 20.6 посмотреть...

Привет. А не планируется ли сделать impersonation в кх? Видел недавно влили поддержку ldap в мастер. Интересно, как бы теперь bi инструменты подружить с огромной пачкой юзеров.

вроде нет, но я не настоящий сварщик https://github.com/ClickHouse/ClickHouse/blob/master/docs/ru/whats-new/extended-roadmap.md
вам зачем? сделайте feature request

зря вы задаете эти вопросы тут, тут нет девелоперов, сделайте feature request

мне надо подружить КХ со сторонней системой, в которой внезапно решили использовать sha3 для генерации пользовательских id, соответственно теперь предстоит миграция имеющейся базы

проблема в том что sha3 это 256 bit и это больно бъет по размеру базы и перфомансу. 64 бита достаточно для всех, и в этом случае коллизии (group by userid) не важны

сам не в восторге. Там вроде ребята из азиатских стран делали систему, поэтому я, по сути, перед фактом поставлен был. с одной стороны, это однократная операция, с другой, около 200 млрд записей надо обновить

200млрд это фигня для КХ

А сколько полей можно положить в Primary Key для MergeTree? Вроде засечки по первичному ключу лежат в памяти, значит это число ограниченно RAM. Да и как расположить поля в первичном ключе лучше? От менее кардинальным к более ?

все нормально, точнее все знают что это ненормально )
https://github.com/ClickHouse/ClickHouse/pull/13252

эээ какая связь вообще?  drop partition + папки на диске VS ttl оставляет пустые парты.

ну так-то да, хранить столько он может спокойно, а вот делать апдейты, конвертируя и кладя значения в соседний столбец, сможет?

да, я 600млрд апдейтил, только лучше инсерты остановить

да причинно-следственная связь потерялась... я дальше поковырял, коллега имел ввиду удаление через ТТЛ частым таймером... сорри

первичный ключ всегда в памяти целиком (файл primary.idx), и это не засечки(.mrk)!!!! Засечки как раз в кеше 5GB (засечки mrk - файлы у каждой колонки в любом случае)

нужно делать первичный ключ как можно уже. Тут в чатике есть пользователи с триллионами записей и у них первичный ключ жрет 10ки и сотни гигабайт озу. Можно делать primary key отличный от order by -- это помогает.

не, какая-то проблема есть, но напрямую не понять... drop partition в backgroundе идет...
в логах есть такое, но они все вроде для ddlworker

2020.08.24 15:39:36.057408 [ 20927 ] {ec4af1c4-25ac-4634-8ff6-8ce941692a05} <Information> DB.table: Will not drop partition 20200816-6-1, it is empty.

не получается воспроизвести, поживем увидим...

всем привет.
подскажите пожалуйста, совершенно не могу придумать, как бы так реализовать percent of total, чтобы это работало по скорости оптимально

есть таблица:

name
1       
1
1
1
1
2
2
2
3
3

нужен вывод:

name count percent
1        5        50
2        3        30
3        2        20

решение

SELECT
    name,
    count() AS count,
    round(count * 100.0 / (
        SELECT count()
        FROM table
    ), 3) AS percentage
FROM table
GROUP BY name
ORDER BY count DESC;

работает очень долго :(
существует ли какой-то более быстрый путь это сделать?

Всем привет! Можете подсказать, есть для clickhouse возможность настроить прокси, через который нужно ходить в интернет? При попытке писать в s3 получаю таймаут

name
1       
1
1
1
1
2
2
2
3
3

name count percent
1        5        50
2        3        30
3        2        20

SELECT
    name,
    count() AS count,
    round(count * 100.0 / (
        SELECT count()
        FROM table
    ), 3) AS percentage
FROM table
GROUP BY name
ORDER BY count DESC;

Попробовать вынести вложенный запрос наружу?