> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8c05c8a2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Dimensionnement des ressources

> Guide de dimensionnement des ressources pour les déploiements Managed ClickStack

Ce qui suit propose un modèle pour estimer les ressources de calcul et de stockage nécessaires à un déploiement ClickStack en fonction du volume d’ingestion prévu. Les valeurs obtenues sont **uniquement des estimations** et doivent servir de **référence initiale** - elles ne constituent pas une recommandation prescriptive. Les besoins réels dépendent de la complexité des requêtes, de la concurrence, des politiques de rétention et des variations du débit d’ingestion. Surveillez toujours l’utilisation des ressources et adaptez le dimensionnement selon les besoins.

<Warning>
  **Tous les chiffres sont basés sur l’ingestion brute non compressée**

  Tous les chiffres indiqués sur cette page - débit (MB/s, TB/mois), dimensionnement CPU et stockage - sont exprimés en **volume d’ingestion brute non compressée**, c’est-à-dire la taille des données telles qu’elles sont produites par vos applications et envoyées au collecteur OpenTelemetry avant toute compression.

  C’est ce volume que vous devez estimer à partir de vos pipelines existants de logs, de traces et de métriques. Les chiffres de stockage du tableau ci-dessous intègrent déjà le **taux de compression de 10x** supposé appliqué à ce volume brut.
</Warning>

Lors du déploiement de ClickStack, provisionnez les ressources de calcul pour couvrir deux charges de travail indépendantes : **ingestion** et **requêtes**.

| Charge de travail | Ressources estimées                                         |
| ----------------- | ----------------------------------------------------------- |
| **Ingestion**     | 1 vCPU pour 10 MB/s de débit d’ingestion soutenu            |
| **Requêtes**      | 1 vCPU par QPS et pour 10 MB/s de débit d’ingestion soutenu |

<Info>
  **Isolation des requêtes par rapport à l’ingestion**

  Dans la plupart des déploiements autogérés, l’ingestion et les requêtes partagent les mêmes nœuds. Dans ce cas, utilisez le total des **CPU** comme référence. Le dimensionnement isolé - où les ressources de calcul pour l’ingestion et les requêtes sont provisionnées indépendamment - est pris en charge dans ClickHouse Cloud via des [pools de calcul distincts, appelés Warehouses](/fr/products/cloud/features/infrastructure/warehouses).
</Info>

<Accordion title="Hypothèses">
  * Un **taux de compression de 10x** pour le stockage - généralement une hypothèse prudente pour les logs et les traces.
  * Des SLA de requête avec un P50 de 1,5 seconde et un P99 de 5 secondes.
  * Nous supposons que la plupart des requêtes portent sur des données récentes, selon une distribution log-normale qui culmine autour d’une heure et décroît jusqu’à environ six heures. Les utilisateurs peuvent souhaiter provisionner des ressources de calcul dédiées pour interroger des données plus anciennes. Dans ClickHouse Cloud, celles-ci peuvent rester inactives (et donc ne pas engendrer de coûts) lorsqu’elles ne sont pas utilisées.
  * Bien que les ressources de calcul des requêtes puissent être dimensionnées indépendamment de celles de l’ingestion, elles restent intrinsèquement liées au volume d’ingestion. Nous partons du principe qu’à mesure que l’ingestion augmente, la densité des données croît, ce qui entraîne des volumes analysés plus importants au moment des requêtes et, par conséquent, des besoins plus élevés en ressources de calcul pour les requêtes.
</Accordion>

Le tableau suivant présente des exemples de dimensionnement basés sur un débit d’ingestion croissant en mégaoctets par seconde, ainsi que les volumes de données correspondants en téraoctets par mois. Il suppose une moyenne soutenue de **1 QPS** depuis ClickStack sur l’ensemble des types de requêtes (recherche, tableaux de bord, alertes).

| MB/s | TB/mois | CPU d’ingestion | CPU de requête | CPU totaux | Stockage total (par mois) (GB) |
| ---: | ------: | --------------: | -------------: | ---------: | -----------------------------: |
|   10 |   25.92 |               1 |              3 |          4 |                          2,592 |
|   20 |   51.84 |               2 |              6 |          8 |                          5,184 |
|   50 |   129.6 |               5 |             15 |         20 |                         12,960 |
|  100 |   259.2 |              10 |             30 |         40 |                         25,920 |
|  200 |   518.4 |              20 |             60 |         80 |                         51,840 |
|  500 |   1,296 |              50 |            150 |        200 |                        129,600 |
| 1000 |   2,592 |             100 |            300 |        400 |                        259,200 |

