Хозяйке кликхауса на заметку Реальный кейс: перетаскивал данные из одной большой таблицы в другую с изменением структуры через INSERT … SELECT. В какой-то момент селекты на перенесённых данных стали просто невозможно долгими, а при попытке переноса следующего куска я даже получил ошибку: Code: 252. DB::Exception: Too many parts (5585 with average size of 1.14 MiB) in table 'db.table'. Merges are processing significantly slower than inserts. (TOO_MANY_PARTS) Суть ошибки заключается в том, что партов (не путать с партициями) стало слишком много, а значит дальнейшая вставка нежелательна и может привести к деградации (о чём намекнули медленные селекты). Что вообще за парты? Основной движок в ClickHouse – это MergeTree. И название тут уже многое говорит, потому что это действительно некое дерево слияний, которое особенно важно для быстрой вставки данных. Как бы работала наивная медленная вставка? Мы бы брали входные данные, сортировали бы их по ORDER BY таблицы, затем брали бы файл с данными таблицы/колонки, и "расставляли" бы данные в соответствии с нужным порядком. Уже даже звучит не очень шустро. ClickHouse же делает иначе: когда в INSERT приходят данные, он распределяет их по небольшим отсортированным партам. Пока без слияния: максимально быстро данные получил и сохранил на диск. Но если дальше ничего не сделать, то медленно будет работать уже чтение, потому что в итоге партов станет слишком много, и каждый из них придётся читать отдельно. Как ускорить теперь чтение? Для этого ClickHouse выполняет фоновое слияние партов (background part merges), когда берётся несколько десятков маленьких партов, данные в них сортируются и объединяются, и записываются в большой парт. Затем берутся большие парты, точно также данные сортируются и объединяются, и появляется ещё больший парт. И всё это происходит автоматически и в фоне, можно прямо проверить SELECT FROM system.merges . Подробнее можете прочитать в потрясающей доке https://clickhouse.com/docs/merges. Я прочитал часть с Merges are processing significantly slower than inserts , и решил проверить эти самые "merges", выполнив SELECT FROM system.merges . В этой таблице вы можете увидеть активные в данный момент операции слияния. Я удивился, не увидев там ни одной операции слияния нужной мне таблицы. Окей, может там и не должно было ничего быть? Проверил количество активных партов, выполнив SELECT COUNT(*) FROM system.parts WHERE database = 'db' AND table = 'table' AND active; , и что бы вы думали? 5585 партов! Нет, тут точно что-то пошло не так! Видимо, я настолько утомил кликхаус, что он решил взять больничный! 😁 Решение Подтолкнуть ClickHouse к обработке мержей оказалось легко и задокументировано. Я запустил: SYSTEM START MERGES db.table; И сразу увидел в system.merges, как парты таблицы начали сливаться. Резюмируя 🤓 1. Похоже иногда может возникнуть ситуация, что ClickHouse "забудет" начать слияние новых партов таблицы. Вполне вероятно это фиксят в каждой новой версии, но многие ли из вас успевают апгрейдить такой важный компонент, ещё и регулярно? 2. Косвенным признаком является драматичное замедление селектов (приходится считывать слишком много разрозненных файлов). 3. Явным признаком является аномальное количество активных партов в system.parts и отсутствие какой-либо обработки в system.merges. 4. SYSTEM START MERGES db.table; волшебным образом "подталкивает" кликхаус начать обработку таблицы без перезапуска и прочего. Славный АйТи 👨‍💻