Comprendre les index de saut de données dans ClickHouse

• Nom de l’index. Le nom de l’index est utilisé pour créer le fichier d’index dans chaque partition. Il est également requis comme paramètre lors de la suppression ou de la matérialisation de l’index.
• Expression de l’index. L’expression de l’index sert à calculer l’ensemble des valeurs stockées dans l’index. Elle peut être une combinaison de colonnes, d’opérateurs simples et/ou d’un sous-ensemble de fonctions déterminé par le type d’index.
• TYPE. Le type d’index contrôle le calcul qui détermine s’il est possible d’éviter la lecture et l’évaluation de chaque bloc d’index.
• GRANULARITY. Chaque bloc indexé est constitué de GRANULARITY granules. Par exemple, si la granularité de l’index principal de la table est de 8192 lignes et que la granularité de l’index est de 4, chaque “bloc” indexé comptera 32768 lignes.

• skp_idx_{index_name}.idx, qui contient les valeurs ordonnées de l’expression
• skp_idx_{index_name}.mrk2, qui contient les offsets correspondants dans les fichiers de colonnes de données associés.

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.

• Le bloom_filter de base, qui prend un seul paramètre facultatif correspondant au taux de « faux positifs » autorisé entre 0 et 1 (si non spécifié, .025 est utilisé).
• Le tokenbf_v1 spécialisé (Obsolète)). Il prend trois paramètres, tous liés au réglage du filtre de Bloom utilisé : (1) la taille du filtre en octets (des filtres plus grands produisent moins de faux positifs, au prix d’un surcoût de stockage), (2) le nombre de fonctions de hachage appliquées (là encore, un plus grand nombre de fonctions de hachage réduit les faux positifs), et (3) la seed des fonctions de hachage du filtre de Bloom. Consultez le calculateur ici pour plus de détails sur l’effet de ces paramètres sur le fonctionnement du filtre de Bloom. Cet index fonctionne uniquement avec les types de données String, FixedString et Map. L’expression d’entrée est découpée en séquences de caractères séparées par des caractères non alphanumériques. Par exemple, une valeur de column This is a candidate for a \"full text\" search contiendra les tokens This is a candidate for full text search. Il est destiné à être utilisé avec des recherches LIKE, EQUALS, IN, hasToken() et d’autres recherches similaires portant sur des mots et d’autres valeurs au sein de chaînes plus longues. Par exemple, un cas d’usage possible serait la recherche d’un petit nombre de noms de classe ou de numéros de ligne dans une column de lignes de logs applicatifs en texte libre.
• Le ngrambf_v1 spécialisé (Obsolète). Cet index fonctionne de la même manière que l’index de tokens. Il prend un paramètre supplémentaire avant les réglages du filtre de Bloom : la taille des ngrams à indexer. Un ngram est une chaîne de caractères de longueur n composée de caractères quelconques, de sorte que la chaîne A short string avec une taille de ngram de 4 serait indexée comme suit :
  'A sh', ' sho', 'shor', 'hort', 'ort ', 'rt s', 't st', ' str', 'stri', 'trin', 'ring'
  

Pour les workloads de recherche en texte intégral, le index de texte dédié (voir Text index for full-text search) est recommandé à la place des index obsolètes tokenbf_v1 ou ngrambf_v1. Le index de texte fournit un véritable index inversé avec de meilleures performances de recherche, un comportement plus prévisible, ainsi qu’une plus grande souplesse et de meilleures performances que les index de filtre de Bloom basés sur des tokens.

• des données sont insérées et l’index est défini comme une expression fonctionnelle (le résultat de l’expression étant stocké dans les fichiers d’index), ou
• la requête est traitée et l’expression est appliquée aux valeurs d’index stockées afin de déterminer s’il faut exclure le block.

• use_skip_indexes (0 ou 1, 1 par défaut). Toutes les requêtes ne peuvent pas utiliser efficacement les index de saut. Si une condition de filtrage donnée est susceptible d’inclure la plupart des granules, l’utilisation de l’index de data skipping entraîne un coût inutile, parfois important. Définissez cette valeur sur 0 pour les requêtes qui ne bénéficieront probablement d’aucun index de saut.
• force_data_skipping_indices (liste de noms d’index séparés par des virgules). Ce paramètre peut être utilisé pour empêcher certains types de requêtes inefficaces. Lorsqu’une requête sur une table est trop coûteuse sans index de saut, l’utilisation de ce paramètre avec un ou plusieurs noms d’index renverra une exception pour toute requête qui n’utilise pas les index indiqués. Cela évite que des requêtes mal écrites ne consomment les ressources du serveur.

SELECT timestamp, url FROM table WHERE visitor_id = 1001`

• Guide des bonnes pratiques
• Exemples d’index de saut de données
• Manipulation des index de saut de données
• Informations sur la table système