Выбор ключа партиционирования
Партиционирование является в первую очередь техникой управления данными, а не инструментом оптимизации запросов. Хотя оно может улучшить производительность в определенных загрузках, это не должно быть первым механизмом, который используется для ускорения запросов; ключ партиционирования должен быть выбран тщательно, с ясным пониманием его последствий, и применяться только тогда, когда это соответствует потребностям жизненного цикла данных или хорошо понимаемым паттернам доступа.
В ClickHouse партиционирование организует данные в логические сегменты на основе указанного ключа. Это определяется с помощью оператора PARTITION BY во время создания таблицы и обычно используется для группировки строк по временным интервалам, категориям или другим бизнес-значимым измерениям. Каждое уникальное значение выражения партиционирования формирует собственную физическую партицию на диске, и ClickHouse хранит данные в отдельных частях для каждого из этих значений. Партиционирование улучшает управление данными, упрощает политику хранения и может помочь в определенных паттернах запросов.
Например, рассмотрим следующую таблицу набора данных цен, оплаченных в Великобритании, с ключом партиционирования toStartOfMonth(date).
Каждый раз, когда набор строк вставляется в таблицу, вместо создания (по крайней мере) одной единственной части данных, содержащей все вставленные строки (как описано здесь), ClickHouse создает одну новую часть данных для каждого уникального значения ключа партиционирования среди вставленных строк:
Сервер ClickHouse сначала делит строки из примера вставки с 4 строками, изображенными на диаграмме выше, по значениям их ключа партиционирования toStartOfMonth(date). Затем для каждой идентифицированной партиции строки обрабатываются как обычно путем выполнения нескольких последовательных шагов (① Сортировка, ② Деление на колонки, ③ Сжатие, ④ Запись на диск).
Для более детального объяснения партиционирования мы рекомендуем этот гид.
С включенным партиционированием ClickHouse только объединяет части данных внутри, но не между партициями. Это показано для нашей примерной таблицы выше:
Применение партиционирования
Партиционирование является мощным инструментом для управления большими наборами данных в ClickHouse, особенно в случаях наблюдаемости и аналитики. Оно позволяет эффективно выполнять операции жизненного цикла данных, позволяя целым партициям, часто соответствующим времени или бизнес-логике, быть удаленными, перемещенными или архивированными в одной операции с метаданными. Это значительно быстрее и менее затратнее по ресурсам, чем операции удаления или копирования на уровне строк. Партиционирование также хорошо интегрируется с функциями ClickHouse, такими как TTL и многоуровневое хранение, что позволяет реализовать политики хранения или стратегии горячего/холодного хранения без необходимости в пользовательской оркестрации. Например, последние данные могут храниться на быстром SSD-хранилище, в то время как более старые партиции автоматически перемещаются в более дешевое объектное хранилище.
Хотя партиционирование может улучшить производительность запросов для некоторых загрузок, оно также может негативно повлиять на время отклика.
Если ключ партиционирования не входит в состав первичного ключа и вы фильтруете по нему, пользователи могут замечать улучшение производительности запросов с партиционированием. Смотрите здесь для примера.
С другой стороны, если запросы требуют выполнения запросов по партициям, это может негативно сказаться на производительности из-за большего количества частей в целом. По этой причине пользователи должны понимать свои паттерны доступа перед тем, как рассматривать партиционирование как технику оптимизации запросов.
В заключение, пользователи должны в первую очередь мыслить о партиционировании как о технике управления данными. Для примера управления данными смотрите "Управление данными" из руководства по случаям использования наблюдаемости и "Для чего используются таблицы партиций?" из основных концепций - Табличные партиции.
Выбор ключа партиционирования с низкой кардинальностью
Важно отметить, что более высокое количество частей negatively влияет на производительность запросов. Поэтому ClickHouse ответит на вставки с ошибкой “слишком много частей”, если количество частей превышает заданные ограничения как в общем, так и на партицию.
Выбор правильной кардинальности для ключа партиционирования критичен. Ключ партиционирования с высокой кардинальностью — когда количество различных значений партиции велико — может привести к значительному увеличению части данных. Поскольку ClickHouse не объединяет части между партициями, слишком много партиций приведет к слишком многим не объединенным частям, в конечном итоге вызывая ошибку “Слишком много частей”. Объединения необходимы для уменьшения фрагментации хранилища и оптимизации скорости запросов, но с партициями высокой кардинальности этот потенциал объединения теряется.
В отличие от этого, ключ партиционирования с низкой кардинальностью — с количеством различных значений менее 100 - 1 000 — обычно является оптимальным. Это обеспечивает эффективное объединение частей, поддерживает низкие накладные расходы на метаданные и избегает избыточного создания объектов в хранилище. Кроме того, ClickHouse автоматически создает MinMax индексы для колонок партиций, что может значительно ускорить запросы, которые фильтруют по этим колонкам. Например, фильтрация по месяцу, когда таблица партиционирована по toStartOfMonth(date), позволяет движку полностью пропустить нерелевантные партиции и их части.
Хотя партиционирование может улучшить производительность в некоторых паттернах запросов, оно в первую очередь является функцией управления данными. Во многих случаях выполнение запросов по всем партициям может быть медленнее, чем использование непартиционированной таблицы из-за увеличения фрагментации данных и большего количества частей, которые сканируются. Используйте партиционирование с осторожностью и всегда убеждайтесь, что выбранный ключ имеет низкую кардинальность и соответствует вашим политикам жизненного цикла данных (например, хранение via TTL). Если вы не уверены, необходимо ли партиционирование, вы можете начать без него и оптимизировать позже на основе наблюдаемых паттернов доступа.
