У меня есть колонка my_id в которой гуид я буду делать

запросы where my_id = '...' а так же возможно where my_id IN ...

имеет ли смысл использовать guid тип данных вместо строк? или при таком кейсе без разницы

да имеет, тупо меньше места в памяти быстрее сравнение... быстрее запаковка распаковка... меньше читать с диска... но вообще если есть возможность влиять на тип my_id то лучше всего использовать для него какой нибудь snowflake id генерацию и UInt64 для хранения..

а почему UInt64 для хранения лучше? ещё быстрее поиск и тд чем гуиды?

строка GUID/UUID - 36 байт UUID - 16 байт UInt64 - 8 байт

подскажите, пожалуйста я хочу хранить в кликхаусе логи лог формата: время, клиент, сообщение и когда я буду их читать, я буду читать их по конкретному клиенту, т.е. меня не будут интересовать все логи за последний час, день для всех, меня будут интересовать логи конкретного клиента за максимально возможный период, месяц, год и тд каким образом лучше будет выполнить предагрегацию и партиционирование для быстроты выполнения запросов на чтения (естественно с пагинациец) Order by (toStartOfHour(timestamp), client_id); количество клиентов измеряется в сотнях тысяч и ещё, насколько опасным / безопасным будет использования нулабл client_id при том, что он используется в предагрегациях? я получаю логи из vector и не понимаю как мне отсеять лог, в котором нет этого поля, и соответственно в батче летит невалидный запрос тк один из запросов или несколько содержат пустое поле которое должно быть guid, если вдруг такой возможности в векторе нет, можно ли будет это компенсировать за счёт нулабл?

если вы собираетесь читать логи по клиенту, то какой для вас смысл несеть null в client_id? если вы планируете читать все логи, то о какой агрегации идет речь?

я не хочу нести null в client_id, просто вынужден, пока не разберусь как отсеять такого рода логи вектором

а зачем вам в сортировке слева час, если читать вы будете по клиентам? фактически, ваша выборка по клиентам побежит по всем часам

все логи по клиенту т.е. вглубину а не вширь хочу понять, как в таком случае лучше предагрегировать данные например Order by (client_id); сделает так что в таблице логи по клиенту будут рядом, кажется что и селект по этому клиенту быстрее отработает, чем если логи по нему будут раскиданы по всей таблице но при этом предагрегация будет доп нагрузку при инсёртах делать

вы не ответили о том что за агрегация у вас сделайте order by (client_id, нечто по чему внутри клиента агрегируете)

но при этом хотелось бы что бы данные по клиенту лежали в порядке времени timestamp, иначе нельзя будет сделать нормальную пагинацию

сделайте order by (client_id, timestamp) и partition by toYYYYMM(timestamp)

тогда поменяйте местами то, что в вашем примере ну и Null не нужен

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

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

никогда не встречал, чтобы она прям мешалась, а вот случаев "черт, надо переливать теперь в другую таблицу, потому что понадобились запросы where timestamp >=", было замечено гораздо больше )

согласен, поэтому и написал с сомнением в общем я бы потестил и перелить не проблема )

нет, скорее всего такого не будет, тупа select offcet limit

а почему вы такую задачу до "доставанию" строк по client_id делаете на колоночной olap базе, которая вообще-то не для такого построена?

[transforms.app-clickhouse-json-filter] type = "filter" inputs = ["app-json"] condition = '!contains(string!(.query), "api/v1?systemtest") && !contains(string!(.query), "api/v1/?servicestatus")'

partition by toYYYYMM(timestamp) Order by (client_id,timestamp) ;

что

а почему сначала client_id, а потом timestamp

Ну и в кх данные одного аккаунта будут рядом и сожмутся лучше