Движок таблицы MergeTree

Движок MergeTree и другие движки семейства MergeTree (например, ReplacingMergeTree, AggregatingMergeTree) являются наиболее часто используемыми и наиболее надёжными движками таблиц в ClickHouse.

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

Основные особенности движков таблиц семейства MergeTree.

Первичный ключ таблицы определяет порядок сортировки внутри каждой части таблицы (кластерный индекс). При этом первичный ключ указывает не на отдельные строки, а на блоки по 8192 строки, которые называются гранулами. Это делает первичные ключи для очень больших наборов данных достаточно компактными, чтобы оставаться загруженными в основную память, при этом обеспечивая быстрый доступ к данным на диске.
Таблицы могут быть разбиты на разделы (партиции) с использованием произвольного выражения секционирования. Исключение разделов (partition pruning) гарантирует, что такие разделы пропускаются при чтении, когда это допускает запрос.
Данные могут реплицироваться между несколькими узлами кластера для обеспечения высокой доступности, отказоустойчивости и обновлений без простоя. См. раздел Репликация данных.
Движки таблиц MergeTree поддерживают различные виды статистики и методы выборочного чтения (sampling), помогающие оптимизировать запросы.

Примечание

Несмотря на похожее название, движок Merge отличается от движков *MergeTree.

Создание таблиц

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
    name1 [type1] [[NOT] NULL] [DEFAULT|MATERIALIZED|ALIAS|EPHEMERAL expr1] [COMMENT ...] [CODEC(codec1)] [STATISTICS(stat1)] [TTL expr1] [PRIMARY KEY] [SETTINGS (name = value, ...)],
    name2 [type2] [[NOT] NULL] [DEFAULT|MATERIALIZED|ALIAS|EPHEMERAL expr2] [COMMENT ...] [CODEC(codec2)] [STATISTICS(stat2)] [TTL expr2] [PRIMARY KEY] [SETTINGS (name = value, ...)],
    ...
    INDEX index_name1 expr1 TYPE type1(...) [GRANULARITY value1],
    INDEX index_name2 expr2 TYPE type2(...) [GRANULARITY value2],
    ...
    PROJECTION projection_name_1 (SELECT <COLUMN LIST EXPR> [GROUP BY] [ORDER BY]),
    PROJECTION projection_name_2 (SELECT <COLUMN LIST EXPR> [GROUP BY] [ORDER BY])
) ENGINE = MergeTree()
ORDER BY expr
[PARTITION BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[TTL expr
    [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx' [, ...] ]
    [WHERE conditions]
    [GROUP BY key_expr [SET v1 = aggr_func(v1) [, v2 = aggr_func(v2) ...]] ] ]
[SETTINGS name = value, ...]

Подробное описание параметров см. в описании оператора CREATE TABLE

Части запроса

ENGINE

ENGINE — имя и параметры движка таблицы. ENGINE = MergeTree(). Движок таблицы MergeTree не имеет параметров.

ORDER BY

ORDER BY — ключ сортировки.

Кортеж имён столбцов или произвольных выражений. Пример: ORDER BY (CounterID + 1, EventDate).

Если первичный ключ не определён (то есть PRIMARY KEY не был указан), ClickHouse использует ключ сортировки в качестве первичного ключа.

Если сортировка не требуется, можно использовать синтаксис ORDER BY tuple(). Либо, если включена настройка create_table_empty_primary_key_by_default, ORDER BY () неявно добавляется к операторам CREATE TABLE. См. раздел Выбор первичного ключа.

PARTITION BY

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

Для партиционирования по месяцам используйте выражение toYYYYMM(date_column), где date_column — это столбец с датой типа Date. Имена партиций в этом случае имеют формат "YYYYMM".

PRIMARY KEY

PRIMARY KEY — первичный ключ, если он отличается от сортировочного ключа. Необязательный параметр.

Указание сортировочного ключа (с помощью клаузы ORDER BY) неявно задаёт первичный ключ. Обычно нет необходимости указывать первичный ключ дополнительно к сортировочному ключу.

SAMPLE BY

SAMPLE BY — выражение для семплирования (sampling expression). Необязательное выражение.

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

Пример: SAMPLE BY intHash32(UserID) ORDER BY (CounterID, EventDate, intHash32(UserID)).

TTL

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

Выражение должно возвращать Date или DateTime, например, TTL date + INTERVAL 1 DAY.

Тип правила DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'|GROUP BY определяет действие, которое выполняется с частью, если выражение удовлетворяется (достигает текущего времени): удаление истёкших строк, перемещение части (если выражение выполняется для всех строк в части) на указанный диск (TO DISK 'xxx') или на том (TO VOLUME 'xxx'), либо агрегация значений в истёкших строках. Тип правила по умолчанию — удаление (DELETE). Можно задать список из нескольких правил, но не более одного правила DELETE.

Подробнее см. TTL для столбцов и таблиц

ПАРАМЕТРЫ

См. настройки MergeTree.

Пример настройки параметра sections

ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID) SETTINGS index_granularity=8192

В этом примере мы задаём секционирование по месяцам.

Мы также задаём выражение для выборочного чтения данных в виде хэша по ID пользователя. Это позволяет псевдослучайно распределить данные в таблице для каждого CounterID и EventDate. Если вы укажете предложение SAMPLE при выборке данных, ClickHouse вернёт равномерную псевдослучайную выборку данных для подмножества пользователей.

Параметр index_granularity можно опустить, так как 8192 — это значение по умолчанию.

Устаревший метод создания таблицы

Примечание

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

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
    name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
    name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
    ...
) ENGINE [=] MergeTree(date-column [, sampling_expression], (primary, key), index_granularity)

Параметры MergeTree()

date-column — Имя столбца типа Date. ClickHouse автоматически создаёт партиции по месяцам на основе этого столбца. Имена партиций имеют формат "YYYYMM".
sampling_expression — Выражение для выборочного чтения данных.
(primary, key) — Первичный ключ. Тип: Tuple()
index_granularity — Гранулярность индекса. Количество строк данных между «метками» индекса. Значение 8192 подходит для большинства задач.

Пример

MergeTree(EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID)), 8192)

Движок MergeTree настраивается так же, как в примере выше для основного метода конфигурации движка.

Хранение данных

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

При вставке данных в таблицу создаются отдельные части данных, и каждая из них лексикографически сортируется по первичному ключу. Например, если первичный ключ — (CounterID, Date), данные в части сортируются по CounterID, а внутри каждого CounterID упорядочиваются по Date.

Данные, принадлежащие разным партициям, разделяются на отдельные части. В фоновом режиме ClickHouse сливает части данных для более эффективного хранения. Части, принадлежащие разным партициям, не сливаются. Механизм слияния не гарантирует, что все строки с одинаковым первичным ключом окажутся в одной и той же части.

