TTL dans ClickStack
${TABLES_TTL} est remplacé par la durée de rétention configurée (3 jours sauf modification) lorsque le collector crée la table :
PARTITION BY. Cette clause peut contenir une expression SQL sur une ou plusieurs colonnes, dont le résultat détermine vers quelle partition une ligne est envoyée. Les données sont ainsi logiquement associées (via un préfixe commun de nom de dossier) à chaque partition sur le disque, qui peut ensuite être interrogée isolément. Dans l’exemple ci-dessus, le schéma otel_logs par défaut partitionne les données par jour à l’aide de l’expression toDate(Timestamp). À mesure que des lignes sont insérées dans ClickHouse, cette expression est évaluée pour chaque ligne et celle-ci est dirigée vers la partition correspondante si elle existe (si la ligne est la première d’une journée, la partition sera créée). Pour plus de détails sur le partitionnement et ses autres applications, voir “Partitions de table”.
Le schéma de la table inclut également TTL toDateTime(Timestamp) + ${TABLES_TTL} et le paramètre ttl_only_drop_parts = 1. La première clause garantit que les données seront supprimées une fois qu’elles dépassent le TTL configuré (3 jours par défaut). Le paramètre ttl_only_drop_parts = 1 fait en sorte que seules les data parts dont toutes les données ont expiré soient supprimées (au lieu de tenter une suppression partielle des lignes). Comme le partitionnement garantit que les données de jours distincts ne sont jamais fusionnées, elles peuvent ainsi être supprimées efficacement.
Par défaut, les données dont le TTL a expiré sont supprimées lorsque ClickHouse fusionne les data parts. Lorsque ClickHouse détecte que des données ont expiré, il effectue une fusion hors planification.
Planification du TTLLes TTL ne sont pas appliqués immédiatement, mais selon une planification, comme indiqué ci-dessus. Le paramètre de table MergeTree
merge_with_ttl_timeout définit le délai minimal, en secondes, avant de répéter une fusion avec suppression TTL. La valeur par défaut est de 14400 secondes (4 heures). Mais il ne s’agit que du délai minimal ; le déclenchement d’une fusion TTL peut prendre plus de temps. Si la valeur est trop faible, cela entraînera de nombreuses fusions hors planification susceptibles de consommer beaucoup de ressources. Une expiration TTL peut être forcée à l’aide de la commande ALTER TABLE my_table MATERIALIZE TTL.Modification du TTL
- Modifier les schémas des tables (recommandé). Pour cela, vous devez vous connecter à l’instance ClickHouse, par exemple avec clickhouse-client ou la Cloud SQL Console. Par exemple, vous pouvez modifier le TTL de la table
otel_logsà l’aide de l’instruction DDL suivante :
- Modifiez l’OTel collector. Le ClickStack OpenTelemetry collector crée des tables dans ClickHouse si elles n’existent pas. Cela se fait via le ClickHouse exporter, qui expose lui-même un paramètre
ttlpermettant de contrôler l’expression TTL par défaut, par exemple.
TTL au niveau de la colonne
Body au cas où de nouvelles métadonnées dynamiques seraient ajoutées sans avoir été extraites au moment de l’insertion, par exemple un nouveau label Kubernetes. Après un certain temps, par exemple 1 mois, il peut devenir évident que ces métadonnées supplémentaires ne sont pas utiles, ce qui réduit l’intérêt de conserver la colonne Body.
Ci-dessous, nous montrons comment supprimer la colonne Body après 30 jours.
Pour définir un TTL au niveau de la colonne, les utilisateurs doivent définir leur propre schéma. Cela ne peut pas être configuré dans l’OTel collector.