Politique de rétention
Définir une durée appropriée selon les besoins.
Éviter l’accumulation de données inutiles.
Exemple de stratégie à plusieurs niveaux :
Données brutes : 7 jours
Agrégats horaires : 90 jours
Agrégats journaliers : 2 ans
Utiliser des tasks pour agréger et réduire le volume.
Durée des shards
Ajuster selon la fréquence des mesures.
Mesures très fréquentes : shards courts (1h à 6h).
Mesures occasionnelles : shards longs (1d à 7d).
Trop de shards = overhead de gestion.
Trop peu de shards = lectures/écritures inefficaces.
Indexation
Indexation automatique sur :
- Les tags
- Le timestamp
Optimiser l’utilisation des tags :
- Limiter aux métadonnées essentielles
- Éviter les tags très granulaires (bcp de valeurs différentes)
- Éviter les timestamps ou UUIDs comme tags
Exemple à éviter :
// Tag avec trop de cardinalité
measurement,request_id=uuid1 value=10
measurement,request_id=uuid2 value=20
// Des millions de valeurs différentes = index énorme
Exemple correct :
// Tag avec cardinalité raisonnable
measurement,endpoint=/api/users,method=GET value=10
measurement,endpoint=/api/posts,method=POST value=20
// Quelques dizaines/centaines de combinaisons
Bonnes pratiques
Utiliser les fields pour les valeurs de haute cardinalité.
Voir Tags vs Fields pour bien choisir.
Agréger les données anciennes via tasks périodiques.
Supprimer les measurements obsolètes.
Monitorer la taille des buckets régulièrement.
Configurer les caches mémoire selon la charge.
Utiliser le downsampling (réduction de résolution) :
// Task qui agrège les données anciennes
option task = {name: "downsample", every: 1h}
from(bucket: "raw_data")
|> range(start: -2h, stop: -1h)
|> aggregateWindow(every: 10m, fn: mean)
|> to(bucket: "aggregated_data")