Description
Contient une ligne par entrée actuellement stockée dans le cache des colonnes désérialisées. Ce cache conserve en mémoire les colonnes déjà lues et désérialisées des partsMergeTree, de sorte que les lectures répétées d’une même plage de lignes n’ont pas à payer une nouvelle fois le coût de la décompression et de la désérialisation.
Chaque entrée correspond à une plage contiguë de granules [row_begin, row_end) d’une seule colonne d’une seule part, au sein d’un stripe fixe d’environ 65536 lignes de cette part. Les lectures sont servies depuis le cache granule par granule, et les stripes sont identiques pour toutes les lectures de la part ; les entrées ne dépendent donc pas de la manière dont une requête découpe la part en plages de marques : une lecture qui ne touche que certains granules d’un stripe met uniquement ceux-ci en cache, et les plages adjacentes écrites par des lectures différentes sont fusionnées.
Le cache identifie les entrées par l’UUID de la table ; il n’est donc actif que pour les tables appartenant à des bases de données qui attribuent des UUID, telles que Atomic, Replicated et Shared (le moteur de base de données par défaut dans ClickHouse Cloud). Les tables des anciennes bases de données Ordinary n’ont pas d’UUID et sont exclues du cache sans avertissement. Seules les wide parts sont prises en charge par le cache ; les parts compact en sont exclues sans avertissement.
Le cache est contrôlé par les paramètres serveur columns_cache_size (par défaut, columns_cache_size_to_ram_ratio de la mémoire disponible pour le serveur) et columns_cache_size_ratio, ainsi que par les paramètres de niveau requête use_columns_cache, enable_reads_from_columns_cache, enable_writes_to_columns_cache, columns_cache_max_estimated_bytes_to_write_to_cache et columns_cache_max_bytes_to_write_to_cache. Il peut être vidé manuellement avec SYSTEM DROP COLUMNS CACHE.
Les lignes sont filtrées selon les droits d’accès : une entrée n’est visible que par un utilisateur autorisé à voir à la fois sa table et sa colonne, c’est-à-dire disposant de SHOW TABLES sur la table et de SHOW COLUMNS sur la colonne. Un octroi de SHOW COLUMNS sur *.* ne prévaut pas sur une révocation portant sur une table ou une colonne particulière, car cette table expose des données opérationnelles (noms des parts, plages de lignes et tailles en cache), et pas uniquement le schéma. Les entrées d’une table qui n’existe plus ne comportent aucun nom à vérifier ; elles ne sont donc visibles que par un utilisateur disposant de SHOW COLUMNS au niveau global.
Colonnes
database(String) — Nom de la base de données de la table à laquelle appartient la part.table(String) — Nom de la table.table_uuid(UUID) — UUID de la table. Reste inchangé en cas de renommage.part(String) — Nom de la part.column(String) — Nom de la colonne.row_begin(UInt64) — Index de la première ligne de la plage mise en cache (inclus).row_end(UInt64) — Index de fin de la plage mise en cache (exclu).rows(UInt64) — Nombre de lignes dans la plage mise en cache (row_end - row_begin).bytes(UInt64) — Mémoire occupée par l’entrée, en octets : taille allouée de la colonne mise en cache, plus un léger surcoût par entrée. C’est sur cette quantité que s’applique la limite du cache : la somme de cette colonne sur l’ensemble des entrées ne dépasse donc pascolumns_cache_size. Cette valeur peut être supérieure à la taille logique des lignes, car une colonne conserve la capacité qui lui a été allouée.
Exemples
Mémoire totale utilisée par les colonnes mises en cache, par table :Voir aussi
- SYSTEM DROP COLUMNS CACHE — Le statement qui supprime toutes les entrées du cache des colonnes.