Ce tutoriel vous montre comment maintenir à jour des rollups pré-agrégés à partir d’une table d’événements à fort volume à l’aide de vues matérialisées. Vous créerez trois objets : une table d’événements bruts, une table de rollup et la vue matérialisée qui alimente automatiquement le rollup.
Quand utiliser ce modèle
- Vous avez un flux d’événements uniquement en ajout (clics, vues de page, IoT, logs).
- La plupart des requêtes sont des agrégations sur des intervalles de temps (par minute/heure/jour).
- Vous voulez des temps de lecture systématiquement inférieurs à une seconde sans réanalyser toutes les lignes brutes.
1
Créer la table d’événements bruts
PARTITION BY toYYYYMM(event_time)permet de conserver des partitions de petite taille et faciles à supprimer.ORDER BY (event_time, user_id)prend en charge les requêtes bornées dans le temps + le filtre secondaire.LowCardinality(String)économise de la mémoire pour les dimensions catégorielles.TTLsupprime les données brutes après 90 jours (à ajuster selon vos exigences de rétention).
2
Concevoir la table de rollup (agrégée)
Nous effectuerons une préagrégation à une granularité horaire. Choisissez la granularité en fonction de la période d’analyse la plus courante.AggregateFunction(sum, ...)) qui représentent de façon compacte des agrégats partiels et peuvent être fusionnés ou finalisés ultérieurement.3
Créer une vue matérialisée qui alimente le rollup
Cette vue matérialisée se déclenche automatiquement lors des insertions dansevents_raw et écrit des états d’agrégation dans le rollup.4
5
Interroger le rollup
Vous pouvez soit fusionner les états à la lecture, soit les finaliser :- Fusionner à la lecture
- Finaliser avec -Final
6
Filtrez sur les champs de la clé primaire pour des performances optimales
Vous pouvez utiliser la commandeEXPLAIN pour voir comment l’index est utilisé pour écarter des données :Query
Response
(bucket_start, country, event_type).
Pour obtenir les meilleures performances de filtrage, assurez-vous que vos requêtes utilisent les champs de la clé primaire afin d’écarter les données inutiles.7
Variantes courantes
- Granularités différentes : ajoutez un rollup quotidien :
- Compression : appliquez des codecs aux colonnes volumineuses (exemple :
Codec(ZSTD(3))) dans la table brute. - Contrôle des coûts : concentrez la rétention la plus lourde sur la table brute et conservez des roll-ups de longue durée.
- Backfilling : lors du chargement de données historiques, insérez dans
events_rawet laissez la vue matérialisée créer automatiquement les roll-ups. Pour les lignes existantes, utilisezPOPULATElors de la création de la vue matérialisée si cela s’y prête, ouINSERT SELECT.
8
Nettoyage et rétention
- Augmentez le TTL des données brutes (par ex., 30/90 jours), mais conservez les agrégats plus longtemps (par ex., 1 an).
- Vous pouvez également utiliser TTL pour déplacer les anciennes parts vers un stockage moins coûteux si la hiérarchisation par niveaux est activée.
9
Dépannage
- La vue matérialisée ne se met pas à jour ? Vérifiez que les insertions arrivent bien dans events_raw (et non dans la table de rollup) et que la cible de la vue matérialisée est correcte (
TO events_rollup_1h). - Requêtes lentes ? Vérifiez qu’elles utilisent bien le rollup (interrogez directement la table de rollup) et que les filtres temporels correspondent à sa granularité.
- Écarts après backfill ? Utilisez
SYSTEM FLUSH LOGSet vérifiezsystem.query_log/system.partspour confirmer les insertions et les fusions.