Выбор ключа партиционирования

Техника управления данными

Партиционирование в первую очередь является техникой управления данными, а не инструментом оптимизации запросов. Хотя оно может улучшить производительность в конкретных рабочих нагрузках, оно не должно быть первым механизмом, используемым для ускорения запросов; ключ партиционирования должен быть выбран внимательно, с ясным пониманием его последствий, и применяться только тогда, когда он соответствует потребностям жизненного цикла данных или хорошо понятным шаблонам доступа.

В ClickHouse партиционирование организует данные в логические сегменты на основе заданного ключа. Это определяется с помощью оператора PARTITION BY во время создания таблицы и обычно используется для группировки строк по временным интервалам, категориям или другим бизнес-значимым измерениям. Каждое уникальное значение выражения партиционирования образует собственную физическую партицию на диске, и ClickHouse хранит данные в отдельных частях для каждого из этих значений. Партиционирование улучшает управление данными, упрощает политики хранения и может помочь с определенными шаблонами запросов.

Например, рассмотрим следующий набор данных о ценах в Великобритании с ключом партиционирования toStartOfMonth(date).

CREATE TABLE uk.uk_price_paid_simple_partitioned
(
  date Date,
  town LowCardinality(String),
  street LowCardinality(String),
  price UInt32
)
ENGINE = MergeTree
ORDER BY (town, street)
PARTITION BY toStartOfMonth(date)

Когда набор строк вставляется в таблицу, вместо создания (по крайней мере) одной единственной части данных, содержащей все вставленные строки (как описано здесь), ClickHouse создает одну новую часть данных для каждого уникального значения ключа партиционирования среди вставленных строк:

Сервер ClickHouse сначала разделяет строки из приведенного выше примера вставки с 4 строками, изображенными на диаграмме, по их значению ключа партиционирования toStartOfMonth(date). Затем для каждой идентифицированной партиции строки обрабатываются как обычно, выполняя несколько последовательных шагов (① Сортировка, ② Разделение на колонки, ③ Сжатие, ④ Запись на диск).

Для более подробного объяснения партиционирования мы рекомендуем это руководство.

С включенным партиционированием ClickHouse только сливает части данных внутри, но не между партициями. Мы иллюстрируем это на примере нашей таблицы выше:

Применения партиционирования

Партиционирование является мощным инструментом для управления большими наборами данных в ClickHouse, особенно в областях наблюдаемости и аналитики. Оно обеспечивает эффективные операции жизненного цикла данных, позволяя целым партициям, часто согласованным с временной или бизнес-логикой, быть удаленными, перемещенными или архивированными за одну метаданные-операцию. Это значительно быстрее и менее ресурсоемко, чем операции удаления или копирования на уровне строк. Партиционирование также хорошо интегрируется с функциями ClickHouse, такими как TTL и многоуровневое хранилище, что позволяет реализовать политики хранения или стратегии горячего/холодного хранения без кастомной оркестрации. Например, последние данные могут храниться на быстром SSD-накопителе, в то время как более старые партиции автоматически перемещаются в более дешевое объектное хранилище.

Хотя партиционирование может улучшить производительность запросов для некоторых нагрузок, оно также может негативно сказаться на времени отклика.

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

Напротив, если запросы требуют выборки данных из нескольких партиций, производительность может быть негативно затронута из-за большего числа частей. По этой причине пользователи должны понимать свои шаблоны доступа, прежде чем рассматривать партиционирование как технику оптимизации запросов.

В заключение, пользователи должны в первую очередь рассматривать партиционирование как технику управления данными. Для примера управления данными смотрите "Управление данными" в руководстве по случаям наблюдаемости и "Для чего используются партиции таблиц?" из Основных концепций - Партиции таблиц.

Выбор ключа партиционирования с низкой кардинальностью

Важно, что большее количество частей негативно скажется на производительности запросов. Поэтому ClickHouse будет реагировать на вставки с ошибкой “слишком много частей”, если количество частей превышает заданные лимиты, либо в общем, либо по партициям.

Выбор правильной кардинальности для ключа партиционирования критичен. Ключ партиционирования с высокой кардинальностью - когда количество различных значений партиции велико - может привести к изобилию частей данных. Поскольку ClickHouse не сливает части между партициями, слишком много партиций приведет к слишком большому количеству неслитых частей, что в конечном итоге вызовет ошибку "Слишком много частей". Слияния необходимы для снижения фрагментации хранения и оптимизации скорости запросов, но при высококардинальных партициях этот потенциал слияния утрачивается.

Напротив, ключ партиционирования с низкой кардинальностью—с менее чем 100 - 1,000 различными значениями—обычно является оптимальным. Он обеспечивает эффективное слияние частей, удерживает накладные расходы метаданных на низком уровне и избегает чрезмерного создания объектов в хранилище. В дополнение, ClickHouse автоматически создает индексы MinMax по колонкам партиции, что может значительно ускорить запросы, которые фильтруют по этим колонкам. Например, фильтрация по месяцу, когда таблица партиционирована по toStartOfMonth(date), позволяет движку полностью пропустить незначимые партиции и их части.

Хотя партиционирование может улучшить производительность в некоторых шаблонах запросов, оно в первую очередь является функцией управления данными. Во многих случаях запросы через все партиции могут быть медленнее, чем использование непартиционированной таблицы из-за увеличенной фрагментации данных и большего количества проверяемых частей. Используйте партиционирование разумно и всегда убедитесь, что выбранный ключ имеет низкую кардинальность и соответствует вашим политикам жизненного цикла данных (например, хранение через TTL). Если вы не уверены, необходимо ли партиционирование, вы можете начать без него и оптимизировать позже на основе наблюдаемых шаблонов доступа.