и несколько мат.вью на таблицы с движком mergetree. Цель - оптимизация загрузки, а именно уменьшение кол-ва кусочков при инсерте.
Согласно : https://kb.altinity.com/altinity-kb-queries-and-syntax/atomic-insert/ , атомарной вставки не добиться , как минимум, из-за наличия матвью. А каким образом можно минимизировать кол-во кусков. На данный момент установил input_format_parallel_parsing=0 и min_insert_block_size_rows=2000000 и min_insert_block_size_bytes=2000000 ( 2000000 кол-во строк в файлах). Что можете ещё посоветовать ?
Зачем уменьшать кол-во кусочков ?
Хочется iowait снизить
главный совет - реже вставлять. Если есть возможно буферизовать где-то (кафка?), то вставляйте раз в 10с или даже раз в минуту. парты (кусочки) образуются при вставке, одна вставка - один парт.
асинхронные инсерты можно попробовать если больше буферизовать негде. https://clickhouse.com/blog/click-house-v2111-released/#async-inserts
Не пойму, как это поможет, если вставка и так по 2кк идёт
никак не поможет. Но тогда непонятен вопрос. Вас не устраивают парты по 2kk строк? (наверное меньше - там же в MV какая-то аггрегация?) У вас partition by - обычный (месячный) или какой-то хитрый?
Так не получатся парты по 2кк строк, потому что загрузка не напрямую в mergetree,а через матвью. Партиционирование по месяцам , матвью перекладывают данные в таблицы с чуть другим первичным ключом , аггрегаций нет.
теперь вопрос понятен. min_insert_block_size_rows_for_materialized_views пробовали?
Нет, буду пробовать. Спасибо !
кол-во партов равно количеству INSERT запросов это настройками не лечится, это надо на стороне приложения фигачить либо Engine=Buffer со сбросом в Engine=Null либо async_insert=1 в запросе передавать
bytes должно быть выше чем rows...
Обсуждают сегодня