Типы частей и форматы хранения

ClickHouse использует два независимых подхода к организации данных внутри частей:

Типы частей (Wide и Compact): как хранятся данные в столбцах внутри части
Форматы хранения (Full и Packed): как файлы части хранятся на диске

Типы частей: Wide vs Compact

Типы частей определяют, как данные столбцов организованы внутри части данных.

Тип	Описание	Лучше всего подходит для
Wide	Каждый столбец хранится в отдельном файле, у каждого свой файл меток	Запросов, выбирающих подмножество столбцов
Compact	Все столбцы хранятся в одном файле с одним файлом меток	Производительности ингестии и запросов, которым нужны все столбцы

Когда используется каждый тип

Тип части определяется следующими настройками таблицы:

min_bytes_for_wide_part: Минимальный размер части в байтах для использования формата Wide
min_rows_for_wide_part: Минимальное количество строк в части для использования формата Wide

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

Особенности производительности

Компактные части:

Более высокая производительность ингестии
Оптимальны, когда запросам нужны все столбцы
Более эффективны для небольших частей

Части Wide:

Более эффективны для запросов, выбирающих только часть столбцов
Лучше подходят для больших наборов данных с выборочным доступом к столбцам

Слияния compact-to-wide выполняются медленнее, чем wide-to-wide, потому что ClickHouse использует алгоритмы Вертикального слияния для преобразований compact-to-wide, а для слияний compact-to-compact — горизонтальные алгоритмы. Если вы хотите принудительно использовать части Wide независимо от размера, можно задать min_bytes_for_wide_part=0. Это может быть полезно в следующих сценариях:

Если у вас есть таблицы с большим количеством столбцов (например, более 600) и вы выполняете крупные вставки, установка этого значения в 0 может повысить производительность
Для оптимизации использования памяти системными таблицами, такими как system.metric_log и system.text_log, которые потребляют слишком много памяти во время слияний
При работе с таблицами с большим объёмом вставок, когда нужно оптимизировать хранилище и поведение слияния
Если вам нужно предсказуемое поведение формата частей и вы хотите избежать дополнительных издержек из-за переходов между форматами в зависимости от порогов размера

Стоит отметить, что, хотя установка этого значения в 0 может улучшить некоторые характеристики производительности, она может привести к увеличению числа GET-запросов к хранилищу S3 из-за формата частей Wide.

Ограничения

Статистика по размеру столбцов не рассчитывается для компактных частей, что может повлиять на мониторинг и оптимизацию. При запросе к system.parts_columns для компактных частей выводится 0 в полях column_data_compressed_bytes и column_data_uncompressed_bytes. Подробнее см. в разделе «Найти количество и размеры широких или компактных частей».

Форматы хранения: Full и Packed

Форматы хранения определяют, как файлы части физически размещаются на диске.

Формат	Описание	Доступность
Full	Каждый файл хранится отдельно в каталоге части	С открытым исходным кодом и Cloud
Packed	Большинство файлов части объединены в один архивный файл (проекции и несколько служебных файлов записываются отдельно)	С открытым исходным кодом и Cloud

Полное хранилилилище

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

Хранилище Packed

В хранилилище Packed большинство файлов частей объединены в один архив. Проекции и несколько служебных файлов — txn_version.txt, delete-on-destroy.txt и invalidated_system_columns.txt — по-прежнему записываются отдельно, поскольку они могут быть созданы или перезаписаны после записи самой части. Это значительно сокращает количество файловых операций, что особенно важно для удалённых хранилищ, таких как S3, где каждый запрос связан с задержкой и дополнительными затратами. Преимущества хранилилища Packed:

Меньше вызовов API S3/Объектного хранилища
Меньшая нагрузка на метаданные в службе координации
Более низкие затраты на хранилилилище (полное хранилилилище может быть значительно дороже)
Более высокая производительность для небольших частей в удалённом хранилилище

Когда используется хранилище Packed

Для части используется хранилище Packed, если выполняется хотя бы одно из следующих условий:

Объём несжатых данных < min_bytes_for_full_part_storage
Число строк < min_rows_for_full_part_storage
Уровень слияния < min_level_for_full_part_storage

