А, логично, в общем случае да. Принял, значит, велосипедов не изобрели, уже неплохо. Как всегда, спасибо за быстрый ответ!

Всем привет!
Может ли кто-нибудь подсказать?
Есть 2 таблицы, например
содержание 1-й T1:
ID, USER_ID, IAP_NAME, CREATION_DATE -
Содержание 2-й T2
ID, USER_ID, PAY_ID, CREATION_DATE
Это две разные таблицы, где нет связи, но в обоих есть USER_ID

можно ли как то сделать JOIN двух таблицу по USER_ID, но при это в результате вывести так
T1.USERID - не группируя USER_ID,
COUNT( T2.ID WHERE T2.CREATION_DATE <= T1.CREATIONDATE)
Получается получить количество ивентов из таблицы T2 до записи ивента в таблицу T1

если такое в КХ конечно возможно

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

Можно переместить все таблицы с помощью RENAME TABLE

можно переименовать все таблицы rename table db.xxx to db1.xxx
можно остановить кх (или сделать detach database ) и переименовать и поправить файл базы в метадата, переименовать каталог базы в дата

А в ZK не надо делать никаких манпуляций если поменяю файл базы в метадата ?

Нет, путь таблицы в зуукипер и название таблицы базы в кликхаусе это совершенно независимые вещи

Всем привет
Может кто-то встречал полезные статейки,презентации на тему оптимального хранения данных по месту,поделитесь пож-та)
- типы
-движки
- кодеки (стоит ли смотреть в эту сторону или нет)?

Движок как бы один: MergeTree выбирать не из чего.
1. Главное это Order by -- положить похожие значения рядом, тогда сработает компрессия.
все остальные пункты просто жалкие полумеры, мертвому припарки.
2. Не использовать Nullable
3. Все кодировать числами по максимуму (LowCardinality если строки не удалось закодировать в числа)
4. Использовать минимальные типы, влезает в UInt8 - значит UInt8
5. Огрублять значения DateTime, Float, Decimal насколько возможно.
6. Компресия ZSTD по дефолту в конфиге
7. Ни в коем случае не использовать UUID потому что каким-то баранам показалось что в UInt64 коллизии будут якобы влиять на результат
8. Тестировать Codec-и, да Delta помогает, т.е. смотрим на самую жирную колонку и думаем а что если вот так, фигачим тестовую таблицу, переливаем туда миллиард строк, фигачим другую таблицу переливаем туда тот же миллиард из первой и сравниваем и т.д.
ZSTD(2) (3) умеет примерно все теже кодеки сам, но жрет cpu.

По дефолту лз4 вроде, а насколько лз4хс хуже чес зстд на больших уровнях сжатия?

Оно просто быстрее при декомпрессии емнип

ну LZ4 это очень простая и очень быстрая балалайка, он же словарь не пытается строить практически, там кода поди сто байт на асме.
про лз4хс не уверен, насколько я читал по диагонали, он сильно тупее чем zstd

А чем так плох uuid?)

Ну, я недавно уткнулся в скорость декомпрессии и тут лз4хс почти не отстает от обычного лз4 вот и задумался, вообще не хватает статьи на счёт скорости сжатия расжатия реализации алгоритмов в клике

возможно вы правы. Мне к сожалению никогда не была критична скорость разжатия, всегда упираюсь или в hdd диски или в джойны или еще во что-нибудь типа массива на 1000 элементов в каждой строке. Меня всегда заботит место и вопрошающего кмк показалось тоже именно место заботит.

тестировали. хуже + к тому же медленнее после определенного уровня

1 он 16 байт. вам столько надо?
ну и он не сожмется

вообще сжатие надо тестировать именно на ваших данных... ордербай решит компрессию на колонках ключа, а на остальных не поможет

ещё можете увеличить размер блока компрессии... так zstd будет более эффективен