Части данных могут храниться в форматах Wide или Compact. В формате Wide каждый столбец хранится в отдельном файле в файловой системе, в формате Compact все столбцы хранятся в одном файле. Формат Compact может использоваться для повышения производительности при небольших и частых вставках.

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

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

Размер гранулы ограничивается параметрами движка таблицы index_granularity и index_granularity_bytes. Число строк в грануле находится в диапазоне [1, index_granularity] и зависит от размера строк. Размер гранулы может превышать index_granularity_bytes, если размер одной строки больше значения этого параметра. В этом случае размер гранулы равен размеру строки.

Первичные ключи и индексы в запросах

Рассмотрим в качестве примера первичный ключ (CounterID, Date). В этом случае сортировку и индекс можно представить следующим образом:

Все данные:     [---------------------------------------------]
CounterID:      [aaaaaaaaaaaaaaaaaabbbbcdeeeeeeeeeeeeefgggggggghhhhhhhhhiiiiiiiiikllllllll]
Date:           [1111111222222233331233211111222222333211111112122222223111112223311122333]
Метки:           |      |      |      |      |      |      |      |      |      |      |
                a,1    a,2    a,3    b,3    e,2    e,3    g,1    h,2    i,1    i,3    l,3
Номера меток:    0      1      2      3      4      5      6      7      8      9      10

Если в запросе к данным указано:

CounterID in ('a', 'h'), сервер читает данные в диапазонах меток [0, 3) и [6, 8).
CounterID IN ('a', 'h') AND Date = 3, сервер читает данные в диапазонах меток [1, 3) и [7, 8).
Date = 3, сервер читает данные в диапазоне меток [1, 10].

Приведённые выше примеры показывают, что использование индекса всегда эффективнее, чем полное сканирование.

Разреженный индекс допускает чтение лишних данных. При чтении одного диапазона первичного ключа в каждом блоке данных может быть прочитано до index_granularity * 2 дополнительных строк.

Разреженные индексы позволяют работать с очень большим числом строк в таблице, потому что в большинстве случаев такие индексы помещаются в оперативную память.

ClickHouse не требует уникального первичного ключа. Вы можете вставлять несколько строк с одинаковым первичным ключом.

Вы можете использовать выражения типа Nullable в выражениях PRIMARY KEY и ORDER BY, но это настоятельно не рекомендуется. Чтобы включить эту возможность, активируйте настройку allow_nullable_key. Принцип NULLS_LAST применяется к значениям NULL в выражении ORDER BY.

Выбор первичного ключа

Количество столбцов в первичном ключе явно не ограничено. В зависимости от структуры данных вы можете включать больше или меньше столбцов в первичный ключ. Это может:

Повысить производительность индекса.

Если первичный ключ — (a, b), то добавление дополнительного столбца c улучшит производительность, если выполняются следующие условия:
- Есть запросы с условием по столбцу c.
- Длинные диапазоны данных (в несколько раз длиннее, чем index_granularity) с одинаковыми значениями для (a, b) встречаются часто. Другими словами, добавление еще одного столбца позволяет пропускать достаточно длинные диапазоны данных.
Улучшить сжатие данных.

ClickHouse сортирует данные по первичному ключу, поэтому чем выше упорядоченность, тем лучше сжатие.
Обеспечить дополнительную логику при слиянии частей данных в движках CollapsingMergeTree и SummingMergeTree.

В этом случае имеет смысл указать ключ сортировки, отличающийся от первичного ключа.

Длинный первичный ключ негативно влияет на производительность операций вставки и потребление памяти, но дополнительные столбцы в первичном ключе не влияют на производительность ClickHouse при выполнении SELECT‑запросов.

Вы можете создать таблицу без первичного ключа, используя синтаксис ORDER BY tuple(). В этом случае ClickHouse хранит данные в порядке вставки. Если вы хотите сохранить порядок данных при вставке через запросы INSERT ... SELECT, установите max_insert_threads = 1.

Чтобы выбирать данные в исходном порядке, используйте однопоточные SELECT‑запросы.

Выбор первичного ключа, отличного от ключа сортировки

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

Эта возможность полезна при использовании движков таблиц SummingMergeTree и AggregatingMergeTree. В типичном случае при использовании этих движков таблица содержит два типа столбцов: измерения и показатели. Типичные запросы агрегируют значения столбцов-показателей с произвольным GROUP BY и фильтрацией по измерениям. Поскольку SummingMergeTree и AggregatingMergeTree агрегируют строки с одинаковым значением ключа сортировки, естественно включить в него все измерения. В результате выражение ключа состоит из длинного списка столбцов, и этот список необходимо часто обновлять при добавлении новых измерений.

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

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

Использование индексов и партиций в запросах

Для запросов SELECT ClickHouse анализирует, может ли быть использован индекс. Индекс может быть использован, если предложение WHERE/PREWHERE содержит выражение (как один из элементов конъюнкции или целиком), представляющее собой операцию сравнения на равенство или неравенство, или если оно содержит IN или LIKE с фиксированным префиксом по столбцам или выражениям, входящим в первичный ключ или ключ партиционирования, или по определённым частично повторяющимся функциям этих столбцов, или логические комбинации этих выражений.

Таким образом, можно быстро выполнять запросы по одному или нескольким диапазонам первичного ключа. В этом примере запросы будут выполняться быстро при выборке по конкретному тегу отслеживания, по конкретному тегу и диапазону дат, по конкретному тегу и дате, по нескольким тегам с диапазоном дат и так далее.

Рассмотрим движок, настроенный следующим образом:

ENGINE MergeTree()
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate)
SETTINGS index_granularity=8192

В таком случае в запросах:

SELECT count() FROM table
WHERE EventDate = toDate(now())
AND CounterID = 34

SELECT count() FROM table
WHERE EventDate = toDate(now())
AND (CounterID = 34 OR CounterID = 42)

SELECT count() FROM table
WHERE ((EventDate >= toDate('2014-01-01')
AND EventDate <= toDate('2014-01-31')) OR EventDate = toDate('2014-05-01'))
AND CounterID IN (101500, 731962, 160656)
AND (CounterID = 101500 OR EventDate != toDate('2014-05-01'))

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

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

В приведённом ниже примере индекс использоваться не будет.

SELECT count() FROM table WHERE CounterID = 34 OR URL LIKE '%upyachka%'

Чтобы проверить, может ли ClickHouse использовать индекс при выполнении запроса, используйте настройки force_index_by_date и force_primary_key.

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

Использование индекса для частично-монотонных первичных ключей

