Vue d’ensemble des projections
- Exécuter des requêtes sur une colonne qui ne fait pas partie de la clé primaire
- Pré-agréger des colonnes afin de réduire à la fois les calculs et les IO
Utilisation du disqueLes projections créent en interne une nouvelle table cachée, ce qui signifie que davantage d’IO et d’espace disque seront nécessaires.
Par exemple, si la projection définit une clé primaire différente, toutes les données de la table d’origine seront dupliquées.
Utilisation des projections
Exemple de filtrage sans utiliser de clés primaires
ALTER TABLE, on peut ajouter la projection à une table existante :
user_name, même si, dans la table d’origine, user_name n’a pas été défini comme PRIMARY_KEY.
Au moment de l’exécution de la requête, ClickHouse détermine que moins de données seront traitées si la projection est utilisée, puisque les données sont ordonnées par user_name.
system.query_log. Dans le champ projections, nous trouvons le nom de la projection utilisée, ou rien si aucune n’a été utilisée :
Exemple de requête de pré-agrégation
projection_visits_by_user :
GROUP BY sur le champ user_agent.
Cette requête n’utilisera pas la projection définie, car la pré-agrégation ne correspond pas.
GROUP BY :
system.query_log pour vérifier si une projection a été utilisée.
Le champ projections indique le nom de la projection utilisée.
Il sera vide si aucune projection n’a été utilisée :
Création et utilisation d’index de projection
_part_offset conserve sa valeur après les fusions et les mutations, ce qui le rend utile pour l’indexation secondaire. On peut en tirer parti dans les requêtes :
Gestion des projections
ADD PROJECTION
Clause WITH SETTINGS
WITH SETTINGS définit des paramètres de projection qui personnalisent la façon dont la projection stocke les données (par exemple, index_granularity ou index_granularity_bytes).
Ils correspondent directement aux paramètres de table MergeTree, mais s’appliquent uniquement à cette projection.
Exemple :
DROP PROJECTION
MATERIALIZE PROJECTION
name dans la partition partition_name.
Cette opération est implémentée sous forme de mutation.
CLEAR PROJECTION
ADD, DROP et CLEAR sont légères, au sens où elles ne font que modifier les métadonnées ou supprimer des fichiers.
De plus, elles sont répliquées et synchronisent les métadonnées des projections via ClickHouse Keeper ou ZooKeeper.
La manipulation des projections n’est prise en charge que pour les tables utilisant le moteur
*MergeTree (y compris les variantes répliquées).Contrôler le comportement de fusion des projections
ReplacingMergeTree.
Si la même row est détectée dans plusieurs parts d’entrée lors de la fusion, seule la version la plus récente de la ligne (issue de la part insérée le plus récemment) est conservée, tandis que toutes les versions plus anciennes sont supprimées.
De même, si la table utilise le table engine AggregatingMergeTree, l’opération de fusion peut regrouper des rows identiques dans les parts d’entrée (sur la base des primary key values) en une seule row afin de mettre à jour les partial aggregation states.
Avant ClickHouse v24.8, les parties de projection se désynchronisaient silencieusement des données principales, ou bien certaines opérations comme les mises à jour et les suppressions ne pouvaient pas être exécutées du tout, car la database levait automatiquement une exception si la table avait des projections.
Depuis la v24.8, un nouveau paramètre au niveau de la table deduplicate_merge_projection_mode contrôle le comportement lorsque les background merge operations non triviales mentionnées ci-dessus se produisent dans les parts de la table d’origine.
Les delete mutations sont un autre exemple de part merge operations qui suppriment des rows dans les parts de la table d’origine. Depuis la v24.7, nous disposons également d’un paramètre pour contrôler le comportement vis-à-vis des delete mutations déclenchées par les lightweight deletes : lightweight_mutation_projection_mode.
Voici les valeurs possibles pour deduplicate_merge_projection_mode et lightweight_mutation_projection_mode :
throw(par défaut) : une exception est levée, ce qui empêche les parties de projection de se désynchroniser.drop: les parties de projection affectées sont supprimées. Les requêtes reviennent alors à la part de la table d’origine pour les projections affectées.rebuild: la partie de projection affectée est reconstruite afin de rester cohérente avec les données de la part de la table d’origine.
Limites
ALIAS dans la clause ORDER BY d’une projection. Par exemple :
ALIAS ne sont pas stockées physiquement et sont calculées à la volée à l’exécution de la requête. Elles ne sont donc pas disponibles lors de l’écriture de la partie de projection, au moment où l’expression de tri est évaluée.
Utilisez plutôt des colonnes MATERIALIZED ou intégrez directement l’expression :