11238
Обсуждаем ClickHouse
Посидеть в тени пару часов 3500, мороженое
Читать полностью…
Отнести письмо на почту 3000, конфеты в бонус
Читать полностью…
Забрать коробку и передать 4500, с меня тортик
Читать полностью…
Привет.
Вопрос про запросы к distributed-таблицам с использованием Query Parameters.
tldr: почему при запросе к distirbuted-таблице с использованием QueryParameters клику не получается определить нужный шард исходя из запроса, а "хардкодя" параметры в сам запрос, клик понимает в какие шарды нужно сходить
У меня есть кластер состоящий из 5 шардов. Версия клика 24.1.2.5
Я выполняю следующие запросы
1. Создание таблиц
create table test.yakovlev_test_local on cluster c5 (
id int,
height int
)
Engine = MergeTree
order by tuple();
create table test.yakovlev_test on cluster c5 as test.yakovlev_test_local
engine = Distributed('c5', 'test', 'yakovlev_test_local', id);
insert into test.yakovlev_test
select number, randUniform(50, 100)::int as height from numbers(1000000000);
select * from test.yakovlev_test
where id = 5;
**some logs here**
[hostname-s2-1] 2025.09.02 20:20:55.143024 [ 859991 ] {96ab5ac7-a72c-4152-a849-419ef4e8dc6c} <Debug> StorageDistributed (yakovlev_test): Skipping irrelevant shards - the query will be sent to the following shards of the cluster (shard numbers): [1]
┌─id─┬─height─┐
1. │ 5 │ 52 │
└────┴────────┘
**some logs here**
1 row in set. Elapsed: 0.041 sec. Processed 200.00 million rows, 800.00 MB (4.88 billion rows/s., 19.54 GB/s.)
Peak memory usage: 233.62 KiB.
select * from test.yakovlev_test
where id in (1,100,105,1001);
**some logs here**
[hostname-s2-1] 2025.09.02 20:22:44.331452 [ 859991 ] {160cca24-fd18-4a58-829d-9f5817023d5d} <Debug> StorageDistributed (yakovlev_test): Skipping irrelevant shards - the query will be sent to the following shards of the cluster (shard numbers): [1, 2]
**some logs here**
┌───id─┬─height─┐
1. │ 1 │ 86 │
2. │ 1001 │ 52 │
└──────┴────────┘
**some logs here**
┌──id─┬─height─┐
3. │ 100 │ 50 │
4. │ 105 │ 69 │
└─────┴────────┘
**some logs here**
4 rows in set. Elapsed: 0.089 sec. Processed 400.00 million rows, 1.60 GB (4.50 billion rows/s., 18.01 GB/s.)
Peak memory usage: 475.17 KiB.
set param_ID = [1,100,105,1001];
select * from test.yakovlev_test
where id in {ID:Array(Int)};
SET param_ID = '[1, 100, 105, 1001]'
Query id: 858d378d-6431-4f2d-a48c-3959fdc1c37d
**some logs here**
0 rows in set. Elapsed: 0.044 sec.
SELECT *
FROM test.yakovlev_test
WHERE id IN ({ID:Array(Int)})
Query id: ec172c10-d50b-4364-8f8d-be0420607149
**some logs here**
[hostname-s2-1] 2025.09.02 20:23:12.456240 [ 859991 ] {ec172c10-d50b-4364-8f8d-be0420607149} <Debug> StorageDistributed (yakovlev_test): Unable to figure out irrelevant shards from WHERE/PREWHERE clauses - the query will be sent to all shards of the cluster
**some logs here**
┌───id─┬─height─┐
1. │ 1 │ 86 │
2. │ 1001 │ 52 │
└──────┴────────┘
**some logs here**
┌──id─┬─height─┐
3. │ 100 │ 50 │
4. │ 105 │ 69 │
└─────┴────────┘
**some logs here**
4 rows in set. Elapsed: 0.111 sec. Processed 1.00 billion rows, 4.00 GB (9.02 billion rows/s., 36.10 GB/s.)
Peak memory usage: 2.05 MiB.
Забрать коробку и передать 4500, с меня тортик
Читать полностью…
в 25.8.1 баг, надо выключить default кластер (т.е. у своего remote_servers сделать replace)
https://github.com/ClickHouse/ClickHouse/issues/86434
/channel/clickhouse_ru/429571
ON CLUSTER запросы идут через кипер. insert идет напрямую. Смотрите в сторону сетевой связанности кипера и кластера. Возможно, у вас в конфигах указаны dns имена и их resolve проходит долго, отсюда задержка. Может еще что в настройках.
Читать полностью…
заведите issue без стектрейса непонятно...
Читать полностью…
нормальный батч это миллион строк
батчи по 10-20k строк маленькие
100k-1kk строк, в итоге где то так плавают все...
вставляю JS клиентом для клика
• батч 50k строк
• периодичность ~10 секунд
• 20 воркеров
• MergeTree
Анализатор выключили перед обновлением, но возможно проблема в том, что запрос состоит из 3 cte, которые на разные кластера смотрят
2 из них той же версии, 1 - 23.8 (не смогли обновить его)
в 24.8 исправили и оно ломаться начало или в чем исправление заключается?
Читать полностью…
select version()
похоже на баг когда КХ не удалял неактивные парты
И какое оптимальное количество строк в блоке? От 100-1000??
Читать полностью…
вариантов много но ни один не соответсвует теме форума
Читать полностью…
Какая-то путаница в репозитории чтоль, не могу понять.. почему-то в master ветке есть метод Clear() для очистки батча. А в релизной верси 2.5.1 нет..Подскажите по репе, в мастере что у кх, в прод лучше не брать??
Читать полностью…
Вопрос: почему в запросе 3.3 клику не удалось понять в какие шарды сходить за данными, несмотря на то, что в запросе 3.2 точно такой же запрос без QueryParameters удалось оптимизировать и выполнить только на некоторых шардах?
Данное поведение приводит к тому, что если одна из 5 машин по какой-то причине недоступна, в результате получим ошибку, несмотря на то, что у клика была возможность достать нужные данные.
Возможно такое поведение было пофикшено на более высоких версиях? Кто-то сталкивался с таким?
Возможно можно как-то переписать запрос, чтобы с QueryParameters он стал ожидаемо выполняться?
<?xml version="1.0" ?>
<clickhouse>
<remote_servers replace="1">
Сходить со мной в одну точку 4500, печеньки ждут
Читать полностью…
Привет, создал чистый кластер клика через altinity operator.
1 шард, 3 реплики. Пинг между нодами примерно 1мс. Работает через clickhouse-keeper.
версия клика 25.8.1
Почему-то ON CLUSTER запросы очень медленные. Даже CREATE TABLE или DROP TABLE могут занимать минуту, но выполниться на всех нодам.
Если всё таки дождаться и выполнить INSERT в одну из реплик, то репликация происходит без задержек, равномерно на всех репликах
Подскажите куда копать.
Спасибо
Напомните мне пожалуйста, несмотря на то, что говорят JSON is production ready, все равно же получается рисколвать особо не стоит по причине что не все оптимизировано?
Читать полностью…
Привет.
Обновился с 25.3 до 25.8.1, стал ловить UNKNOWN_ACCESS_TYPE. В system.errors: Unknown access type: ID и Unknown access type: {}. Больше нигде не нашел ничего. Это случайно не новая фантомная ошибка, как CANNOT_PARSE_INPUT_ASSERTION_FAILED?
Что принято считать большим батчем? От?
Читать полностью…
а к стати нельзя ли никак скидывать временное состояние расчета оконных функций на диск?
по аналоги с max_bytes_befor_external_group_by и тд
исправление в том что запрос использует 10ГБ а учитывается 3ГБ, поэтому теперь падает, т.е. 23.8 тоже должна была падать с этой ошибкой
и это все слишком абстрактный разговор, возможно план изменился полностью из-за enable_analyzer=1
там исправили проблему с неправильным учетом использованной памяти.
Читать полностью…
И каким образом async_insert=1 влияет на производительность при маленьких вставках, и будет ли это как-то влиять если при этом будут и батчи и маленькие вставки??
Читать полностью…
Всем привет! Как раз по теме батчей вопросец, направьте пожалуйста на информацию как в клиентской либе на c++ переиспользовать блок для вставки? Т.е. я создал блок по табличной схеме, наполняю, по условию сбрасываю в базу и тут чтобы не вызывать деструктор блока и потом опять конструктор, хотелось бы очистить блок и переиспользовать его.. Чет не могу разобраться как это делать..😅
Читать полностью…