<div id="refining-sizing-assumptions">
  ## Affiner les hypothèses de dimensionnement pour votre environnement
</div>

Le modèle suppose une moyenne soutenue de 1 QPS depuis ClickStack, tous types de requêtes confondus, y compris la recherche, les dashboards et les alertes.

Pour des volumes de requêtes plus élevés, faites évoluer les besoins en CPU de manière linéaire en multipliant les besoins en CPU par le QPS cible. Par exemple, un déploiement ingérant 100 MB/s avec un objectif de 9 QPS nécessiterait 90 CPU pour les requêtes (10 × 9) au lieu des 10 de référence, soit un total révisé de 100 CPU (10 pour l’ingestion + 90 pour les requêtes).

Les estimations de stockage supposent un taux de compression prudent de 10x. En pratique, les logs, les traces et les métriques obtiennent souvent une compression plus élevée. Nous recommandons d’effectuer des tests sur un échantillon de données afin de déterminer à l’avance votre taux de compression et vos besoins de stockage avant la mise en production. Pour calculer le stockage nécessaire pour une durée de rétention plus longue, multipliez le stockage mensuel par le nombre de mois de rétention requis.

Cela suppose une répartition des requêtes relativement équilibrée. Les charges de travail davantage orientées vers des requêtes historiques ou d’archivage plus lourdes peuvent avoir des besoins en calcul sensiblement différents et doivent être validées par des tests de charge. Nous prévoyons d’introduire un modèle de dimensionnement plus flexible, permettant d’extrapoler les ressources de calcul des requêtes selon différents profils de répartition des requêtes.

<div id="worked-example">
  ### Exemple pratique
</div>

**Exigences :** ingestion de 1,5 PB/mois, 5 QPS, rétention de 3 mois.

**Conversion en MB/s**

Le modèle de dimensionnement est exprimé en MB/s. Conversion de 1,5 PB/mois (1 500 TB) en débit constant :

* 1 500 TB = 1 500 000 000 MB
* Secondes par mois (30 jours) : 30 × 24 × 60 × 60 = 2 592 000
* MB/s = 1 500 000 000 ÷ 2 592 000 ≈ **579 MB/s**

**Calcul pour l’ingestion**

Avec 1 vCPU pour 10 MB/s d’ingestion constante :

579 ÷ 10 = **\~58 vCPUs** pour l’ingestion

**Calcul pour les requêtes**

La capacité de calcul pour les requêtes dépend à la fois du débit d’ingestion et du QPS. À 5 QPS :

(579 ÷ 10) × 5 = 58 × 5 = **290 vCPUs** pour les requêtes

**Stockage**

Avec 579 MB/s constants sur 30 jours, l’ingestion brute représente 1 500 TB/mois. En appliquant le ratio de compression supposé de 10x :

* Compressé par mois : 1 500 TB ÷ 10 = **150 TB/mois**
* Pour une rétention de 3 mois : 150 TB × 3 = **450 TB au total**

**Résumé**

| Ressource                             | Valeur    |
| ------------------------------------- | --------- |
| Calcul pour l’ingestion               | 58 vCPUs  |
| Calcul pour les requêtes              | 290 vCPUs |
| Calcul total                          | 348 vCPUs |
| Stockage par mois (compressé)         | 150 TB    |
| Stockage pour une rétention de 3 mois | 450 TB    |

<div id="isolating-workloads">
  ## Isolation des charges de travail d’observabilité
</div>

Si vous ajoutez ClickStack à un **service ClickHouse Cloud existant** qui prend déjà en charge d’autres charges de travail, comme l’analytique applicative en temps réel, il est fortement recommandé d’isoler le trafic d’observabilité.

Utilisez [**Managed Warehouses**](/fr/products/cloud/features/infrastructure/warehouses) pour créer un **service enfant** dédié à ClickStack. Cela vous permet de :

* Isoler la charge liée à l’ingestion et aux requêtes des applications existantes
* Faire évoluer indépendamment les charges de travail d’observabilité
* Empêcher les requêtes d’observabilité d’affecter l’analytique en production
* Partager, si nécessaire, les mêmes jeux de données sous-jacents entre les services

Cette approche garantit que vos charges de travail existantes restent inchangées, tout en permettant à ClickStack de monter en charge de manière indépendante à mesure que les données d’observabilité augmentent.

Pour les déploiements de plus grande envergure ou pour des conseils personnalisés en matière de dimensionnement, veuillez contacter le support afin d’obtenir une estimation plus précise.