Не обязательно TTL использовать, можно использовать политику на основе занятного места (дефолтно доля  свободного равна 0.1)
далее создаете таблицу с настройкой SETTINGS storage_policy = 'your_policy_name' и он будет писать новые парты (если помещаются, на самый верхний volume, а потом когда там заканчивается место перемещать парты на другие volumes. TTL ... TO DISK|VOLUME позволяет более точно насраивать это поведение, но не обязательно использовать их. Поправьте меня если я был не точен где-то

а какие данные он будет переносить на другой диск? я хочу что бы он переносил только старые данные, т.е. сейчас ssd диск заполнен на 96%, если я добавлю свой конфиг - disk.xml и перезапущу сервер
то он должен будет уже какие-то данные перенести на другой диск, т.к. диск уже заполнен больше 0.1

Настройка применима к каждой отдельной таблице, по умолчанию применяется настройка default. Эту настройку для таблицы можно глянуть
SELECT
   database,
   name,
   data_paths,
   storage_policy
FROM system.tables
LIMIT 10
Попробуйте с тестами на новой табличке с небольшим кол-вом данных, просто я не смогу поправить ваши конфиги как вам надо,
если у вас не будет достаточно свободного места для нового парта - он начнет сразу записывать его на "следующий" volume, все остальные переносы будут выполнены в фоне "когда-нибудь", так же вы можете вручную переносить парты|партиции через ALTER TABLE (например перенести на HDD старые данные вручную)


https://clickhouse.tech/docs/ru/sql-reference/statements/alter/#alter_move-partition
https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-multiple-volumes

Всем привет. Ребят, подскажите пожалуйста, что я делаю не так.

select id, src_id, param_date, param
from telemetry_common
where src_id in (260,261,66)
group by id, src_id, param_date, param
order by param_date desc
limit 1 by src_id;

выполняется ~5.6 сек (моя последняя попытка оптимизировать)


Второй тупой вариант:

select  id, src_id, param_date, param
from telemetry_common
where src_id in (260)
order by param_date desc
limit 1
union all
select  id, src_id, param_date, param
from telemetry_common
where src_id in (261)
order by param_date desc
limit 1
union all
select  id, src_id, param_date, param
from telemetry_common
where src_id in (66)
order by param_date desc
limit 1

выполняется 0.5 сек 😂

как правильно написать первый запрос, чтобы он выполнялся быстрее?
задача получить последние записи (по колонке param_date) для списка src_id
провёл много часов, пытаясь разобраться, но без результата.

Всем привет.
Народ, а подскажите плиз, можно ли в мат вьюхах использовать сабселекты или джойны?

У меня есть таблица и я хотел сделать вьюху типо для отчёта, которая собирает данные из этой же таблицы и складывает в отдельную. И в селекте на создание вьюхи мне нужно будет обогащать данные данными из этой же таблицы. Т.е. у меня в запросе на вьюху будет либо сабселект, либо джойн на эту же таблицу.

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

Всем привет. Ребят, подскажите пожалуйста, что я делаю не так.

select id, src_id, param_date, param
from telemetry_common
where src_id in (260,261,66)
group by id, src_id, param_date, param
order by param_date desc
limit 1 by src_id;

выполняется ~5.6 сек (моя последняя попытка оптимизировать)


Второй тупой вариант:

select  id, src_id, param_date, param
from telemetry_common
where src_id in (260)
order by param_date desc
limit 1
union all
select  id, src_id, param_date, param
from telemetry_common
where src_id in (261)
order by param_date desc
limit 1
union all
select  id, src_id, param_date, param
from telemetry_common
where src_id in (66)
order by param_date desc
limit 1

выполняется 0.5 сек 😂

как правильно написать первый запрос, чтобы он выполнялся быстрее?
задача получить последние записи (по колонке param_date) для списка src_id
провёл много часов, пытаясь разобраться, но без результата.

Всем привет. Ребят, подскажите пожалуйста, что я делаю не так.

select id, src_id, param_date, param
from telemetry_common
where src_id in (260,261,66)
group by id, src_id, param_date, param
order by param_date desc
limit 1 by src_id;

выполняется ~5.6 сек (моя последняя попытка оптимизировать)


Второй тупой вариант:

select  id, src_id, param_date, param
from telemetry_common
where src_id in (260)
order by param_date desc
limit 1
union all
select  id, src_id, param_date, param
from telemetry_common
where src_id in (261)
order by param_date desc
limit 1
union all
select  id, src_id, param_date, param
from telemetry_common
where src_id in (66)
order by param_date desc
limit 1

выполняется 0.5 сек 😂

как правильно написать первый запрос, чтобы он выполнялся быстрее?
задача получить последние записи (по колонке param_date) для списка src_id
провёл много часов, пытаясь разобраться, но без результата.

Привет! Есть такой вопрос:
Версия Clickhouse 20.5. Есть таблица mergetree. Делаю select и вижу, что таблица пустая. Смотрю в system.parts и вижу, что имеется два парта. На таблицу настроен ttl, парты должны были потереться. Делаю alter table materialize ttl, в таблице system.mutations вижу, что операция завершена. При этом старые парты всё равно не удалились. Аналогично если делаю операцию alter table modify ttl, а затем optimize final. Также пробовал system start ttl merges для этой таблицы, не помогло. Почему так?

rows=0 у партов?  такое поведение было изначально. Парты остаются с 0 строк.

Господа, подскажите по sql, есть вот такой запрос

select toYYYYMMDD(date) dt, count() total
    from request_log
    where date between '2020-06-01' and '2020-06-30'
    group by dt

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

Да, rows =0
То есть мне чтобы эти парты потереть, дропать самому через alter drop partition? Иначе я так понимаю, они с rows=0 просто продолжают лежать на диске

Отвечаю сам себе. Существенный прирост в скорости дало доп условие по дате. Если ограничить выборку последними сутками, то запрос выполняется в 4 раза быстрее.

Отвечаю сам себе. Существенный прирост в скорости дало доп условие по дате. Если ограничить выборку последними сутками, то запрос выполняется в 4 раза быстрее.

Order by dt with fill

<Error> Retention.Events_Local (ReplicatedMergeTreeRestartingThread): Couldn't start replication: Replica /clickhouse/tables/1-2/Events_Local/replicas/1 appears to be already active. If you'r
e sure it's not, try again in a minute or remove znode /clickhouse/tables/1-2/Events_Local/replicas/1/is_active manually. Code: 224, e.displayText() = DB::Exception: Replica /clickhouse/tables/1-2/Events_Local/replicas/1 appears
to be already active. If you're sure it's not, try again in a minute or remove znode /clickhouse/tables/1-2/Events_Local/replicas/1/is_active manually, Stack trace (when copying this message, always include the lines below):

0. Poco::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) @ 0x104191d0 in /usr/bin/clickhouse
1. DB::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) @ 0x8fff8ad in /usr/bin/clickhouse
2. ? @ 0xda714e7 in /usr/bin/clickhouse
3. DB::ReplicatedMergeTreeRestartingThread::tryStartup() @ 0xda6f4b8 in /usr/bin/clickhouse
4. DB::ReplicatedMergeTreeRestartingThread::run() @ 0xda6ff18 in /usr/bin/clickhouse
5. DB::BackgroundSchedulePoolTaskInfo::execute() @ 0xcfe9619 in /usr/bin/clickhouse
6. DB::BackgroundSchedulePool::threadFunction() @ 0xcfe9c42 in /usr/bin/clickhouse
7. ? @ 0xcfe9d72 in /usr/bin/clickhouse
8. ThreadPoolImpl<std::__1::thread>::worker(std::__1::__list_iterator<std::__1::thread, void*>) @ 0x902526b in /usr/bin/clickhouse
9. ? @ 0x9023753 in /usr/bin/clickhouse
10. start_thread @ 0x76db in /lib/x86_64-linux-gnu/libpthread-2.27.so
11. clone @ 0x12188f in /lib/x86_64-linux-gnu/libc-2.27.so

@den_crane день добрый!
а это нормальная впринципе практика для кликхауса создавать N таблиц с одинаковым набором данных, но с разными ключами сортировки?
или как это обычно организуется?