Как ускорить большой запрос в ClickHouse?

Фон:

Я отправил локальный запрос в ClickHouse (без использования кеша), и он обработал 414,43 миллиона строк, 42,80 ГБ. Запрос длился более 100 секунд. Мои экземпляры ClickHouse были установлены на AWS c5.9xlarge EC2 с 12T st1 EBS

Во время этого запроса IOPS - до 500, а чтение throughput - до 20M/s. Для сравнения: st1 EBS max IOPS равно 500, а max throughput равно 500M/s.

Вот мой вопрос:

  1. Действительно ли 500 IOPS ограничивает скорость моего запроса (чтения файла)? (не говоря уже о кеше) Следует ли мне изменить тип тома EBS на gp2 или io1, чтобы увеличить IOPS?
  2. Есть какие-нибудь настройки, которые могут улучшить throughput под тот же IOPS? (как я вижу, на самом деле это далеко от потолка) Я попытался увеличить 'max_block_size', чтобы читать больше файлов за один раз, но, похоже, это не сработало.
  3. Как увеличить время кеширования? Большой запрос занял минуты. Кеширование заняло секунды. Но кажется, что кеш-память длится недолго.
  4. Как разогреть колонки, чтобы они соответствовали всем требованиям? Покажите, пожалуйста, sqls.

performance throughput clickhouse
person Winter Z.    schedule 20.01.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Действительно ли 500 IOPS ограничивают скорость моего запроса (чтения файла)?

да

Следует ли мне изменить тип тома EBS на gp2 или io1, чтобы увеличить количество операций ввода-вывода в секунду?

да

Есть ли какие-либо настройки, которые могут улучшить пропускную способность при тех же IOPS?

настроить max_bytes_to_read

уменьшить количество столбцов (в выбранном)

уменьшить количество деталей (в избранном)

Как продлить время кеширования?

min_merge_bytes_to_use_direct_io = 1

Как разогреть колонки, чтобы они соответствовали всем требованиям? Покажите, пожалуйста, sqls.

select a,b,c,d from T Format Null

person Denny Crane    schedule 20.01.2020
comment
Для справки: запрошенная мной таблица содержит тысячи разделов (на данный момент 2k). Я обнаружил, что для max_bytes_to_read по умолчанию установлено значение 0, что означает отсутствие ограничений. Я попытался изменить его значение, но не обнаружил значительного изменения производительности. Означает ли это, что мой запрос производит такую ​​низкую пропускную способность только потому, что его слишком много частей и он не соответствует пределу max_bytes_to_read - person Winter Z.; 21.01.2020
comment
Видимо перепутал max_bytes_to_read с другим параметром. Я помню, что CH читает по буферу размером 1 МБ. Но ваша цель - не пропускная способность. Да, 2к деталей могли быть причиной давления от лимита 500IPS. Часть может быть слишком маленькой, и CH выполняет больше операций ввода-вывода, чтобы читать много файлов вместо одного. Попробуйте перестроить таблицу с другим разделом на. - person Denny Crane; 21.01.2020