ClickHouse

Bases de données

Interrogez des données analytiques en temps réel, gérez des tables et réglez les performances ClickHouse — Neotask utilise OpenClaw pour le rendre conversationnel.

Ce que vous pouvez faire

Exécuter des requêtes analytiques en temps réel

Décrivez votre question analytique — "montre-moi le taux de clics par campagne pour les 7 derniers jours, réparti en buckets horaires" — et Neotask rédige du SQL ClickHouse optimisé pour l'exécution en colonnes.

Diagnostiquer la santé des fusions et des parts

Demandez à Neotask de vérifier la table system.parts pour les tables avec trop de parts, d'identifier les fusions en cours, ou de trouver les partitions avec des comptages de lignes inattendus. Il interprète le backlog de fusion ClickHouse et vous dit si un OPTIMIZE manuel est nécessaire.

Surveiller la réplication et les requêtes distribuées

Pour les tables ReplicatedMergeTree et Distributed, demandez le décalage de réplication, la profondeur de la file d'attente et si des réplicas sont en retard. Neotask interroge system.replication_queue et system.replicas et explique ce que signifient les chiffres.

Gérer les structures de tables et les TTL

Créez des tables de la famille MergeTree avec les bonnes expressions ORDER BY, PARTITION BY et TTL — décrites en langage naturel, générées comme DDL ClickHouse correct. Ajoutez ou modifiez des règles TTL pour l'expiration automatique des données.

Régler les performances des requêtes

Collez une requête ClickHouse lente et demandez à Neotask d'interpréter la sortie du journal des requêtes, d'identifier si la clé primaire est utilisée efficacement et de suggérer si une projection ou une vue matérialisée aiderait.

Essayez de demander

  • "Montre-moi les pages vues par heure pour les dernières 24 heures depuis la table events"
  • "Quelles tables ont plus de 1000 parts et pourraient avoir besoin d'OPTIMIZE ?"
  • "À quel point mes réplicas sont-ils en retard en ce moment ?"
  • "Crée une table ReplicatedMergeTree pour stocker les événements utilisateurs partitionnés par mois"
  • "Pourquoi cette requête n'utilise-t-elle pas la clé primaire ?" (collez votre requête)
  • "Ajoute un TTL à la table logs pour supprimer les lignes de plus de 90 jours"
  • "Montre-moi les 10 requêtes les plus lentes de la dernière heure en utilisant system.query_log"
  • "Crée une vue matérialisée qui pré-agrège les totaux horaires depuis la table d'événements bruts"

    • Conseils pro

  • Concevez votre ORDER BY (clé primaire) pour vos filtres de requêtes les plus fréquents — demandez à Neotask de revoir vos schémas de requêtes et de recommander une clé optimale avant de créer la table.
  • Utilisez LowCardinality() pour les colonnes de chaînes avec moins de 10 000 valeurs distinctes — Neotask le suggérera automatiquement quand il voit des colonnes de chaînes dans votre description de schéma.
  • Préférez toStartOfHour() et toStartOfDay() pour le bucketing temporel plutôt que l'arithmétique de date manuelle.
  • Lors de l'insertion de données, regroupez les insertions en au moins quelques milliers de lignes par insertion — demandez à Neotask de vérifier vos schémas d'insertion si vous voyez des comptages de parts excessifs.
  • Les vues matérialisées dans ClickHouse se déclenchent lors de l'insertion, pas lors de la lecture — demandez à Neotask de confirmer que votre logique d'agrégation gère correctement les mises à jour incrémentielles avant d'en créer une.

    • Works Well With