Size: a a a

ClickHouse не тормозит

2021 February 18

R

Ruslan in ClickHouse не тормозит
DDL запросы актуальны только для хостов которые описаны в конфиге на момент запроса? (речь не про доступность, а про факт наличия хоста в конфиге). Те если через пару дней будет добавлен новый хост, все конфиги будут обновлены (добавление скажем ещё одной реплики в каком то шарде) - этот новый хост тоже получит на исполнение DDL запросы которые в прошлом были применены на этом кластере?
источник

R

Ruslan in ClickHouse не тормозит
Судя по тому что описано в зукиперных нодах - не должен (там четкий список хостов указан), но может я что то упускаю?
источник

l

lnuynxa in ClickHouse не тормозит
Ruslan
Судя по тому что описано в зукиперных нодах - не должен (там четкий список хостов указан), но может я что то упускаю?
нет, не получит
источник

S

Slach in ClickHouse не тормозит
Andrey
Пайплайн запроса

┌─explain──────────────────────────────────────────┐
│ (Expression)                                     │
│ ExpressionTransform                              │
│   (Filter)                                       │
│   FilterTransform                                │
│     (Aggregating)                                │
│     Resize 16 → 1                                │
│       AggregatingTransform × 16                  │
│         StrictResize 16 → 16                     │
│           (Expression)                           │
│           ExpressionTransform × 16               │
│             (SettingQuotaAndLimits)              │
│               (Expression)                       │
│               ExpressionTransform × 16           │
│                 (Materializing)                  │
│                 MaterializingTransform × 16      │
│                   (Expression)                   │
│                   ExpressionTransform × 16       │
│                     (SettingQuotaAndLimits)      │
│                       (ReadFromStorage)          │
│                       MergeTreeThread × 16 0 → 1 │
└──────────────────────────────────────────────────┘
такое ощущение что память аллоцируется все равно на финальной стадии
@den_crane @unamedrus IMHO интересный кейс

а можно все таки SHOW CREATE TABLE расшарить?
источник

A

Andrey in ClickHouse не тормозит
CREATE TABLE default.impressions_a4930_4930_ftp
(
   `date` Date,
   `__account_id` String,
   `__row_hash` UInt64,
   `__row_id` UInt16,
   `__sign` Int8,
   `__insert_date` DateTime,
   `advertiser_id` String,
   `advertiser_name` String,
   `insertion_order_id` String,
   `insertion_order_name` String,
   `package_id` String,
   `package_name` String,
   `line_item_id` LowCardinality(String),
   `line_item_name` String,
   `ad_id` String,
   `creative_id` String,
   `creative_name` LowCardinality(String),
   `currency` String,
   `user_id` String,
   `mobile_device_id` String,
   `impression` Float64,
   `impression_datetime` String,
   `click` Float64,
   `click_datetime` String,
   `inventory_source_name` String,
   `creative_size` String,
   `video_player_size` String,
   `video_playback_method` String,
   `tld` String,
   `subdomain` String,
   `region_name` String,
   `dma_name` LowCardinality(String),
   `postal_code` String,
   `device_type` String,
   `mobile_device_type` String,
   `os_type_name` String,
   `browser_type_name` String,
   `country` String,
   `media_channel_name` String,
   `format` String,
   `environment` String,
   `mobile_device_manufacturer` String,
   `mobile_device_model` String,
   `ad_position` String,
   `percent25_events` Float64,
   `percent50_events` Float64,
   `percent75_events` Float64,
   `percent100_events` Float64,
   `sum_cost` Float64,
   `__key_hash` UInt64,
   `iab_in_view_imp` Float64
)
ENGINE = CollapsingMergeTree(__sign)
PARTITION BY toYYYYMM(date)
ORDER BY (date, __account_id, __row_hash, __row_id)
SETTINGS index_granularity = 8192
источник

A

Andrey in ClickHouse не тормозит
насколько я понимаю, важная часть проблемы состоит в том, что __row_hash - это cityHash64() по всем не включенным в ключ сортировки полям. тут имеет место быть хитрый план по использованию collapsingmergetree без включения всех дименшенов в ключ сортировки
источник

СС

Саша Суббота... in ClickHouse не тормозит
Добый день, как можно получить(или есть функция) результат перемножения элементов массива?
источник

S

Sergei in ClickHouse не тормозит
Привет. Вопрос возник: можно где-то как-то получать информацию, для каких строк были удалены дубли в процессе выполнения ALTER TABLE ... OPTIMIZE PARTITION ... DEDUPLICATE ?
источник

S

Sharif in ClickHouse не тормозит
привет, правда ли что DDL запрос с дропом партиции никак нельзя заставить отработать при наличии недоступных хостов?
источник

S

