Size: a a a

ClickHouse не тормозит

2021 February 05

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Vladislav Filippov
не, а если не перед replicated, а именно для distributed?
такое не знаю
источник

VF

Vladislav Filippov in ClickHouse не тормозит
Denny Crane [not a Yandex bot]
такое не знаю
Понятно, ладно будем тестить )
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Egor Ivanko
Добрый день
Подскажите с запросом

Есть:
CREATE MATERIALIZED VIEW test_materialized_view
ENGINE = MergeTree
PARTITION BY a ORDER BY (a, b, c, d, e, f, g, h)

Где a, b - String
Всего строк ~500M
Разных значений a около 10
Разных значений b - 3

При этом долго выполняется запрос вида:
SELECT a, b
FROM test_materialized_view
GROUP BY a, b
ORDER BY a, b;


Можно ли ускорить такой запрос в подобной ситуации
что значит долго?
Вы ожидаете что ORDER BY (a, b поможет? или о что?

optimize_aggregation_in_order выклечено по дефолту

--optimize_aggregation_in_order arg                              Enable GROUP BY optimization for aggregating data in corresponding order in MergeTree tables
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Artem Chekunov
Привет
Кто может подсказать по структуре каталогов

/data/DATABASE/TABLE/???/COLUMNS
??? - парт
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Temur Uzbekov
у нас уже есть нечто похожее - скажите, что здесь не так?

CREATE MATERIALIZED VIEW foo.events_importance (
   `count` AggregateFunction(count),
   `time` DateTime('UCT'),
   `importance` String,
   `_date` Date
) ENGINE = AggregatingMergeTree()
PARTITION BY toDate(time)
ORDER BY (toDate(time), importance)
SETTINGS index_granularity = 8192 AS
SELECT
   countState() AS count,
   toStartOfMinute(toDateTime(time)) AS time,
   importance,
   toDate(time) AS _date
FROM foo.events
GROUP BY time, importance
SELECT
GROUP BY time, importance -- гранулярность секунда

PARTITION BY toDate(time)
ORDER BY (toDate(time), importance)
-- гранулярность день

что бессмысленно, логичнее либо там день либо тут секунда
AggregatingMergeTree схлапывает по своему ORDER BY , оно вообще не в курсе что есть MV, AggregatingMergeTree живет отдельной жизнью

а `_date` Date зачем вообще  ?

https://youtu.be/1LVJ_WcLgF8?t=7596

https://den-crane.github.io/Everything_you_should_know_about_materialized_views_commented.pdf
источник
2021 February 06

AC

Artem Chekunov in ClickHouse не тормозит
Хмм
Интересно почему их больше сотни тысяч
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Artem Chekunov
Хмм
Интересно почему их больше сотни тысяч
ну так сто тысяч инсертов и пожалуйста

там наверное большинство неактивные, они удаляются через 8 минут.

проще смортеть

   select round(sum(bytes)/1024/1024) size, round((sum(data_uncompressed_bytes))/1024/1024) ub , sum(rows),count() part_count, database,table,partition
   from system.parts
   where active = 1 and table like '%' and database like '%'
   group by database,table,partition
   order by part_count desc
источник

S

Slach in ClickHouse не тормозит
Lazoreth
В исходную таблицу каждую минуту делается запись с datetime штампом. Изза избыточности у нас в исходной таблице на какой-то срок может возникнуть 5 одинаковых записей. Которые потом исходной таблицей сожмутся в одну. Вот мне нужна одна, что бы я в другой таблице просуммировал колличество таких записей после сжатия за сутки
ой простите херню вам посоветовал

у вас же MV SummingMergeTree?
тогда просто из него через SELECT sum(k) FROM mv GROUP BY выбирайте и все будет ОК
потому что SummingMergeTree означает что суммирование по одинаковым значнеия ORDER BY будет в фоне производится при слиянии кусков из system.parts
источник

D

Dj in ClickHouse не тормозит
Denny Crane [not a Yandex bot]
а какая версия? Что если --input_format_parallel_parsing=0

20.13.1.5273
create table trg(A Int64, S String) Engine=MergeTree order by A;
cl -q ' select toInt64(number) A, toString(number) S from numbers(100000000) format TSV' > t.tsv
cl --max_insert_block_size=100000000  -q 'insert into trg format TSV' <t.tsv
select count(), min(rows), max(rows) from system.parts where active and table='trg'
┌─count()─┬─min(rows)─┬─max(rows)─┐
│       1 │ 100000000 │ 100000000 │
└─────────┴───────────┴───────────┘

truncate table trg;
cl -q ' select toInt64(number) A, toString(number) S from numbers(100000000) format Native' > t.native
cl --max_insert_block_size=100000000  -q 'insert into trg format Native' <t.native
select count(), min(rows), max(rows) from system.parts where active and table='trg'
┌─count()─┬─min(rows)─┬─max(rows)─┐
│       6 │    890935 │  32293965 │
└─────────┴───────────┴───────────┘

с native непонятно
https://habr.com/ru/company/solarsecurity/blog/540368/#comment_22629566

>> min_insert_block_size_rows, min_insert_block_size_bytes не влияют на атомарность, тут Denny Crane ошибся.


@milovidov_an все мои предыдущие эксперименты говорят что это не похоже на правду, min-ы влияют в зависимости от вставляемых данных, например native
для ТСВ input_format_parallel_parsing влиял

короче МИН настройки нужны именно для ГАРАНТИИ атомарности, так как макс сам по себе не гарантирует этого...

https://t.me/clickhouse_ru/195294
источник

AM

Alexey Milovidov in ClickHouse не тормозит
Dj
https://habr.com/ru/company/solarsecurity/blog/540368/#comment_22629566

>> min_insert_block_size_rows, min_insert_block_size_bytes не влияют на атомарность, тут Denny Crane ошибся.


@milovidov_an все мои предыдущие эксперименты говорят что это не похоже на правду, min-ы влияют в зависимости от вставляемых данных, например native
для ТСВ input_format_parallel_parsing влиял

короче МИН настройки нужны именно для ГАРАНТИИ атомарности, так как макс сам по себе не гарантирует этого...

https://t.me/clickhouse_ru/195294
min влияют на склеивание блоков в более крупные при INSERT SELECT или в Native протоколе, если отправляются мелкие блоки. Каждый такой склеенный блок в каждую партицию будет вставлен атомарно.
источник

D

Dj in ClickHouse не тормозит
Alexey Milovidov
min влияют на склеивание блоков в более крупные при INSERT SELECT или в Native протоколе, если отправляются мелкие блоки. Каждый такой склеенный блок в каждую партицию будет вставлен атомарно.
ну я про это и говорю. именно МИН дает гарантию атомарности  независимо от того что на входе. а МАКС это просто ограничение сверху.
источник

AC

Artem Chekunov in ClickHouse не тормозит
Denny Crane [not a Yandex bot]
ну так сто тысяч инсертов и пожалуйста

там наверное большинство неактивные, они удаляются через 8 минут.

проще смортеть

   select round(sum(bytes)/1024/1024) size, round((sum(data_uncompressed_bytes))/1024/1024) ub , sum(rows),count() part_count, database,table,partition
   from system.parts
   where active = 1 and table like '%' and database like '%'
   group by database,table,partition
   order by part_count desc
Хмм

Они там инсертся встроенным Кафка консюмером
Я думал они там батчами вставляются
источник

MV

Max Vikharev in ClickHouse не тормозит
Dj
ну, update_field
т.е. в ПГ таблице иметь что то типа LAST_UPDATED, и будут вам инкрементально обновления данных подвозится
Привет. Начали тестить и поняли что такой способ апдейтит только словарь целиком, инкрементальный апдейт же не поддерживается. Ту в любом случае придется гонять вс таблицу целиком. Те инкрменеталки строк поupdate_field нет. Или я что то непонимаю в доке?
источник

C

Combot in ClickHouse не тормозит
Total messages: 202872
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Max Vikharev
Привет. Начали тестить и поняли что такой способ апдейтит только словарь целиком, инкрементальный апдейт же не поддерживается. Ту в любом случае придется гонять вс таблицу целиком. Те инкрменеталки строк поupdate_field нет. Или я что то непонимаю в доке?
update_field не документирован, забили докумантировать.
Partial update словарей работают с марта 2018.
источник

D

Dj in ClickHouse не тормозит
Max Vikharev
Привет. Начали тестить и поняли что такой способ апдейтит только словарь целиком, инкрементальный апдейт же не поддерживается. Ту в любом случае придется гонять вс таблицу целиком. Те инкрменеталки строк поupdate_field нет. Или я что то непонимаю в доке?
ДДЛ словаря киньте
источник

MV

Max Vikharev in ClickHouse не тормозит
Проверим еще раз, спасибо
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Artem Chekunov
Хмм

Они там инсертся встроенным Кафка консюмером
Я думал они там батчами вставляются
а что в partition by у таблицы ? возможно батчи режутся на множество партов по partition by

select round(sum(bytes)/1024/1024) size, round((sum(data_uncompressed_bytes))/1024/1024) ub , sum(rows),count() part_count, database,table,partition
   from system.parts
   where active = 1 and table like '%' and database like '%'
   group by database,table,partition
   order by part_count desc
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Dj
https://habr.com/ru/company/solarsecurity/blog/540368/#comment_22629566

>> min_insert_block_size_rows, min_insert_block_size_bytes не влияют на атомарность, тут Denny Crane ошибся.


@milovidov_an все мои предыдущие эксперименты говорят что это не похоже на правду, min-ы влияют в зависимости от вставляемых данных, например native
для ТСВ input_format_parallel_parsing влиял

короче МИН настройки нужны именно для ГАРАНТИИ атомарности, так как макс сам по себе не гарантирует этого...

https://t.me/clickhouse_ru/195294
ржачная статья.

Оптимизатор запросов в ClickHouse пока далек от того, что есть в других базах (например, PostgreSQL и Oraсle). Он не понимает зависимости данных между столбцами.
источник

D

Dj in ClickHouse не тормозит
Denny Crane [not a Yandex bot]
ржачная статья.

Оптимизатор запросов в ClickHouse пока далек от того, что есть в других базах (например, PostgreSQL и Oraсle). Он не понимает зависимости данных между столбцами.
да, статья - самолюбование, её можно не читать...
Моя претензия к Алексею в том, что его комментарий как минимум "misleading".
источник