11238
Обсуждаем ClickHouse
вроде есть баги про проекции, show create table DB.table
еще возможно что битый minmax индекс, который побился в сильно раньше
там однопоточный инсерт из distributed в шарды, просто не успевает, мелкие инсерты
попробуйте поменять insert_distributed_sync на 1
Кластер из примера на локальном компе
Наливаю в таблицу Distributed
Растет очередь distribution_queue
SELECT *
FROM system.distribution_queue
Row 1:
──────
database: obs
table: metrics_null
data_path: /var/lib/clickhouse/store/392/392d910a-15f9-400d-aef2-897947b7e22a/shard2_all_replicas/
is_blocked: 0
error_count: 0
data_files: 3268
data_compressed_bytes: 349309099 -- 349.31 million
broken_data_files: 0
broken_data_compressed_bytes: 0
last_exception:
last_exception_time: 1970-01-01 00:00:00
добавлю пару вводных, версия 24.8.12.28, движок merge tree, полей для джойна больше, но все через равенство (в примере указал меньшее кол-во для наглядности), f - это decimal поле (28, 4)
Читать полностью…
я немного подкорректировал пример, но в данном случае все верно, да, но тем не менее я делаю то же самое на 100млн записях и у меня некорректный результат, может ли это быть багом, который проявляется при каких то специфичных условиях?
Читать полностью…
они не могут снова появиться, потому что далее используется t1 в котором его нет
Читать полностью…
группировка по полю b нужна, чтобы взять самое последнее значение f и по ней работать (грубо говоря view на актуальные записи), но в этой таблице есть полностью идентичные записи по a, b, created at, и, если на этапе v они отбрасываются, то на этапе join, снова появляются и влияют на сумму
Читать полностью…
у вас в v есть группировка по полю b, которое нигде далее не используется. Возможно поэтому вы получаете не то что ожидаете
Читать полностью…
Тут слишком мало информации. Надо больше логов. Что там было начиная за несколько минут до этого. И версию кх
Шарим текст через pastila.nl
Если у вас большое количество уникальных путей в JSON, то долгие мержи это ожидаемо из-за большого числа подстолбцов внутри JSON.
Можете попробовать ограничить количество путей выделяемых в подстолбцы (параметер max_dynamic_paths). Правда это сделает чтение части путей менее эффективным.
В версиях 25.8+ могу посоветовать попробовать подход без динамических путей (max_dynamic_paths=0) но с новой версией shared data (документация: https://clickhouse.com/docs/sql-reference/data-types/newjson#shared-data-structure-in-merge-tree-parts, блог пост с объяснениями как это работает https://clickhouse.com/blog/json-data-type-gets-even-better)
Здравствуйте, столкнулся с такой проблемой: при insert читает всю таблицу(перекидывает в ram) и только потом записывает в таблицу. Обновились до 25.8 ещё недели 2 назад, но началось это только сегодня
Можете подсказать, как можно отследить из-за чего именно такое началось? Спасибо!
КХ 23.3.6.56 таблица ReplaceingMergeTree с проекцией. Настройки MergeTree
deduplicate_merge_projection_mode=drop
OPTIMIZE TABLE my_table FINAL DEDUPLICATE;
микроменеджмент... ну, как вариант. Только я не очень понимаю, почему сам кипер не распределяет подключения
Читать полностью…
там можно прописать разные ноды кипера на разных КХ (в смысле в разном порядке) поставить in_order и настроить fallback_session_lifetime
https://github.com/tonickkozlov/ClickHouse/blob/5dfc30528dbdfe1ef053ec3cfa4067fd9fdbf886/tests/integration/test_zookeeper_fallback_session/configs/zookeeper_load_balancing.xml#L5-L8
https://github.com/ClickHouse/ClickHouse/pull/50424
подскажите, известно про такое поведение? Версия 25.8.10.7
SELECT max(calc_time)Читать полностью…
FROM DB.table
┌──────max(calc_time)─┐
1. │ 1970-01-01 00:00:00 │
└─────────────────────┘
SELECT max(calc_time)
FROM DB.table
WHERE calc_time != 1
┌──────max(calc_time)─┐
1. │ 2025-10-21 12:53:07 │
└─────────────────────┘
SELECT max(calc_time)
FROM DB.table
WHERE calc_time != 2
┌──────max(calc_time)─┐
1. │ 2025-10-21 12:53:07 │
└─────────────────────┘
SELECT
max(calc_time),
max(1)
FROM DB.table
┌──────max(calc_time)─┬─max(1)─┐
1. │ 2025-10-21 12:53:07 │ 1 │
└─────────────────────┴────────┘
это ожидаемо
надо в явном виде указывать Decimal(76,0)
Добрый день, подскажите, пожалуйста, ожидаемое это поведение или это баг. При использовании в запросе большого числа оно автоматически приводится к типу Float64, что в моем случае приводит к неправильному результату на запрос:
clickhouse-01.test.net 🙂 🙂 select points from some_table final where some_field = unhex('some_hex')
AND requested_block_number > 23146000 and points = 2441753498842748200000000000000000000000000000000000 limit 10;
SELECT points
FROM some_table
FINAL
WHERE (some_field = unhex('some_hex')) AND (requested_block_number > 23146000) AND (points = 2.4417534988427482e51)
LIMIT 10
┌───────────────────────────────────────────────points─┐
1. │ 2441753498842748218059455865257984907244327467332535 │
2. │ 2441753498842748218059455865257984907244327467332535 │
3. │ 2441753498842748218059455865257984907244327467332535 │
4. │ 2441753498842748218059455865257984907244327467332535 │
5. │ 2441753498842748218059455865257984907244327467332535 │
6. │ 2441753498842748218059455865257984907244327467332535 │
7. │ 2441753498842748218059455865257984907244327467332535 │
8. │ 2441753498842748218059455865257984907244327467332535 │
9. │ 2441753498842748218059455865257984907244327467332535 │
10. │ 2441753498842748218059455865257984907244327467332535 │
└──────────────────────────────────────────────────────┘
10 rows in set. Elapsed: 0.109 sec. Processed 6.49 million rows, 389.29 MB (59.27 million rows/s., 3.56 GB/s.)
Peak memory usage: 15.49 MiB.
[clickhouse-01.test.net] 2025.10.21 12:19:54.384464 [ 464524 ] {} <Debug> `some_database`.some_table ... Query condition cache has dropped 0/5291 granules for WHERE condition and(equals(points, 2.4417534988427482e51_Float64), ...
нет
https://fiddle.clickhouse.com/2606c560-52e5-4214-b0a8-ad1600771226
На самом деле задача состоит в том, что требуется патчить запросы из внешних систем.
Читать полностью…
Привет! Скажите, а есть ли возможность выполнить AST запроса?
Читать полностью…
рестартанул сервер, ожило )
запрос кривой видать )
Добрый вечер!
поймал такую ошибку
Хочется понять, как это исправть , но не понятно с чего начать )
всем привет
недавно переехали со строк на JSON, пришли вот к такой вот схеме
CREATE TABLE `dev`.infra_metrics_events
(
`account_id` Int64,
`event_type` LowCardinality(String),
`entity_key` LowCardinality(String),
`timestamp` DateTime('UTC'),
`json` JSON
)
ENGINE = MergeTree
PRIMARY KEY (account_id, event_type, toDate(timestamp), entity_key)
ORDER BY (account_id, event_type, toDate(timestamp), entity_key, timestamp)
TTL toDateTime(timestamp) + toIntervalDay(_CAST(30, 'UInt32'))
SETTINGS index_granularity = 8192
table: infra_metrics_events
elapsed: 23016.911594236
progress: 0.4153115226344885
num_parts: 1
source_part_names: ['all_1536280_5474010_436_5030108']
result_part_name: all_1536280_5474010_437_5030108
source_part_paths: ['/var/lib/clickhouse/store/bd4/bd4eb238-157d-46ff-a00f-f78f391ebb5d/all_1536280_5474010_436_5030108/']
result_part_path: /var/lib/clickhouse/store/bd4/bd4eb238-157d-46ff-a00f-f78f391ebb5d/all_1536280_5474010_437_5030108/
partition_id: all
partition: tuple()
is_mutation: 0
total_size_bytes_compressed: 6127181294 -- 6.13 billion
total_size_bytes_uncompressed: 171964548732 -- 171.96 billion
total_size_marks: 255671
bytes_read_uncompressed: 1118731743446 -- 1.12 trillion
rows_read: 157204294 -- 157.20 million
bytes_written_uncompressed: 1205348780852 -- 1.21 trillion
rows_written: 153934627 -- 153.93 million
columns_written: 0
memory_usage: 1602119921 -- 1.60 billion
thread_id: 3398
merge_type: TTLDelete
merge_algorithm: Horizontal
ну попробуйте deduplicate_merge_projection_mode = rebuild
Читать полностью…
>КХ 23.3.6.56
v24.8.1.2684-lts
Added a new MergeTree setting `deduplicate_merge_projection_mode` to control the projections during merges (for specific engines) and OPTIMIZE DEDUPLICATE query. Supported options: throw (throw an exception in case the projection is not fully supported for *MergeTree engine), drop (remove projection during merge if it can't be merged itself consistently) and rebuild (rebuild projection from scratch, which is a heavy operation). [#66672](https://github.com/ClickHouse/ClickHouse/pull/66672) ([jsc0218](https://github.com/jsc0218)).
ну так кипер это имплементация зукипера, в зукипере такой фичи нет
Читать полностью…
Нет, но можно читать только нужные вложенные подстолбцы c самого начала, например https://fiddle.clickhouse.com/0d307dca-7f3a-411c-a339-a0fec03af3f9
В вашем примере это тоже можно сделать. А то в вашем примере ClickHouse будет читать весь массив SpinJson.Spin.Steps и все остальные вложенные пути вытаскивать уже в памяти, а если сразу вытащить все вложенные подстолбцы, то ClickHouse будет читать данные относящиеся только к этим вложенные подстолбцам