А разве есть вообще смысл в расширении ключа сортировки после поля типа DateTime в случае непрерывного потока событий? Ведь это по сути влияет только на упорядоченность записей, пришедших в одну и ту же секунду (или милисекунду?), а если их меньше 8192, то всё равно блок будет целиком читаться.

Можно удалять записи из мат вью таким образом?

ALTER TABLE default.table_mv DELETE WHERE 1=1;

вот у человек хочет проаггрегировать данные за 5 дней, он напишет datetime>today()-5, и все ненужное отсечется.

что все привязались к этому 8192 я вообще не понимаю... он больше про точечные запросы, к конкретным строкам.

А если аггрегирующий человек сделает тот же запрос к таблице с ключом сортировки (datetime), то у него разве иначе всё ненужное отсекаться будет?

а, вы имеете ввиду что click_id не нужен?
ну так нам сказали же "если по click_id почти искать не будем".
а почти != никогда
а какая там у клик-ид локальность относительно дат - только ванга знает...

Да, я об этом. Меня тут волнует понимание теории, поэтому позвольте нафантазирую другой пример.

Имеется поток каких-то событий (id UInt32, ts DateTime). Если мы делаем ключ сортировки (ts), то в КХ записи хранятся, например, так:

1005, 2021-02-16 16:50:00
1003, 2021-02-16 16:50:01
1006, 2021-02-16 16:50:01
1004, 2021-02-16 16:50:01
1001, 2021-02-16 16:50:01
1002, 2021-02-16 16:50:02

А если делаем ключ сортировки (ts, id), то так:

1005, 2021-02-16 16:50:00
1001, 2021-02-16 16:50:01
1003, 2021-02-16 16:50:01
1004, 2021-02-16 16:50:01
1006, 2021-02-16 16:50:01
1002, 2021-02-16 16:50:02

В таком случае, если у нас не более index_granularity записей на одно и то же уникальное время в ts, то никаких преимуществ ключ сортировки (ts, id) перед (ts) при поиске по id давать не будет, верно?

Code: 556. DB::Exception: Received from localhost:9000. DB::Exception: MySQL SYNC USER ACCESS ERR: mysql sync user needs at least GLOBAL PRIVILEGES:'RELOAD, REPLICATION SLAVE, REPLICATION CLIENT' and SELECT PRIVILEGE on Database

Я хочу вот так подключиться в clickhouse CREATE DATABASE akt109_P6 ENGINE = MaterializeMySQL('192.30.90.152:3306', 'database', 'tesd', '*54958E764CE10E50764C2EECBB71D01F08549980')

Добрый вечер!Я так хочу подключиться в mariadb

но ошибка выходит , можете помощь

что  не так делаю можете подсказать

1005, 2021-02-16 16:50:00
1003, 2021-02-16 16:50:01
1006, 2021-02-16 16:50:01
1004, 2021-02-16 16:50:01
1001, 2021-02-16 16:50:01
1002, 2021-02-16 16:50:02

1005, 2021-02-16 16:50:00
1001, 2021-02-16 16:50:01
1003, 2021-02-16 16:50:01
1004, 2021-02-16 16:50:01
1006, 2021-02-16 16:50:01
1002, 2021-02-16 16:50:02

да вы правы, в общем случае мало пользы, но тут много "если".
если у вас ИД в общем случае растет со временем (например в основном новые пользователи заходят), а активность старых ИД низкая, то польза будет.

при необходимости его можно будет улучшить (или ухудшить) навесив дополнительно skip index на id.

из минусов, только память и то несильно.

Спасибо.

Можете ещё разжевать почему в вашем примере с растущим ИД от ключа сортировки (ts, id) будет польза (без скип индекса)?
Ведь в индексе будут засечки (2021-02-16 16:50:00, 1005), (2021-02-16 16:50:01, 1003), ..., (2021-02-16 19:50:00, 8500), (2021-02-16 19:50:01, 8502) и тогда (у нас не более index_granularity записей с одним и тем же ts) запись с id=1004 может быть вообще в любом из этих блоков, разве нет?

Так у меня же CollapsingMergeTree, если я не укажу click_id он просто все склеит у меня

пепеименуйте/удалите старую таблицу, кх создаст новую с новым конфигом

sql запросы парсит сам клиент. Клиент тоже надо обновлять

заведите issue

да, я херню сказал.
точнее надо говорить так: польза будет если у вас на один таймстемп много ИД (например 20-100 тыс).

так что в вашем случае пользы НЕ будет, кроме разве что потенциально компрессии других данных + запросы с order by/limit, но это копейки.

если будете индекс делать toDate(datetime), id - запросы к ИД будут быстрее, но запросы надо писать как toDate(datetime)=toDate(xxx), либо можно до часов округлять... но это все замедлит запросы к дате.

path + data_path -- это старый способ который позволял положить базу КХ в другой каталог (ему многооо лет)
storage_configuration -- это новый способ, который позволяет настраивать на уровне таблиц

они не связаны

исправлено, нет вам толку класть ID в индекс
https://t.me/clickhouse_ru/204766