Analyse en temps réelEntreposage de donnéesObservabilitéIA/MLCloudOss
Prérequis
- A running ClickHouse Cloud service. If you don’t have one yet, complete the Create your first Cloud service quickstart first.
uk_price_paid qui y est créée.
Ce que vous allez créer
uk_price_paid par town ou county nécessite un balayage complet de la table, car celle-ci est triée par (postcode, addr1, addr2).
Dans ce guide de démarrage rapide, vous allez résoudre ce problème en créant une vue matérialisée qui stocke les mêmes données triées par (town, date), ce qui permet des recherches rapides par ville sans modifier la table d’origine.
À la fin, vous comprendrez comment les vues matérialisées fonctionnent comme des déclencheurs à l’insertion, comment réinjecter les données existantes, ainsi que le compromis en espace disque qu’implique le stockage des données en double.
1
Comprendre pourquoi vous avez besoin d’une vue matérialisée
Votre tableuk_price_paid est triée selon (postcode, addr1, addr2). Cela signifie que ClickHouse peut ignorer de grands blocs de données lorsque vous filtrez sur postcode, addr1 ou addr2, mais les requêtes qui filtrent sur town doivent parcourir chaque ligne — les 30 millions.Vous pourriez créer une deuxième table avec un ORDER BY différent, mais il faudrait alors penser à insérer les nouvelles données dans les deux tables à chaque arrivée. Une vue matérialisée automatise cela : elle surveille les insertions dans une table source, transforme les lignes, puis les écrit automatiquement dans une table de destination.Considérez une vue matérialisée comme un déclencheur d’insertion : chaque fois que des lignes sont insérées dans la table source, la requête SELECT de la MV s’exécute sur le nouveau bloc de lignes, puis le résultat est inséré dans la table de destination.2
Créer la table de destination
Une vue matérialisée a besoin d’un emplacement où stocker sa sortie. Il s’agit simplement d’une table MergeTree standard : vous avez un contrôle total sur son schéma,ORDER BY et PARTITION BY.Créez une table triée par (town, date) avec uniquement les colonnes nécessaires aux requêtes par ville :3
Créer la vue matérialisée
Créez maintenant la vue matérialisée qui relie la table source (uk_price_paid) à la table de destination (uk_price_paid_by_town) :TO uk_price_paid_by_town indique à ClickHouse d’écrire le résultat du SELECT dans votre table de destination. Désormais, chaque fois que des lignes sont insérées dans uk_price_paid, cette vue matérialisée se déclenche et insère les lignes transformées dans uk_price_paid_by_town.Attention toutefois : les vues matérialisées ne se déclenchent que lors des insertions. Si vous supprimez ou mettez à jour des lignes dans la table source, la table de destination n’en est pas informée - les vues matérialisées ne restent pas synchronisées avec les suppressions ou les mises à jour. Si vous avez besoin de ce type de synchronisation, envisagez plutôt d’utiliser des projections.4
Charger les données historiques
La vue matérialisée ne traite que les insertions futures. Les 30 millions de lignes déjà présentes dansuk_price_paid ont été insérées avant que la vue matérialisée n’existe, la table de destination est donc actuellement vide.Chargez-les manuellement :5
Interroger la table de destination de la vue matérialisée
Exécutez maintenant une requête avec un filtre surtown dans la table de destination, puis comparez le résultat à celui obtenu en interrogeant directement la table source.Commencez par interroger la table source :town ne figure pas dans l’ORDER BY de la table source.Exécutez maintenant la même requête sur la table de destination de la vue matérialisée :(town, date) et ClickHouse peut ignorer toutes les données qui ne correspondent pas à LONDON.Exécutez SHOW TABLES pour voir ce qui a été créé :uk_price_paid_by_town (la table de destination) et uk_price_paid_by_town_mv (la vue). Comme vous avez utilisé CREATE MATERIALIZED VIEW ... TO, vous maîtrisez le nom de la table de destination. Si vous omettez la clause TO, ClickHouse crée une table de destination au nom implicite (.inner.xxx), avec laquelle il est plus difficile de travailler directement.
Il est donc recommandé de créer des vues matérialisées avec la clause TO.6
Observez que les données sont stockées en double
Les vues matérialisées offrent des lectures plus rapides, au prix d’un espace disque supplémentaire. Interrogezsystem.parts pour voir combien d’espace chaque table utilise :uk_price_paid, triées selon (postcode, addr1, addr2), et une fois dans uk_price_paid_by_town, triées selon (town, date). C’est le compromis fondamental : vous utilisez davantage d’espace disque en contrepartie de lectures plus rapides selon différents modes d’accès.La table de destination peut occuper moins d’espace sur disque, car elle contient moins de colonnes et l’ordre de tri (town, date) peut se compresser différemment de celui d’origine.