Рассмотрим, например, дни месяца. Они образуют монотонную последовательность в пределах одного месяца, но не являются монотонными на более длительных промежутках времени. Это частично-монотонная последовательность. Если пользователь создаёт таблицу с частично-монотонным первичным ключом, ClickHouse создаёт разреженный индекс как обычно. Когда пользователь выбирает данные из такой таблицы, ClickHouse анализирует условия запроса. Если пользователь хочет получить данные между двумя метками индекса и обе эти метки попадают в один месяц, ClickHouse может использовать индекс в этом конкретном случае, потому что он может вычислить расстояние между параметрами запроса и метками индекса.

ClickHouse не может использовать индекс, если значения первичного ключа в заданном в параметрах запроса диапазоне не образуют монотонную последовательность. В этом случае ClickHouse использует полное сканирование.

ClickHouse применяет эту логику не только к последовательностям дней месяца, но и к любому первичному ключу, который представляет частично-монотонную последовательность.

Индексы пропуска данных

Объявление индекса указывается в разделе COLUMNS оператора CREATE.

INDEX index_name expr TYPE type(...) [GRANULARITY granularity_value]

Для таблиц из семейства *MergeTree можно задать индексы пропуска данных (data skipping indices).

Эти индексы агрегируют некоторую информацию об указанном выражении по блокам, которые состоят из гранул размера granularity_value (размер гранулы задаётся с помощью настройки index_granularity в движке таблицы). Затем эти агрегаты используются в запросах SELECT для уменьшения объёма данных, считываемых с диска, за счёт пропуска крупных блоков данных, в которых условие секции WHERE не может быть выполнено.

Секцию GRANULARITY можно опустить, значение granularity_value по умолчанию равно 1.

Пример

CREATE TABLE table_name
(
    u64 UInt64,
    i32 Int32,
    s String,
    ...
    INDEX idx1 u64 TYPE bloom_filter GRANULARITY 3,
    INDEX idx2 u64 * i32 TYPE minmax GRANULARITY 3,
    INDEX idx3 u64 * length(s) TYPE set(1000) GRANULARITY 4
) ENGINE = MergeTree()
...

ClickHouse может использовать индексы из примера, чтобы сократить объём данных, считываемых с диска, в следующих запросах:

SELECT count() FROM table WHERE u64 == 10;
SELECT count() FROM table WHERE u64 * i32 >= 1234
SELECT count() FROM table WHERE u64 * length(s) == 1234

Индексы пропуска данных также могут создаваться для составных столбцов:

-- для столбцов типа Map:
INDEX map_key_index mapKeys(map_column) TYPE bloom_filter
INDEX map_value_index mapValues(map_column) TYPE bloom_filter

-- для столбцов типа Tuple:
INDEX tuple_1_index tuple_column.1 TYPE bloom_filter
INDEX tuple_2_index tuple_column.2 TYPE bloom_filter

-- для столбцов типа Nested:
INDEX nested_1_index col.nested_col1 TYPE bloom_filter
INDEX nested_2_index col.nested_col2 TYPE bloom_filter

Типы пропускающих индексов

Движок таблицы MergeTree поддерживает следующие типы пропускающих индексов. Подробнее об использовании пропускающих индексов для оптимизации производительности см. в разделе "Понимание пропускающих индексов данных в ClickHouse".

индекс MinMax
индекс Set
индекс bloom_filter
индекс ngrambf_v1
индекс tokenbf_v1

Индекс MinMax

Для каждой гранулы индекса сохраняются минимальные и максимальные значения выражения. (Если выражение имеет тип tuple, сохраняются минимальные и максимальные значения для каждого элемента кортежа.)

minmax

Set

Для каждой гранулы индекса сохраняется не более max_rows уникальных значений указанного выражения. max_rows = 0 означает «хранить все уникальные значения».

set(max_rows)

Фильтр Блума

Для каждой гранулы индекса хранится фильтр Блума по указанным столбцам.

bloom_filter([false_positive_rate])

Параметр false_positive_rate может принимать значение от 0 до 1 (по умолчанию: 0.025) и задаёт вероятность положительного срабатывания (что увеличивает объём считываемых данных).

Поддерживаются следующие типы данных:

(U)Int*
Float*
Enum
Date
DateTime
String
FixedString
Array
LowCardinality
Nullable
UUID
Map

Тип данных Map: указание создания индекса по ключам или значениям

Для типа данных Map клиент может указать, должен ли индекс создаваться по ключам или по значениям, с помощью функций mapKeys или mapValues.

N-граммовый Bloom-фильтр

Для каждой гранулы индекса хранится Bloom-фильтр по n-граммам указанных столбцов.

ngrambf_v1(n, size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)

Parameter	Description
`n`	размер n-граммы
`size_of_bloom_filter_in_bytes`	Размер фильтра Блума в байтах. Здесь можно использовать большое значение, например `256` или `512`, поскольку оно хорошо сжимается.
`number_of_hash_functions`	Количество хеш-функций, используемых в фильтре Блума.
`random_seed`	Начальное значение (seed) для хеш-функций фильтра Блума.

Этот индекс работает только со следующими типами данных:

Чтобы оценить параметры ngrambf_v1, вы можете использовать следующие пользовательские функции (UDF).

CREATE FUNCTION bfEstimateFunctions [ON CLUSTER cluster]
AS
(total_number_of_all_grams, size_of_bloom_filter_in_bits) -> round((size_of_bloom_filter_in_bits / total_number_of_all_grams) * log(2));

CREATE FUNCTION bfEstimateBmSize [ON CLUSTER cluster]
AS
(total_number_of_all_grams,  probability_of_false_positives) -> ceil((total_number_of_all_grams * log(probability_of_false_positives)) / log(1 / pow(2, log(2))));

CREATE FUNCTION bfEstimateFalsePositive [ON CLUSTER cluster]
AS
(total_number_of_all_grams, number_of_hash_functions, size_of_bloom_filter_in_bytes) -> pow(1 - exp(-number_of_hash_functions/ (size_of_bloom_filter_in_bytes / total_number_of_all_grams)), number_of_hash_functions);

CREATE FUNCTION bfEstimateGramNumber [ON CLUSTER cluster]
AS
(number_of_hash_functions, probability_of_false_positives, size_of_bloom_filter_in_bytes) -> ceil(size_of_bloom_filter_in_bytes / (-number_of_hash_functions / log(1 - exp(log(probability_of_false_positives) / number_of_hash_functions))))

Чтобы использовать эти функции, необходимо указать не менее двух параметров:

total_number_of_all_grams
probability_of_false_positives

