mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-14 18:32:29 +00:00
137 lines
12 KiB
Markdown
137 lines
12 KiB
Markdown
---
|
||
slug: /ru/engines/table-engines/mergetree-family/custom-partitioning-key
|
||
sidebar_position: 32
|
||
sidebar_label: "Произвольный ключ партиционирования"
|
||
---
|
||
|
||
|
||
# Произвольный ключ партиционирования {#proizvolnyi-kliuch-partitsionirovaniia}
|
||
|
||
Партиционирование данных доступно для таблиц семейства [MergeTree](mergetree.md) (включая [реплицированные таблицы](replication.md)). Таблицы [MaterializedView](../special/materializedview.md#materializedview), созданные на основе таблиц MergeTree, также поддерживают партиционирование.
|
||
|
||
Партиция – это набор записей в таблице, объединенных по какому-либо критерию. Например, партиция может быть по месяцу, по дню или по типу события. Данные для разных партиций хранятся отдельно. Это позволяет оптимизировать работу с данными, так как при обработке запросов будет использоваться только необходимое подмножество из всевозможных данных. Например, при получении данных за определенный месяц, ClickHouse будет считывать данные только за этот месяц.
|
||
|
||
Ключ партиционирования задается при [создании таблицы](mergetree.md#table_engine-mergetree-creating-a-table), в секции `PARTITION BY expr`. Ключ может представлять собой произвольное выражение из столбцов таблицы. Например, чтобы задать партиционирования по месяцам, можно использовать выражение `toYYYYMM(date_column)`:
|
||
|
||
``` sql
|
||
CREATE TABLE visits
|
||
(
|
||
VisitDate Date,
|
||
Hour UInt8,
|
||
ClientID UUID
|
||
)
|
||
ENGINE = MergeTree()
|
||
PARTITION BY toYYYYMM(VisitDate)
|
||
ORDER BY Hour
|
||
```
|
||
|
||
Ключом партиционирования также может быть кортеж из выражений (аналогично [первичному ключу](mergetree.md#primary-keys-and-indexes-in-queries)). Например:
|
||
|
||
``` sql
|
||
ENGINE = ReplicatedCollapsingMergeTree('/clickhouse/tables/name', 'replica1', Sign)
|
||
PARTITION BY (toMonday(StartDate), EventType)
|
||
ORDER BY (CounterID, StartDate, intHash32(UserID));
|
||
```
|
||
|
||
В этом примере задано партиционирование по типам событий, произошедших в течение текущей недели.
|
||
|
||
По умолчанию, ключ партиционирования с плавающей запятой не поддерживается. Чтобы использовать его, включите настройку [allow_floating_point_partition_key](../../../operations/settings/merge-tree-settings.md#allow_floating_point_partition_key).
|
||
|
||
Каждая партиция состоит из отдельных фрагментов или так называемых *кусков данных*. Каждый кусок отсортирован по первичному ключу. При вставке данных в таблицу каждая отдельная запись сохраняется в виде отдельного куска. Через некоторое время после вставки (обычно до 10 минут), ClickHouse выполняет в фоновом режиме слияние данных — в результате куски для одной и той же партиции будут объединены в более крупный кусок.
|
||
|
||
:::info "Info"
|
||
Не рекомендуется делать слишком гранулированное партиционирование – то есть задавать партиции по столбцу, в котором будет слишком большой разброс значений (речь идет о порядке более тысячи партиций). Это приведет к скоплению большого числа файлов и файловых дескрипторов в системе, что может значительно снизить производительность запросов `SELECT`.
|
||
:::
|
||
|
||
Чтобы получить набор кусков и партиций таблицы, можно воспользоваться системной таблицей [system.parts](../../../engines/table-engines/mergetree-family/custom-partitioning-key.md#system_tables-parts). В качестве примера рассмотрим таблицу `visits`, в которой задано партиционирование по месяцам. Выполним `SELECT` для таблицы `system.parts`:
|
||
|
||
``` sql
|
||
SELECT
|
||
partition,
|
||
name,
|
||
active
|
||
FROM system.parts
|
||
WHERE table = 'visits'
|
||
```
|
||
|
||
``` text
|
||
┌─partition─┬─name──────────────┬─active─┐
|
||
│ 201901 │ 201901_1_3_1 │ 0 │
|
||
│ 201901 │ 201901_1_9_2_11 │ 1 │
|
||
│ 201901 │ 201901_8_8_0 │ 0 │
|
||
│ 201901 │ 201901_9_9_0 │ 0 │
|
||
│ 201902 │ 201902_4_6_1_11 │ 1 │
|
||
│ 201902 │ 201902_10_10_0_11 │ 1 │
|
||
│ 201902 │ 201902_11_11_0_11 │ 1 │
|
||
└───────────┴───────────────────┴────────┘
|
||
```
|
||
|
||
Столбец `partition` содержит имена всех партиций таблицы. Таблица `visits` из нашего примера содержит две партиции: `201901` и `201902`. Используйте значения из этого столбца в запросах [ALTER … PARTITION](../../../sql-reference/statements/alter/partition.md).
|
||
|
||
Столбец `name` содержит названия кусков партиций. Значения из этого столбца можно использовать в запросах [ALTER ATTACH PART](../../../sql-reference/statements/alter/partition.md#alter_attach-partition).
|
||
|
||
Столбец `active` отображает состояние куска. `1` означает, что кусок активен; `0` – неактивен. К неактивным можно отнести куски, оставшиеся после слияния данных. Поврежденные куски также отображаются как неактивные. Неактивные куски удаляются приблизительно через 10 минут после того, как было выполнено слияние.
|
||
|
||
Рассмотрим детальнее имя куска `201901_1_9_2_11`:
|
||
|
||
- `201901` имя партиции;
|
||
- `1` – минимальный номер блока данных;
|
||
- `9` – максимальный номер блока данных;
|
||
- `2` – уровень куска (глубина дерева слияний, которыми этот кусок образован).
|
||
- `11` - версия мутации (если парт мутировал)
|
||
|
||
:::info "Info"
|
||
Названия кусков для таблиц старого типа образуются следующим образом: `20190117_20190123_2_2_0` (минимальная дата _ максимальная дата _ номер минимального блока _ номер максимального блока _ уровень).
|
||
:::
|
||
|
||
Как видно из примера выше, таблица содержит несколько отдельных кусков для одной и той же партиции (например, куски `201901_1_3_1` и `201901_1_9_2` принадлежат партиции `201901`). Это означает, что эти куски еще не были объединены – в файловой системе они хранятся отдельно. После того как будет выполнено автоматическое слияние данных (выполняется примерно спустя 10 минут после вставки данных), исходные куски будут объединены в один более крупный кусок и помечены как неактивные.
|
||
|
||
Вы можете запустить внеочередное слияние данных с помощью запроса [OPTIMIZE](../../../sql-reference/statements/optimize.md). Пример:
|
||
|
||
``` sql
|
||
OPTIMIZE TABLE visits PARTITION 201902;
|
||
```
|
||
|
||
``` text
|
||
┌─partition─┬─name─────────────┬─active─┐
|
||
│ 201901 │ 201901_1_3_1 │ 0 │
|
||
│ 201901 │ 201901_1_9_2_11 │ 1 │
|
||
│ 201901 │ 201901_8_8_0 │ 0 │
|
||
│ 201901 │ 201901_9_9_0 │ 0 │
|
||
│ 201902 │ 201902_4_6_1 │ 0 │
|
||
│ 201902 │ 201902_4_11_2_11 │ 1 │
|
||
│ 201902 │ 201902_10_10_0 │ 0 │
|
||
│ 201902 │ 201902_11_11_0 │ 0 │
|
||
└───────────┴──────────────────┴────────┘
|
||
```
|
||
|
||
Неактивные куски будут удалены примерно через 10 минут после слияния.
|
||
|
||
Другой способ посмотреть набор кусков и партиций – зайти в директорию с данными таблицы: `/var/lib/clickhouse/data/<database>/<table>/`. Например:
|
||
|
||
``` bash
|
||
/var/lib/clickhouse/data/default/visits$ ls -l
|
||
total 40
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 1 16:48 201901_1_3_1
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 16:17 201901_1_9_2_11
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 15:52 201901_8_8_0
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 15:52 201901_9_9_0
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 16:17 201902_10_10_0
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 16:17 201902_11_11_0
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 16:19 201902_4_11_2_11
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 12:09 201902_4_6_1
|
||
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 1 16:48 detached
|
||
```
|
||
|
||
‘201901_1_1_0’, ‘201901_1_7_1’ и т. д. – это директории кусков партиции. Каждый кусок содержит данные только для соответствующего месяца (таблица в данном примере содержит партиционирование по месяцам).
|
||
|
||
Директория `detached` содержит куски, отсоединенные от таблицы с помощью запроса [DETACH](../../../sql-reference/statements/alter/partition.md#alter_detach-partition). Поврежденные куски также попадают в эту директорию – они не удаляются с сервера.
|
||
|
||
Сервер не использует куски из директории `detached`. Вы можете в любое время добавлять, удалять, модифицировать данные в директории detached - сервер не будет об этом знать, пока вы не сделаете запрос [ATTACH](../../../sql-reference/statements/alter/partition.md#alter_attach-partition).
|
||
|
||
Следует иметь в виду, что при работающем сервере нельзя вручную изменять набор кусков на файловой системе, так как сервер не будет знать об этом.
|
||
Для нереплицируемых таблиц, вы можете это делать при остановленном сервере, однако это не рекомендуется.
|
||
Для реплицируемых таблиц, набор кусков нельзя менять в любом случае.
|
||
|
||
ClickHouse позволяет производить различные манипуляции с кусками: удалять, копировать из одной таблицы в другую или создавать их резервные копии. Подробнее см. в разделе [Манипуляции с партициями и кусками](../../../sql-reference/statements/alter/partition.md).
|