> Ведь наверно CH сохраняет крайние значения колонок, по которому

Question

> Ведь наверно CH сохраняет крайние значения колонок, по которому

делается нарезка партиций и не обращается к лишним кускам?

Верно.

> А что мешает это делать в таблицах в целом и с аналогичной скоростью выполнять запрос с Merge?

Для обычных MergeTree с помесячным партиционированием условие на дату тоже используется для выбора кусков. Конечно, если вы партиционируете не только по дате, но и по чему-либо ещё, то второе условие будет использоваться только в таблице нового стиля.

Скорее всего проблема с производительностью для Merge-таблицы связана со статическим распределением потоков выполнения. Предположим у вас max_threads=16 и для ровного счёта Merge-таблица над 16 MergeTree. Вы задаёте запрос с условием, под которое подпадают только данные одной таблицы. Получается они будут вычитываться в 1 поток. А для таблицы с PARTITION BY в 16 потоков.

#backend #clickhouse #database #devops #programming #russian

0

03.11.2017

1 ответов

5 просмотров

I Igrk · Accepted Answer

Да кстати, я посылаю запрос в котором участвуют все таблицы, т.е. не ограничиваю его по дате или тому доп.критерию. Например запрос с like на одну из ~100 колонк. Поэтому и ожидаю, что такой запрос должен разойтись параллельно на все таблицы и выполниться за приблизительно одинаковое кол-во времени и там и там. А сладывается ощущение, что с Merge они действительно вычитываются в конце последовательно. —---------- ### clickhouse-partition_by (1498 кусков) select count() from test_partition_by where column1 like '%test'; 1 rows in set. Elapsed: 0.914 sec. Processed 291.04 million rows, 6.97 GB (318.44 million rows/s., 7.63 GB/s.) select * from test_partition_by where column1 like '%test'; 88 rows in set. Elapsed: 15.183 sec. Processed 291.04 million rows, 7.76 GB (19.17 million rows/s., 511.41 MB/s.) —---------- ### clickhouse-merge+mergeTree (1020 таблиц, состоящих из 1183 кусков) т.е. в основном все из одного куска. select count() from test_merge where column1 like '%test'; 1 rows in set. Elapsed: 1.031 sec. Processed 291.04 million rows, 6.97 GB (282.21 million rows/s., 6.76 GB/s.) select * from test_merge where column1 like '%test'; 61 rows in set. Elapsed: 120.695 sec. Processed 193.00 million rows, 252.44 GB (1.60 million rows/s., 2.09 GB/s.) (ps. в последнем результатов меньше так как в конфиге ограничили время до 120сек.)

184 похожих чатов

> Ведь наверно CH сохраняет крайние значения колонок, по которому

1 ответов

Похожие вопросы