Например, в грануле есть 4300 n-грамм, и вы ожидаете, что вероятность ложных срабатываний будет меньше 0.0001. Остальные параметры можно затем оценить, выполнив следующие запросы:

--- оценить количество битов в фильтре
SELECT bfEstimateBmSize(4300, 0.0001) / 8 AS size_of_bloom_filter_in_bytes;

┌─size_of_bloom_filter_in_bytes─┐
│                         10304 │
└───────────────────────────────┘

--- оценить количество хеш-функций
SELECT bfEstimateFunctions(4300, bfEstimateBmSize(4300, 0.0001)) as number_of_hash_functions

┌─number_of_hash_functions─┐
│                       13 │
└──────────────────────────┘

Разумеется, вы также можете использовать эти функции для оценки параметров и в других условиях. Приведённые выше функции соответствуют калькулятору фильтра Блума, доступному по адресу здесь.

Фильтр Блума по токенам

Фильтр Блума по токенам аналогичен ngrambf_v1, но вместо n-грамм хранит токены (последовательности, разделённые небуквенно-цифровыми символами).

tokenbf_v1(size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)

Разрежённый n-граммный фильтр Блума

Разрежённый n-граммный фильтр Блума аналогичен ngrambf_v1, но использует токены разрежённых n-грамм вместо n-грамм.

sparse_grams(min_ngram_length, max_ngram_length, min_cutoff_length, size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)

Текстовый индекс

Поддерживает полнотекстовый поиск; подробности см. здесь.

Сходство векторов

Поддерживает приближённый поиск ближайших соседей, подробнее см. здесь.

Поддержка функций

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

Индексы типа set могут использоваться всеми функциями. Остальные типы индексов поддерживаются следующим образом:

Функция (оператор) / Индекс	первичный ключ	minmax	ngrambf_v1	tokenbf_v1	bloom_filter	sparse_grams	текст
равно (=, ==)	✔	✔	✔	✔	✔	✔	✔
notEquals(!=, <>)	✔	✔	✔	✔	✔	✔	✔
like	✔	✔	✔	✔	✗	✔	✔
notLike	✔	✔	✔	✔	✗	✔	✔
match	✗	✗	✔	✔	✗	✔	✔
startsWith	✔	✔	✔	✔	✗	✔	✔
endsWith	✗	✗	✔	✔	✗	✔	✔
multiSearchAny	✗	✗	✔	✗	✗	✗	✗
in	✔	✔	✔	✔	✔	✔	✔
notIn	✔	✔	✔	✔	✔	✔	✔
меньше (`<`)	✔	✔	✗	✗	✗	✗	✗
greater (`>`)	✔	✔	✗	✗	✗	✗	✗
lessOrEquals (`<=`)	✔	✔	✗	✗	✗	✗	✗
greaterOrEquals (`>=`)	✔	✔	✗	✗	✗	✗	✗
empty	✔	✔	✗	✗	✗	✗	✗
notEmpty	✗	✔	✗	✗	✗	✔	✗
has	✗	✗	✔	✔	✔	✔	✔
hasAny	✗	✗	✔	✔	✔	✔	✗
hasAll	✗	✗	✔	✔	✔	✔	✗
hasToken	✗	✗	✗	✔	✗	✗	✔
hasTokenOrNull	✗	✗	✗	✔	✗	✗	✔
hasTokenCaseInsensitive (`*`)	✗	✗	✗	✔	✗	✗	✗
hasTokenCaseInsensitiveOrNull (`*`)	✗	✗	✗	✔	✗	✗	✗
hasAnyTokens	✗	✗	✗	✗	✗	✗	✔
hasAllTokens	✗	✗	✗	✗	✗	✗	✔
mapContains	✗	✗	✗	✗	✗	✗	✔

Функции с константным аргументом, значение которого меньше размера n-граммы, не могут использоваться индексом ngrambf_v1 для оптимизации запросов.

(*) Чтобы hasTokenCaseInsensitive и hasTokenCaseInsensitiveOrNull были эффективны, индекс tokenbf_v1 должен быть создан по данным в нижнем регистре, например: INDEX idx (lower(str_col)) TYPE tokenbf_v1(512, 3, 0).

Примечание

У фильтров Блума возможны ложноположительные срабатывания, поэтому индексы ngrambf_v1, tokenbf_v1, sparse_grams и bloom_filter не могут использоваться для оптимизации запросов, в которых ожидается, что результат функции будет ложным.

Например:

Может быть оптимизировано:
- s LIKE '%test%'
- NOT s NOT LIKE '%test%'
- s = 1
- NOT s != 1
- startsWith(s, 'test')
Не может быть оптимизировано:
- NOT s LIKE '%test%'
- s NOT LIKE '%test%'
- NOT s = 1
- s != 1
- NOT startsWith(s, 'test')

Проекции

Проекции похожи на materialized views, но определяются на уровне частей таблицы (parts). Они обеспечивают гарантии согласованности, а также автоматическое использование в запросах.

Примечание

При использовании проекций следует также учитывать настройку force_optimize_projection.

Проекции не поддерживаются в операторах SELECT с модификатором FINAL.

Запрос проекции

Запрос проекции определяет проекцию. Он неявно выбирает данные из родительской таблицы. Синтаксис

SELECT <выражение списка столбцов> [GROUP BY] <выражение ключей группировки> [ORDER BY] <выражение>

Проекции можно изменять или удалять с помощью оператора ALTER.

Хранение проекций

Проекции хранятся внутри каталога части. По сути это похоже на индекс, но включает подкаталог, в котором хранится часть анонимной таблицы MergeTree. Таблица задаётся запросом, определяющим проекцию. Если в определении есть предложение GROUP BY, базовый движок хранения становится AggregatingMergeTree, и все агрегатные функции приводятся к типу AggregateFunction. Если есть предложение ORDER BY, таблица MergeTree использует его как выражение первичного ключа. Во время процесса слияния часть проекции объединяется с использованием процедуры слияния её движка хранения. Контрольная сумма части родительской таблицы объединяется с частью проекции. Остальные операции обслуживания аналогичны операциям для skip-индексов.

Анализ запросов

Проверьте, может ли проекция быть использована для ответа на данный запрос, то есть даёт ли она тот же результат, что и запрос к базовой таблице.
Выберите оптимальное соответствие, для которого нужно прочитать наименьшее количество гранул.
Конвейер обработки запроса, использующий проекции, будет отличаться от конвейера, работающего с исходными частями. Если в некоторых частях проекция отсутствует, можно добавить конвейер, чтобы «спроецировать» её на лету.

Одновременный доступ к данным

