Isoler les charges de travail de lecture et d’écriture

​

Pourquoi isoler les lectures des écritures

• Les écritures cessent de dégrader les lectures. L’ingestion OpenTelemetry continue — les inserts eux-mêmes, ainsi que les fusions en arrière-plan qui les suivent — entre en concurrence avec les requêtes de tableaux de bord et de recherche pour le CPU et la mémoire. La latence de lecture peut se dégrader sensiblement pendant l’ingestion, puis revenir à la normale une fois celle-ci terminée.
• Les lectures cessent de perturber les écritures. La contention joue dans les deux sens : une requête ad hoc lourde ou un rendu de tableau de bord coûteux peut épuiser la mémoire du service et faire échouer purement et simplement les inserts, et pas seulement les ralentir.
• Le compute en lecture seule est entièrement dédié aux requêtes. Les services en lecture seule n’effectuent aucune fusion en arrière-plan en dehors des tables système. Ils passent également en veille sans délai, contrairement aux services en lecture-écriture, que les fusions peuvent maintenir actifs.
• Chaque côté est dimensionné indépendamment. Le modèle de dimensionnement estime séparément le compute d’ingestion et le compute de requêtes, et un warehouse vous permet de provisionner chacun comme un service distinct. Au-delà du seuil de référence de 1 QPS retenu par le modèle, c’est le compute de requêtes qui domine — son exemple détaillé à 5 QPS aboutit à 58 vCPU pour l’ingestion contre 290 pour les requêtes — de sorte qu’un petit service d’écriture peut alimenter un service de lecture bien plus important.
• La mise en veille et l’autoscaling se configurent par service. Chaque service dispose de son propre nombre de réplicas et de ses propres paramètres d’autoscaling et de mise en veille automatique : le service d’écriture peut ainsi rester toujours actif pour l’ingestion continue, tandis que le service de lecture se met en veille en dehors des heures de travail.
• Le stockage n’est pas dupliqué. Les services d’un warehouse partagent le même dossier de stockage objet et les mêmes tables, et le stockage n’est facturé qu’une seule fois.
• L’accès peut être restreint par endpoint. Les listes d’accès IP s’appliquent par service : l’endpoint d’écriture peut n’être joignable que depuis vos collectors et l’endpoint de lecture que depuis votre déploiement ClickStack. Consultez notre guide sur le contrôle d’accès réseau.

​

Architecture

• Le premier service d’un warehouse est toujours read-write, et le type d’un service est fixé à la création — pour passer de read-only à read-write, créez un nouveau service dans le warehouse.
• Tous les services d’un warehouse partagent le même cloud provider, la même region, la même version de ClickHouse, le même Keeper ainsi que l’upgrade schedule du service primary.
• N’utilisez qu’un seul service read-write pour l’ingestion. Les fusions sont réparties entre tous les services read-write qui partagent le stockage : une fusion liée à un insert sur un service peut donc être exécutée par un autre. Si cet autre service traite par ailleurs des requêtes lourdes, celles-ci entrent en concurrence avec la fusion pour le CPU et la mémoire du service qui l’exécute, ce qui ralentit les fusions liées aux inserts du premier service, et avec elles la performance d’insertion. Conservez les charges de travail de requêtes sur le service read-only et n’ajoutez un second service read-write que si vous avez besoin de séparer les fusions de l’ingestion.

​

Mise en place d’un déploiement isolé

CREATE DATABASE otel;
CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY '<strong-password>';
GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest;

CLICKHOUSE_ENDPOINT=https://<read-write-service>.clickhouse.cloud:8443
CLICKHOUSE_USER=hyperdx_ingest
CLICKHOUSE_PASSWORD=<strong-password>
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel

SELECT 
    user, 
    query_kind, 
    http_user_agent,
    count()
FROM clusterAllReplicas('default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL
ORDER BY count() DESC;

SELECT 
    hostName() AS host, 
    query_kind, 
    count()
FROM clusterAllReplicas('all_groups.default', system.query_log)
WHERE event_time > now() - toIntervalMinute(10) 
  AND type = 'QueryFinish'
  AND is_initial_query = 1
GROUP BY ALL;

​

Séparer les fusions de l’ingestion

• Ne comptez pas sur l’auto-idling pour l’un ou l’autre des services en lecture-écriture. Un service dont les fusions sont désactivées traite malgré tout les événements de téléchargement et de suppression de parts générés par des insertions ailleurs dans le warehouse, et un nombre élevé de parts non fusionnées peut à lui seul empêcher l’idling. Prévoyez que les deux services en lecture-écriture restent actifs en permanence.
• N’envoyez aucune requête vers les services en lecture-écriture. Des requêtes SELECT lourdes sur un service en lecture-écriture entrent en concurrence avec le travail de fusion pour le CPU et la mémoire, ce qui constitue précisément le mode de défaillance que cette topologie vise à éviter. Pointez ClickStack vers le service en lecture seule comme décrit ci-dessus.
• Les mutations, lorsque vous en avez, sont suivies sur le service qui les exécute. Les mutations sont rares en observability — le schéma de ClickStack définit ttl_only_drop_parts = 1, de sorte que la rétention ordinaire supprime des parts expirées entières lors des fusions TTL plutôt que de muter les lignes une à une. Si vous soumettez au service d’ingestion un ALTER produisant une mutation, celle-ci est exécutée par le service de fusion, et sa progression apparaît dans system.mutations sur ce service plutôt que sur le service d’ingestion.

​

Administration et DDL

• La création de tables — effectuée automatiquement par le ClickStack collector lors de la première ingestion
• La modification du TTL pour ajuster la rétention
• La création de vues matérialisées pour accélérer les requêtes
• L’ajout d’index de saut, de projections et d’autres optimisations de performance

CREATE DATABASE otel
SETTINGS distributed_ddl_task_timeout=0

​

Isoler les charges de travail agentiques

claude mcp add --transport http clickstack https://mcp.clickhouse.cloud/clickstack \
  --header "x-service-id: <read-only-agent-service-id>"

​

Alerts

​

Isoler l’évaluation des alertes

• Les alertes communes, ainsi que les dashboards qui les accompagnent, n’existent que sur le service d’alerting et ne sont pas visibles pour les utilisateurs travaillant sur le service de requêtage. Les notifications sont acheminées vers les mêmes destinations dans les deux cas : ce que les utilisateurs perdent, c’est la visibilité sur les définitions, et non l’alerting lui-même.
• Les sources du service d’alerting sont des objets distincts. Celles qui utilisent le schéma OpenTelemetry par défaut sont détectées automatiquement, mais les sources personnalisées doivent aussi y être configurées avant qu’une alerte puisse les référencer.

​

Considérations supplémentaires