Что такое индексы пропуска данных в ClickHouse

• Имя индекса. Имя индекса используется для создания файла индекса в каждой партиции. Оно также требуется как параметр при удалении или материализации индекса.
• Выражение индекса. Выражение индекса используется для вычисления набора значений, хранящихся в индексе. Это может быть комбинация столбцов, простых операторов и/или подмножества функций, определяемого типом индекса.
• TYPE. Тип индекса определяет вычисление, по результатам которого решается, можно ли пропустить чтение и обработку каждого блока индекса.
• GRANULARITY. Каждый индексируемый блок состоит из GRANULARITY гранул. Например, если гранулярность первичного индекса таблицы составляет 8192 строки, а гранулярность индекса — 4, то каждый индексируемый “блок” будет содержать 32768 строк.

• skp_idx_{index_name}.idx, который содержит упорядоченные значения выражения
• skp_idx_{index_name}.mrk2, который содержит соответствующие смещения в связанных файлах столбцов.

CREATE TABLE skip_table
(
  my_key UInt64,
  my_value UInt64
)
ENGINE MergeTree primary key my_key
SETTINGS index_granularity=8192;

INSERT INTO skip_table SELECT number, intDiv(number,4096) FROM numbers(100000000);

SELECT * FROM skip_table WHERE my_value IN (125, 700)

┌─my_key─┬─my_value─┐
│ 512000 │      125 │
│ 512001 │      125 │
│    ... |      ... |
└────────┴──────────┘

8192 rows in set. Elapsed: 0.079 sec. Processed 100.00 million rows, 800.10 MB (1.26 billion rows/s., 10.10 GB/s.

ALTER TABLE skip_table ADD INDEX vix my_value TYPE set(100) GRANULARITY 2;

ALTER TABLE skip_table MATERIALIZE INDEX vix;

SELECT * FROM skip_table WHERE my_value IN (125, 700)

┌─my_key─┬─my_value─┐
│ 512000 │      125 │
│ 512001 │      125 │
│    ... |      ... |
└────────┴──────────┘

8192 rows in set. Elapsed: 0.051 sec. Processed 32.77 thousand rows, 360.45 KB (643.75 thousand rows/s., 7.08 MB/s.)

SET send_logs_level='trace';

<Debug> default.skip_table (933d4b2c-8cea-4bf9-8c93-c56e900eefd1) (SelectExecutor): Index `vix` has dropped 6102/6104 granules.

• Базовый bloom_filter, который принимает один необязательный параметр — допустимую вероятность ложноположительных срабатываний в диапазоне от 0 до 1 (если параметр не указан, используется .025).
• Специализированный tokenbf_v1 (Устарело)). Он принимает три параметра, все они относятся к настройке используемого bloom-фильтра: (1) размер фильтра в байтах (чем больше фильтр, тем меньше ложноположительных срабатываний, но тем больше затраты на хранение), (2) количество применяемых хеш-функций (чем их больше, тем ниже вероятность ложноположительных срабатываний) и (3) seed для хеш-функций bloom-фильтра. Подробнее о том, как эти параметры влияют на работу bloom-фильтра, см. в калькуляторе здесь. Этот индекс работает только с типами данных String, FixedString и Map. Входное выражение разбивается на последовательности символов, разделённые неалфавитно-цифровыми символами. Например, значение столбца This is a candidate for a \"full text\" search будет содержать токены This is a candidate for full text search. Он предназначен для использования в LIKE, EQUALS, IN, hasToken() и аналогичных поисковых запросах по словам и другим значениям внутри более длинных строк. Например, его можно использовать для поиска небольшого числа имён классов или номеров строк в столбце с произвольными строками журналов приложения.
• Специализированный ngrambf_v1 (Устарело). Этот индекс работает так же, как token-индекс. Он принимает ещё один параметр перед настройками bloom-фильтра — размер n-грамм для индексации. N-грамма — это строка длиной n из любых символов, поэтому строка A short string при размере n-граммы 4 будет индексироваться как:
  'A sh', ' sho', 'shor', 'hort', 'ort ', 'rt s', 't st', ' str', 'stri', 'trin', 'ring'
  

Для рабочих нагрузок полнотекстового поиска рекомендуется использовать специализированный текстовый индекс (см. Text index for full-text search) вместо устаревших индексов tokenbf_v1 или ngrambf_v1. Текстовый индекс предоставляет полноценный инвертированный индекс с более высокой производительностью поиска, более предсказуемым поведением, а также большей гибкостью и производительностью по сравнению с индексами bloom-фильтра на основе токенов.

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

• use_skip_indexes (0 или 1, по умолчанию 1). Не все запросы могут эффективно использовать индексы пропуска данных. Если определённое условие фильтрации, скорее всего, охватывает большинство гранул, применение индекса пропуска данных влечёт за собой лишние, а иногда и существенные, затраты. Установите значение 0 для запросов, которым индексы пропуска данных, скорее всего, не дадут выигрыша.
• force_data_skipping_indices (список имён индексов, разделённых запятыми). Эту настройку можно использовать, чтобы предотвратить некоторые виды неэффективных запросов. Если запрос к таблице становится слишком затратным без использования индекса пропуска данных, то при использовании этой настройки с одним или несколькими именами индексов для любого запроса, который не использует указанный индекс, будет возвращено исключение. Это не позволит неудачно написанным запросам расходовать ресурсы сервера.

SELECT timestamp, url FROM table WHERE visitor_id = 1001`

• Руководство по лучшим практикам
• Примеры индексов пропуска данных
• Управление индексами пропуска данных
• Информация о системной таблице