Slach in ClickHouse не тормозит
Andrey
насколько я понимаю, важная часть проблемы состоит в том, что __row_hash - это cityHash64() по всем не включенным в ключ сортировки полям. тут имеет место быть хитрый план по использованию collapsingmergetree без включения всех дименшенов в ключ сортировки
ну выглядит все так что у вас группировка + HAVING все равно требуют память в финальной стадии, вместо стриминга...
источник

S

Sergei in ClickHouse не тормозит
Другой заковыристый вопрос. Есть таблица с метриками (item_id Int64, clock DateTime, value Float64). Случается, что в таблицу попадают дубликаты, как полные, так и совпадающие по (item_id,clock) но различающиеся по value. Для расчетов нужно учитывать только одно значение на (item_id,clock) и возвращать за отчетный диапазон времени по одной записи вида (item_id Int64, values Array(Float64)). Нашли пока два способа. Первый: в подзапросе select item_id, clock, any(value) values ... group by item_id, clock, на уровне выше select item_id, groupArray(values) values ... group by item_id. Второй: всё в одном запросе заковыристой комбинацией лямбд select item_id, arrayMap(x -> (x.2), arrayFilter((i, x) -> (x = 1), groupArrayDistinct((clock, value)) as clock_value, arrayEnumerateUniq(arrayMap(x -> (x.1), clock_value)))) values ... group by item_id. Второй вариант валит сервер на большом количестве данных. Есть ли иные, более "прямые" варианты?
источник

DT

Dmitry Titov in ClickHouse не тормозит
Slach
такое ощущение что память аллоцируется все равно на финальной стадии
@den_crane @unamedrus IMHO интересный кейс

а можно все таки SHOW CREATE TABLE расшарить?
А если HAVING убрать
источник

L

Lazoreth in ClickHouse не тормозит
Подскажите пожалуйста - По опыту, насколько сильно на скорость запроса влияют функции использованные? Есть огромный запрос с достаточно большим multiIf(). У него время выполнения практически константное, вне зависимости от обьёма возвращаемых данных, грешу на multiif
источник

L

Lazoreth in ClickHouse не тормозит
Время запроса не слишком большое, и не слишком критичное. Но если так сильно влияют использованные функции, может можно его ускорить убрав их
источник

D

Dj in ClickHouse не тормозит
Sharif
привет, правда ли что DDL запрос с дропом партиции никак нельзя заставить отработать при наличии недоступных хостов?

Локальная версия запроса в конечном итоге будет выполнена на каждом хосте кластера, даже если некоторые хосты в данный момент не доступны. Гарантируется упорядоченность выполнения запросов в рамках одного хоста.

https://clickhouse.tech/docs/ru/sql-reference/distributed-ddl/
только клиент будет ждать таймаута, но после запуска можно его прибить
источник

D

Dj in ClickHouse не тормозит
Lazoreth
Подскажите пожалуйста - По опыту, насколько сильно на скорость запроса влияют функции использованные? Есть огромный запрос с достаточно большим multiIf(). У него время выполнения практически константное, вне зависимости от обьёма возвращаемых данных, грешу на multiif
MultiIf/if выполняет все ветки условий при запуске... так что да, будет тормозить при больших вложенностях
источник

K

Kid in ClickHouse не тормозит
Dj
да, все сами
не подскажете, они не связываются, мб надо в новых ЗК сделать /clickhouse?
источник

S

Slach in ClickHouse не тормозит
Andrey
День добрый. Есть такой запрос:
SELECT
   any(device) AS device,
   any(line_item_id) AS line_item_id,
   any(tactic) AS tactic,
   any(target) AS target,
   any(line_item_name) AS line_item_name,
   any(line_item_name_2) AS line_item_name_2,
   any(outside_target_dma) AS outside_target_dma,
   any(creative) AS creative,
   date AS date,
   any(inside_target_dma) AS inside_target_dma,
   toFloat64(sum(impression * __sign)) AS impression,
   any(channel) AS channel,
   __account_id AS account_id
FROM impressions_4930
GROUP BY
   date,
   __account_id,
   __row_hash,
   __row_id
HAVING sum(__sign) > 0

Таблица использует CollapsingMergeTree, поля в GROUP BY составляют ключ сортировки, короче - используем способ из документации для выполнения агрегаций без SELECT...FINAL. Правда, запрос превышает лимиты по памяти. Я последовательно снижал значение max_bytes_before_external_group_by и в итоге достиг значения в 20000000 (20 мегабайт), но результат не меняется:
Code: 241. DB::Exception: Received from localhost:9000. DB::Exception: Memory limit (for query) exceeded: would use 46.57 GiB (attempt to allocate chunk of 4216924 bytes), maximum: 46.57 GiB: While executing AggregatingTransform. 

В чем может быть причина?
HAVING пробовали убирать?
источник

A

Andrey in ClickHouse не тормозит
Slach
HAVING пробовали убирать?
емнип да, та же фигня. сейчас еще раз запустил запрос без него
источник

A

Andrey in ClickHouse не тормозит
в таблице 400 миллионов строк и для каждой __row_hash уникальный
источник