Влияние на производительность запросов SELECT при постоянном заполнении таблицы Clickhouse с помощью INSERT INTO

Таблица Clickhouse, MergeTree Engine, постоянно заполняется запросами «INSERT INTO… FORMAT CSV», начиная с пустого. Средняя скорость ввода 7000 строк в секунду. Вставка выполняется партиями по несколько тысяч строк. Это сильно влияет на производительность, когда запросы SELECT выполняются одновременно. Как описано в документации Clickhouse, системе требуется не более 10 минут для объединения данных определенной таблицы (повторного индексации). Но этого не происходит, поскольку таблица постоянно заполняется.

Это также очевидно в файловой системе. Папка таблицы содержит тысячи подпапок, а индекс чрезмерно сегментирован. Если прием данных прекращается, через несколько минут таблица полностью объединяется, а количество подпапок становится дюжиной.

Чтобы устранить указанную выше слабость, был использован механизм буферизации для буферизации приема данных таблицы в течение 10 минут. Следовательно, максимальное количество строк в буфере в среднем составляет 4200000.

Исходная таблица отстает не более чем на 10 минут, поскольку буфер хранит самые последние принятые строки. Наконец, таблица объединяется, и поведение такое же, как и в случае, когда таблица перестала заполняться на несколько минут. Но таблица Buffer, которая соответствует комбинации буфера и исходной таблицы, становится значительно медленнее.

Из вышесказанного следует, что, если таблица постоянно заполняется, она не объединяется, и индексирование страдает. Есть ли способ избежать этой слабости?


person manolis.alivizatos    schedule 09.01.2018    source источник
comment
Не могли бы вы предоставить воспроизводимые операторы создания таблиц, которые вы используете?   -  person egorlitvinenko    schedule 10.01.2018


Ответы (1)


Количество подпапок в каталоге данных таблицы не столь репрезентативное значение.

Действительно, каждая подпапка содержит часть данных, состоящую из отсортированных (проиндексированных) строк. Если несколько частей данных объединяются в новую, более крупную, появляется новая подпапка.

Однако части исходных данных не удаляются сразу после слияния. Существует <merge_tree> параметр old_parts_lifetime, определяющий задержку, после которой детали будут удалены, по умолчанию она установлена ​​на 8 минут. Кроме того, есть cleanup_delay_period параметр, определяющий, как часто средство очистки фона проверяет и удаляет устаревшие части, по умолчанию это 30 секунд.

Таким образом, такое количество подпапок является нормальным в течение примерно 8 минут и 30 секунд после начала приема. Если для вас это неприемлемо, вы можете изменить эти настройки.

Имеет смысл проверять количество активных частей только в таблице (т.е. частей, которые не были объединены в большую). Для этого вы можете выполнить следующий запрос: SELECT count() FROM system.parts WHERE database='db' AND table='table' AND active.

Более того, ClickHouse выполняет такие проверки внутренне, если количество активных частей в разделе больше parts_to_delay_insert=150, это замедляет INSERT, но если оно больше parts_to_throw_insert=300, вставки прерываются.

person Vitaliy L.    schedule 09.02.2018