Для одновременного доступа к таблице используется многоверсионность. Иными словами, когда таблица одновременно читается и обновляется, данные читаются из набора частей, актуального на момент выполнения запроса. Длительные блокировки отсутствуют. Вставки не мешают операциям чтения.

Чтение из таблицы автоматически распараллеливается.

TTL для столбцов и таблиц

Определяет время жизни значений.

Выражение TTL может быть задано как для всей таблицы, так и для каждого отдельного столбца. TTL на уровне таблицы также может задавать логику автоматического перемещения данных между дисками и томами, а также перекомпрессии частей, в которых срок жизни всех данных истёк.

Выражения должны вычисляться в значение типа данных Date, Date32, DateTime или DateTime64.

Синтаксис

Установка времени жизни для столбца:

TTL time_column
TTL time_column + interval

Чтобы задать interval, используйте операторы интервалов времени, например:

TTL date_time + INTERVAL 1 MONTH
TTL date_time + INTERVAL 15 HOUR

TTL столбца

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

Предложение TTL нельзя использовать для ключевых столбцов.

Примеры

Создание таблицы с параметром `TTL`:

CREATE TABLE tab
(
    d DateTime,
    a Int TTL d + INTERVAL 1 MONTH,
    b Int TTL d + INTERVAL 1 MONTH,
    c String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d;

Добавление TTL для столбца существующей таблицы

ALTER TABLE tab
    MODIFY COLUMN
    c String TTL d + INTERVAL 1 DAY;

Изменение TTL для столбца

ALTER TABLE tab
    MODIFY COLUMN
    c String TTL d + INTERVAL 1 MONTH;

TTL таблицы

Для таблицы может быть задано выражение для удаления строк с истекшим сроком жизни и несколько выражений для автоматического перемещения частей между дисками или томами. Когда срок жизни строк в таблице истекает, ClickHouse удаляет все соответствующие строки. Для перемещения или перекомпрессии частей все строки части должны удовлетворять критериям выражения TTL.

TTL expr
    [DELETE|RECOMPRESS codec_name1|НА ДИСК 'xxx'|НА ТОМ 'xxx'][, DELETE|RECOMPRESS codec_name2|НА ДИСК 'aaa'|НА ТОМ 'bbb'] ...
    [WHERE условия]
    [GROUP BY key_expr [SET v1 = aggr_func(v1) [, v2 = aggr_func(v2) ...]] ]

Тип правила TTL может следовать за каждым выражением TTL. Он определяет действие, которое будет выполнено, когда выражение будет выполнено (достигнет текущего времени):

DELETE — удалить истекшие строки (действие по умолчанию);
RECOMPRESS codec_name — перекомпрессировать часть данных с использованием codec_name;
TO DISK 'aaa' — перенести часть на диск aaa;
TO VOLUME 'bbb' — перенести часть в том bbb;
GROUP BY — агрегировать истекшие строки.

Действие DELETE может использоваться вместе с предложением WHERE, чтобы удалять только часть истекших строк на основе условия фильтрации:

TTL time_column + INTERVAL 1 MONTH УДАЛИТЬ ГДЕ column = 'value'

Выражение GROUP BY должно быть префиксом первичного ключа таблицы.

Если столбец не входит в выражение GROUP BY и явно не задан в предложении SET, в результирующей строке он будет содержать произвольное значение из сгруппированных строк (как если бы к нему была применена агрегатная функция any).

Примеры

Создание таблицы с `TTL`:

CREATE TABLE tab
(
    d DateTime,
    a Int
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d
TTL d + INTERVAL 1 MONTH DELETE,
    d + INTERVAL 1 WEEK TO VOLUME 'aaa',
    d + INTERVAL 2 WEEK TO DISK 'bbb';

Изменение `TTL` для таблицы:

ALTER TABLE tab
    MODIFY TTL d + INTERVAL 1 DAY;

Создание таблицы, в которой строки автоматически удаляются через один месяц. Просроченные строки с датами, приходящимися на понедельник, удаляются:

CREATE TABLE table_with_where
(
    d DateTime,
    a Int
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d
TTL d + INTERVAL 1 MONTH DELETE WHERE toDayOfWeek(d) = 1;

Создание таблицы, в которой строки с истёкшим сроком хранения повторно сжимаются:

CREATE TABLE table_for_recompression
(
    d DateTime,
    key UInt64,
    value String
) ENGINE MergeTree()
ORDER BY tuple()
PARTITION BY key
TTL d + INTERVAL 1 MONTH RECOMPRESS CODEC(ZSTD(17)), d + INTERVAL 1 YEAR RECOMPRESS CODEC(LZ4HC(10))
SETTINGS min_rows_for_wide_part = 0, min_bytes_for_wide_part = 0;

Создание таблицы, в которой агрегируются просроченные строки. В результате в столбце x содержится максимальное значение по сгруппированным строкам, в y — минимальное значение, а в d — произвольное значение из сгруппированных строк.

CREATE TABLE table_for_aggregation
(
    d DateTime,
    k1 Int,
    k2 Int,
    x Int,
    y Int
)
ENGINE = MergeTree
ORDER BY (k1, k2)
TTL d + INTERVAL 1 MONTH GROUP BY k1, k2 SET x = max(x), y = min(y);

Удаление просроченных данных

Данные с истёкшим TTL удаляются, когда ClickHouse объединяет части данных.

Когда ClickHouse обнаруживает, что данные просрочены, он выполняет внеплановое слияние. Чтобы контролировать частоту таких слияний, вы можете задать merge_with_ttl_timeout. Если значение слишком мало, будет выполняться много внеплановых слияний, которые могут потреблять значительный объём ресурсов.

Если вы выполняете запрос SELECT между слияниями, вы можете получить просроченные данные. Чтобы этого избежать, используйте запрос OPTIMIZE перед SELECT.

См. также

настройка ttl_only_drop_parts

Типы дисков

Помимо локальных блочных устройств, ClickHouse поддерживает следующие типы хранилищ:

Использование нескольких блочных устройств для хранения данных

Введение

Семейство движков таблиц MergeTree может хранить данные на нескольких блочных устройствах. Например, это может быть полезно, когда данные определённой таблицы фактически разделены на «горячие» и «холодные». Самые свежие данные запрашиваются регулярно, но занимают небольшой объём. Напротив, большой «хвост» исторических данных запрашивается редко. Если доступно несколько дисков, «горячие» данные могут располагаться на быстрых дисках (например, NVMe SSD или в памяти), а «холодные» — на относительно медленных (например, HDD).

Часть данных (data part) — минимальная единица, которую можно перемещать, для таблиц на движке MergeTree. Данные, принадлежащие одной части, хранятся на одном диске. Части данных могут перемещаться между дисками в фоновом режиме (в соответствии с пользовательскими настройками), а также с помощью запросов ALTER.

Термины

Диск — блочное устройство, смонтированное к файловой системе.
Диск по умолчанию — диск, на котором расположен путь, указанный в серверной настройке path.
Том — упорядоченный набор одинаковых дисков (аналогично JBOD).
Политика хранения — набор томов и правил перемещения данных между ними.

Названия описанных сущностей можно найти в системных таблицах system.storage_policies и system.disks. Чтобы применить одну из настроенных политик хранения к таблице, используйте настройку storage_policy для таблиц семейства движков MergeTree.

Конфигурация

Диски, тома и политики хранения должны быть объявлены внутри тега <storage_configuration> или в файле в каталоге config.d.

Совет

Диски также могут быть объявлены в секции SETTINGS запроса. Это полезно для разового анализа, когда нужно временно подключить диск, который, например, доступен по URL-адресу. См. раздел dynamic storage для получения дополнительной информации.

Структура конфигурации:

<storage_configuration>
    <disks>
        <disk_name_1> <!-- название диска -->
            <path>/mnt/fast_ssd/clickhouse/</path>
        </disk_name_1>
        <disk_name_2>
            <path>/mnt/hdd1/clickhouse/</path>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </disk_name_2>
        <disk_name_3>
            <path>/mnt/hdd2/clickhouse/</path>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </disk_name_3>

        ...
    </disks>

    ...
</storage_configuration>

Теги:

<disk_name_N> — имя диска. Имена должны быть разными для всех дисков.
path — путь, по которому сервер будет хранить данные (каталоги data и shadow); должен заканчиваться символом '/'.
keep_free_space_bytes — объем свободного дискового пространства, который необходимо зарезервировать.

Порядок определения дисков не имеет значения.

Разметка конфигурации политик хранения:

<storage_configuration>
    ...
    <policies>
        <policy_name_1>
            <volumes>
                <volume_name_1>
                    <disk>disk_name_from_disks_configuration</disk>
                    <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
                    <load_balancing>round_robin</load_balancing>
                </volume_name_1>
                <volume_name_2>
                    <!-- конфигурация -->
                </volume_name_2>
                <!-- другие тома -->
            </volumes>
            <move_factor>0.2</move_factor>
        </policy_name_1>
        <policy_name_2>
            <!-- конфигурация -->
        </policy_name_2>

        <!-- другие политики -->
    </policies>
    ...
</storage_configuration>

Теги:

policy_name_N — Имя политики. Имена политик должны быть уникальными.
volume_name_N — Имя тома. Имена томов должны быть уникальными.
disk — диск внутри тома.
max_data_part_size_bytes — максимальный размер части данных, которая может быть сохранена на любом из дисков тома. Если оценочный размер сливаемой части будет больше, чем max_data_part_size_bytes, то эта часть будет записана на следующий том. По сути эта возможность позволяет держать новые/маленькие части на «горячем» томе (SSD) и перемещать их на «холодный» том (HDD), когда они достигают большого размера. Не используйте этот параметр, если в вашей политике только один том.
move_factor — когда доступное пространство становится меньше этого коэффициента, данные автоматически начинают перемещаться на следующий том, если он есть (по умолчанию 0.1). ClickHouse сортирует существующие части данных по размеру от наибольшей к наименьшей (по убыванию) и выбирает части с суммарным размером, достаточным для выполнения условия move_factor. Если суммарный размер всех частей недостаточен, будут перемещены все части.
perform_ttl_move_on_insert — Отключает перемещение по TTL при INSERT части данных. По умолчанию (если включено), если мы вставляем часть данных, которая уже просрочена по правилу перемещения TTL, она сразу попадает на том/диск, указанный в правиле перемещения. Это может существенно замедлить вставку, если целевой том/диск медленный (например, S3). Если выключено, то уже просроченная часть данных записывается на том по умолчанию, а затем сразу перемещается на том, указанный в правиле TTL.
load_balancing — политика балансировки дисков: round_robin или least_used.
least_used_ttl_ms — настройка таймаута (в миллисекундах) для обновления информации о доступном пространстве на всех дисках (0 — всегда обновлять, -1 — никогда не обновлять, по умолчанию 60000). Обратите внимание: если диск может использоваться только ClickHouse и не подвержен онлайн-изменению размера файловой системы (расширению/сжатию), вы можете использовать -1; во всех остальных случаях это не рекомендуется, так как в итоге это приведёт к некорректному распределению пространства.
prefer_not_to_merge — Не следует использовать этот параметр. Отключает слияние частей данных на этом томе (это вредно и приводит к деградации производительности). При включённом параметре (не делайте этого) слияние данных на этом томе не допускается (что плохо). Это позволяет (но вам это не нужно) управлять (если вы хотите что‑то контролировать, вы совершаете ошибку) тем, как ClickHouse работает с медленными дисками (но ClickHouse знает лучше, поэтому, пожалуйста, не используйте этот параметр).
volume_priority — Определяет приоритет (порядок), в котором заполняются тома. Меньшее значение означает более высокий приоритет. Значения параметра должны быть натуральными числами и совместно покрывать диапазон от 1 до N (для самого низкого приоритета) без пропусков.
- Если все тома помечены, они получают приоритет в указанном порядке.
- Если помечены только некоторые тома, те, у которых нет метки, имеют самый низкий приоритет и получают приоритет в порядке, в котором они определены в конфигурации.
- Если ни один том не помечен, их приоритет задаётся в соответствии с порядком, в котором они объявлены в конфигурации.
- Два тома не могут иметь одинаковое значение приоритета.

Примеры конфигурации:

<storage_configuration>
    ...
    <policies>
        <hdd_in_order> <!-- имя политики -->
            <volumes>
                <single> <!-- имя тома -->
                    <disk>disk1</disk>
                    <disk>disk2</disk>
                </single>
            </volumes>
        </hdd_in_order>

        <moving_from_ssd_to_hdd>
            <volumes>
                <hot>
                    <disk>fast_ssd</disk>
                    <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
                </hot>
                <cold>
                    <disk>disk1</disk>
                </cold>
            </volumes>
            <move_factor>0.2</move_factor>
        </moving_from_ssd_to_hdd>

        <small_jbod_with_external_no_merges>
            <volumes>
                <main>
                    <disk>jbod1</disk>
                </main>
                <external>
                    <disk>external</disk>
                </external>
            </volumes>
        </small_jbod_with_external_no_merges>
    </policies>
    ...
</storage_configuration>

В приведённом примере политика hdd_in_order реализует стратегию round-robin. Поэтому эта политика определяет только один том (single), а части данных хранятся на всех его дисках по кругу. Такая политика может быть весьма полезна, если в системе подключено несколько однотипных дисков, но RAID не настроен. Имейте в виду, что каждый отдельный диск ненадёжен, и может потребоваться компенсировать это фактором репликации 3 или более.

Если в системе доступны разные типы дисков, вместо этого можно использовать политику moving_from_ssd_to_hdd. Том hot состоит из SSD-диска (fast_ssd), и максимальный размер части, которая может храниться на этом томе, составляет 1 ГБ. Все части размером более 1 ГБ будут храниться непосредственно на томе cold, который содержит HDD-диск disk1. Кроме того, как только диск fast_ssd будет заполнен более чем на 80%, данные будут перенесены на disk1 фоновым процессом.

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

При создании таблицы к ней можно применить одну из настроенных политик хранения:

CREATE TABLE table_with_non_default_policy (
    EventDate Date,
    OrderID UInt64,
    BannerID UInt64,
    SearchPhrase String
) ENGINE = MergeTree
ORDER BY (OrderID, BannerID)
PARTITION BY toYYYYMM(EventDate)
SETTINGS storage_policy = 'moving_from_ssd_to_hdd'

Политика хранения default подразумевает использование только одного тома, который включает один диск, заданный в <path>. Вы можете изменить политику хранения после создания таблицы с помощью запроса [ALTER TABLE ... MODIFY SETTING]; при этом новая политика должна включать все старые диски и тома с теми же именами.

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

Подробности

В случае таблиц MergeTree данные попадают на диск разными способами:

В результате вставки (запрос INSERT).
Во время фоновых слияний и мутаций.
При загрузке с другой реплики.
В результате заморозки партиции ALTER TABLE ... FREEZE PARTITION.

Во всех этих случаях, за исключением мутаций и заморозки партиций, часть данных сохраняется на томе и диске в соответствии с заданной политикой хранения:

Выбирается первый том (в порядке объявления), у которого достаточно свободного дискового пространства для хранения части (unreserved_space > current_part_size) и который допускает хранение частей заданного размера (max_data_part_size_bytes > current_part_size).
Внутри этого тома выбирается тот диск, который следует за диском, использованным для хранения предыдущей части данных, и у которого свободное пространство больше размера части (unreserved_space - keep_free_space_bytes > current_part_size).

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

В фоновом режиме части перемещаются между томами на основе количества свободного места (параметр move_factor) в соответствии с порядком, в котором тома объявлены в конфигурационном файле. Данные никогда не переносятся ни с последнего тома, ни на первый том. Для мониторинга фоновых перемещений можно использовать системные таблицы system.part_log (поле type = MOVE_PART) и system.parts (поля path и disk). Также подробная информация может быть найдена в логах сервера.

Пользователь может принудительно переместить часть или партицию с одного тома на другой с помощью запроса ALTER TABLE ... MOVE PART|PARTITION ... TO VOLUME|DISK ...; при этом учитываются все ограничения для фоновых операций. Запрос самостоятельно инициирует перемещение и не ждёт завершения фоновых операций. Пользователь получит сообщение об ошибке, если недостаточно свободного места или не выполнено какое-либо из требуемых условий.

Перемещение данных не мешает репликации данных. Поэтому для одной и той же таблицы на разных репликах могут быть заданы разные политики хранения.

После завершения фоновых слияний и мутаций старые части удаляются только спустя определённый промежуток времени (old_parts_lifetime). В течение этого времени они не перемещаются на другие тома или диски. Поэтому до окончательного удаления части по-прежнему учитываются при оценке занятого дискового пространства.

Пользователь может более равномерно распределять новые большие части по разным дискам тома JBOD с помощью настройки min_bytes_to_rebalance_partition_over_jbod.

Использование внешнего хранилища для хранения данных

Движки таблиц семейства MergeTree могут хранить данные в S3, AzureBlobStorage, HDFS, используя диск с типом s3, azure_blob_storage, hdfs соответственно. Для получения дополнительной информации см. раздел настройка параметров внешнего хранилища.

Пример использования S3 в качестве внешнего хранилища с диском типа s3.

Фрагмент конфигурации:

<storage_configuration>
    ...
    <disks>
        <s3>
            <type>s3</type>
            <support_batch_delete>true</support_batch_delete>
            <endpoint>https://clickhouse-public-datasets.s3.amazonaws.com/my-bucket/root-path/</endpoint>
            <access_key_id>your_access_key_id</access_key_id>
            <secret_access_key>your_secret_access_key</secret_access_key>
            <region></region>
            <header>Authorization: Bearer SOME-TOKEN</header>
            <server_side_encryption_customer_key_base64>your_base64_encoded_customer_key</server_side_encryption_customer_key_base64>
            <server_side_encryption_kms_key_id>your_kms_key_id</server_side_encryption_kms_key_id>
            <server_side_encryption_kms_encryption_context>your_kms_encryption_context</server_side_encryption_kms_encryption_context>
            <server_side_encryption_kms_bucket_key_enabled>true</server_side_encryption_kms_bucket_key_enabled>
            <proxy>
                <uri>http://proxy1</uri>
                <uri>http://proxy2</uri>
            </proxy>
            <connect_timeout_ms>10000</connect_timeout_ms>
            <request_timeout_ms>5000</request_timeout_ms>
            <retry_attempts>10</retry_attempts>
            <single_read_retries>4</single_read_retries>
            <min_bytes_for_seek>1000</min_bytes_for_seek>
            <metadata_path>/var/lib/clickhouse/disks/s3/</metadata_path>
            <skip_access_check>false</skip_access_check>
        </s3>
        <s3_cache>
            <type>cache</type>
            <disk>s3</disk>
            <path>/var/lib/clickhouse/disks/s3_cache/</path>
            <max_size>10Gi</max_size>
        </s3_cache>
    </disks>
    ...
</storage_configuration>

См. также настройку вариантов внешних хранилищ.

конфигурация кэша

Версии ClickHouse с 22.3 по 22.7 используют другую конфигурацию кэша, см. использование локального кэша, если вы используете одну из этих версий.

Виртуальные столбцы

_part — Имя парта.
_part_index — Последовательный индекс парта в результате запроса.
_part_starting_offset — Кумулятивный номер первой строки парта в результате запроса.
_part_offset — Номер строки в парте.
_part_granule_offset — Номер гранулы в парте.
_partition_id — Имя партиции.
_part_uuid — Уникальный идентификатор парта (если включена настройка MergeTree assign_part_uuids).
_part_data_version — Версия данных парта (либо минимальный номер блока, либо версия мутации).
_partition_value — Значения (кортеж) выражения PARTITION BY.
_sample_factor — Коэффициент выборки (из запроса).
_block_number — Исходный номер блока для строки, который был присвоен при вставке; сохраняется при слияниях, когда включена настройка enable_block_number_column.
_block_offset — Исходный номер строки в блоке, который был присвоен при вставке; сохраняется при слияниях, когда включена настройка enable_block_offset_column.
_disk_name — Имя диска, используемого для хранения.

Статистика по столбцам

Experimental feature. Learn more.

Not supported in ClickHouse Cloud

Объявление статистики задаётся в секции COLUMNS запроса CREATE для таблиц из семейства *MergeTree* при включённой настройке set allow_experimental_statistics = 1.

CREATE TABLE tab
(
    a Int64 STATISTICS(TDigest, Uniq),
    b Float64
)
ENGINE = MergeTree
ORDER BY a

Мы также можем изменять статистику с помощью операторов ALTER.

ALTER TABLE tab ADD STATISTICS b TYPE TDigest, Uniq;
ALTER TABLE tab DROP STATISTICS a;

Эта легковесная статистика агрегирует информацию о распределении значений в столбцах. Статистика хранится в каждой части и обновляется при каждой вставке. Её можно использовать для оптимизации PREWHERE только при включённом параметре set allow_statistics_optimize = 1.

Доступные типы статистики по столбцам

MinMax

Минимальное и максимальное значения столбца, что позволяет оценивать селективность диапазонных фильтров по числовым столбцам.

Синтаксис: minmax
TDigest

Скетчи TDigest, которые позволяют вычислять приблизительные перцентили (например, 90-й перцентиль) для числовых столбцов.

Синтаксис: tdigest
Uniq

Скетчи HyperLogLog, которые позволяют оценить, сколько различных значений содержит столбец.

Синтаксис: uniq
CountMin

Скетчи CountMin, которые предоставляют приблизительный подсчёт частоты каждого значения в столбце.

Синтаксис: countmin

Поддерживаемые типы данных

	(U)Int, Float, Decimal(), Date, Boolean, Enum*	String или FixedString
CountMin	✔	✔
MinMax	✔	✗
TDigest	✔	✗
Uniq	✔	✔

Поддерживаемые операции

	Фильтры равенства (==)	Фильтры по диапазону (`>, >=, <, <=`)
CountMin	✔	✗
MinMax	✗	✔
TDigest	✗	✔
Uniq	✔	✗

Параметры на уровне столбцов

Некоторые настройки MergeTree можно переопределять на уровне столбцов:

max_compress_block_size — максимальный размер блоков несжатых данных перед их сжатием при записи в таблицу.
min_compress_block_size — минимальный размер блоков несжатых данных, необходимый для сжатия при записи следующей метки.

Пример:

CREATE TABLE tab
(
    id Int64,
    document String SETTINGS (min_compress_block_size = 16777216, max_compress_block_size = 16777216)
)
ENGINE = MergeTree
ORDER BY id

Настройки для отдельных столбцов можно изменять или удалять с помощью ALTER MODIFY COLUMN, например:

Удалить SETTINGS из определения столбца:

ALTER TABLE tab MODIFY COLUMN document REMOVE SETTINGS;

Измените параметр:

ALTER TABLE tab MODIFY COLUMN document MODIFY SETTING min_compress_block_size = 8192;

Сбрасывает одну или несколько настроек, а также удаляет объявление настройки в определении столбца в запросе CREATE для таблицы.

ALTER TABLE tab MODIFY COLUMN document RESET SETTING min_compress_block_size;

Создание таблиц​

Части запроса​

ENGINE​

ORDER BY​

PARTITION BY​

PRIMARY KEY​

SAMPLE BY​

TTL​

ПАРАМЕТРЫ​

Хранение данных​

Первичные ключи и индексы в запросах​

Выбор первичного ключа​

Выбор первичного ключа, отличного от ключа сортировки​

Использование индексов и партиций в запросах​

Использование индекса для частично-монотонных первичных ключей​

Индексы пропуска данных​

Типы пропускающих индексов​

Индекс MinMax​

Set​

Фильтр Блума​

N-граммовый Bloom-фильтр​

Фильтр Блума по токенам​

Разрежённый n-граммный фильтр Блума​

Текстовый индекс​

Сходство векторов​

Поддержка функций​

Проекции​

Запрос проекции​

Хранение проекций​

Анализ запросов​

Одновременный доступ к данным​

TTL для столбцов и таблиц​

TTL столбца​

Создание таблицы с параметром TTL:​

Добавление TTL для столбца существующей таблицы​

Изменение TTL для столбца​

TTL таблицы​

Создание таблицы с TTL:​

Изменение TTL для таблицы:​

Создание таблицы, в которой строки с истёкшим сроком хранения повторно сжимаются:​

Удаление просроченных данных​

Типы дисков​

Использование нескольких блочных устройств для хранения данных​

Введение​

Термины​

Конфигурация​

Подробности​

Использование внешнего хранилища для хранения данных​

Виртуальные столбцы​

Статистика по столбцам​

Доступные типы статистики по столбцам​

Поддерживаемые типы данных​

Поддерживаемые операции​

Параметры на уровне столбцов​

Создание таблиц

Части запроса

ENGINE

ORDER BY

PARTITION BY

PRIMARY KEY

SAMPLE BY

TTL

ПАРАМЕТРЫ

Хранение данных

Первичные ключи и индексы в запросах

Выбор первичного ключа

Выбор первичного ключа, отличного от ключа сортировки

Использование индексов и партиций в запросах

Использование индекса для частично-монотонных первичных ключей

Индексы пропуска данных

Типы пропускающих индексов

Индекс MinMax

Set

Фильтр Блума

N-граммовый Bloom-фильтр

Фильтр Блума по токенам

Разрежённый n-граммный фильтр Блума

Текстовый индекс

Сходство векторов

Поддержка функций

Проекции

Запрос проекции

Хранение проекций

Анализ запросов

Одновременный доступ к данным

TTL для столбцов и таблиц

TTL столбца

Создание таблицы с параметром `TTL`:

Добавление TTL для столбца существующей таблицы

Изменение TTL для столбца

TTL таблицы

Создание таблицы с `TTL`:

Изменение `TTL` для таблицы:

Создание таблицы, в которой строки с истёкшим сроком хранения повторно сжимаются:

Удаление просроченных данных

Типы дисков

Использование нескольких блочных устройств для хранения данных

Введение

Термины

Конфигурация

Подробности

Использование внешнего хранилища для хранения данных

Виртуальные столбцы

Статистика по столбцам

Доступные типы статистики по столбцам

Поддерживаемые типы данных

Поддерживаемые операции

Параметры на уровне столбцов