Хранилище Packed включается явно: все три настройки по умолчанию имеют значение 0, поэтому части используют полное хранилилилище, если вы не увеличите одну из них.

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

Настройку min_level_for_full_part_storage можно использовать для оптимизации производительности и затрат на объектном хранилище, особенно для таблиц с непрерывной ингестией данных. Эта настройка доступна начиная с ClickHouse версии 25.10 и работает совместно с min_level_for_wide_part, обеспечивая полный контроль над стратегиями хранения частей. Изменение её значения по умолчанию (0) может быть оправдано в следующих случаях:

Если в таблицы регулярно поступают данные, исходные части быстро сливаются, поэтому хранить их изначально в полном формате неэффективно
Этот параметр позволяет избежать дорогостоящих S3 PUT-запросов при вставках. Например, один анализ показал, что вставки, создающие полные части, в среднем требовали 31,3 PUT-запроса на одну вставку, тогда как вставки, создающие только части Packed, — всего 2,22 PUT-запроса на одну вставку
Операции вставки выполняются быстрее, особенно для таблиц с большим количеством столбцов, поскольку хранилилище Packed записывает все данные в один файл, а не создаёт отдельные файлы для каждого столбца.

Рекомендуемая конфигурация: Установите min_level_for_full_part_storage = 2 для развертываний с объектным хранилищем. Это гарантирует, что:

Части уровня 0 (исходные вставки) используют хранилище Packed
Части уровня 1 также продолжают использовать хранилище Packed
Только части уровня 2 и выше используют полный формат хранения

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

Комбинирование типов частей и форматов хранения

Эти две концепции не зависят друг от друга, и возможна любая их комбинация:

Комбинация	Сценарий использования
Wide + Full	Крупные части в локальном хранилище (по умолчанию)
Wide + Packed	Крупные части в объектном хранилище
Compact + Full	Небольшие части в локальном хранилище
Compact + Packed	Небольшие части в объектном хранилище

Запрос информации о частях

Вы можете посмотреть тип части и тип хранилища существующих частей с помощью таблицы system.parts:

В open-source ClickHouse part_storage_type доступен в system.parts начиная с версии 26.9. В версии 26.8 и более ранних версиях исключите part_storage_type из запроса и выполняйте группировку и сортировку только по part_type.

SELECT
    part_type,
    part_storage_type,
    max(level),
    count(),
    formatReadableSize(max(data_uncompressed_bytes)),
    formatReadableSize(min(data_uncompressed_bytes))
FROM system.parts
WHERE (database != 'system') AND active
GROUP BY
    1,
    2
ORDER BY
    1 ASC,
    2 ASC

Вы увидите что-то вроде этого:

   ┌─part_type─┬─part_storage_type─┬─max(level)─┬─count()─┬─formatReadab⋯sed_bytes))─┬─formatReadab⋯sed_bytes))─┐
1. │ Compact   │ Full              │      12688 │    2456 │ 1023.87 MiB              │ 23.78 MiB                │
2. │ Compact   │ Packed            │      97383 │   13748 │ 127.77 MiB               │ 1.00 B                   │
3. │ Wide      │ Full              │       7642 │    2000 │ 1.38 TiB                 │ 30.18 MiB                │
4. │ Wide      │ Packed            │         10 │     187 │ 110.01 MiB               │ 1.30 KiB                 │
   └───────────┴───────────────────┴────────────┴─────────┴──────────────────────────┴──────────────────────────┘

​Типы частей: Wide vs Compact

​Когда используется каждый тип

​Особенности производительности

​Ограничения

​Форматы хранения: Full и Packed

​Полное хранилилилище

​Хранилище Packed

​Когда используется хранилище Packed

​Комбинирование типов частей и форматов хранения

​Запрос информации о частях

Типы частей: Wide vs Compact

Когда используется каждый тип

Особенности производительности

Ограничения

Форматы хранения: Full и Packed

Полное хранилилилище

Хранилище Packed

Когда используется хранилище Packed

Комбинирование типов частей и форматов хранения

Запрос информации о частях