11238
Обсуждаем ClickHouse
рестартанул сервер, ожило )
запрос кривой видать )
Добрый вечер!
поймал такую ошибку
Хочется понять, как это исправть , но не понятно с чего начать )
всем привет
недавно переехали со строк на 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 будет читать данные относящиеся только к этим вложенные подстолбцам
Ок, понял. Просто раньше у меня такого не происходило, я всегда видел, что несколько нод имеют клиентские подключения. Они неравномерно распределены, но никогда не было такого, чтобы только на одной ноде все клиенты, а сейчас именно так. И хочу понять, от чего это зависит
Читать полностью…
Нет, я просто опираюсь все еще на теорию старую
Читать полностью…
А разве там есть понятие master-slave? Насколько я помню, там есть leader и follower, но это про другое, и лидер может на самом деле вообще не обслуживать клиентов, в кипере есть такой режим.
Читать полностью…
Привет! Коллеги, кто в курсе, как распределяются клиенты между нодами кластера clickhouse-keeper?
Поясню, есть кластер киперов из 5 нод, и кластер кликхаусов из 20+ нод, то есть кликхаусы являются клиентами киперов. И сейчас почему-то сложилось так, что все клиенты подключены только к одному киперу, который в то же время и лидер кластера, а остальные киперы только реплицируют журнал.
Норм ли такая ситуация, и как должно быть в идеале, и можно ли этим управлять?
ну так а где у вас корень КХ ? не в /var/lib/clickhouse/ ?
Читать полностью…
Тут слишком мало информации. Надо больше логов. Что там было начиная за несколько минут до этого. И версию кх
Шарим текст через 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
Я обычно меняю лидера командой echo ydld
Читать полностью…
Привет! Лучше размазать подключения по всему кипер кластеру, чтобы репликация быстрее работала.
У меня лично так, если все клики подключены к одной ноде кипера (всегда почему то к лидеру), то очередь репликации медленнее обрабатывается
точнее теорию монги и прочих бд, использующих такое
Читать полностью…
Вот тут еще можно почитать
https://clickhouse.com/docs/architecture/cluster-deployment
https://pastila.nl/?0018323d/cd52b987df7057de4832e21658e48556#h8UcDghNNHuC/dfl4Y8AkA==
Есть ли возможность типизировать вложенную иерархию?
Из своего опыта с ZK и просто продовым кластером: 3 координатора - один master, остальные slave. Хотя вроде такого понятия я не помню есть или нет у координаторов
Читать полностью…
Функции array* не работают с типом Dynamic, а в JSON все подстолбцы по дефолту имеют этот тип. Для чтения массива объектов можете использовать синтаксис json.some.path[], тип этого подстолбца будет Array(JSON). Для путей с обычными массивами можете использовать каст в нужный тип json.some.path::Array(Int64). Например: https://fiddle.clickhouse.com/ee507b12-7489-4e86-944d-7c3f11b2dd96
Читать полностью…