> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Dimensionnement et recommandations matérielles

> Ce guide présente nos recommandations générales concernant le matériel, les ressources de calcul, la mémoire et les configurations de disque pour les utilisateurs de la version open source.

Ce guide présente nos recommandations générales concernant le matériel, les ressources de calcul, la mémoire et les configurations de disque pour les utilisateurs de la version open source. Si vous souhaitez simplifier votre déploiement, nous vous recommandons d’utiliser [ClickHouse Cloud](https://clickhouse.com/cloud), car il s’adapte automatiquement à la charge et à vos charges de travail tout en réduisant les coûts liés à la gestion de l’infrastructure.

La configuration de votre cluster ClickHouse dépend fortement du cas d’usage de votre application et de ses profils de charge de travail. Lors de la planification de votre architecture, vous devez tenir compte des facteurs suivants :

* Concurrence (requêtes par seconde)
* Débit (lignes traitées par seconde)
* Volume de données
* Politique de rétention des données
* Coûts matériels
* Coûts de maintenance

<div id="disk">
  ## Disque
</div>

Les types de disques à utiliser avec ClickHouse dépendent du volume de données ainsi que des exigences en matière de latence ou de débit.

<div id="optimizing-for-performance">
  ### Optimiser les performances
</div>

Pour maximiser les performances, nous recommandons d’attacher directement des [volumes SSD AWS à IOPS provisionnées](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/provisioned-iops.html), ou l’offre équivalente de votre fournisseur cloud, afin d’optimiser les IO.

<div id="optimizing-for-storage-costs">
  ### Optimisation des coûts de stockage
</div>

Pour réduire les coûts, vous pouvez utiliser des [volumes EBS SSD à usage général](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html).

Vous pouvez également mettre en place un stockage hiérarchisé reposant sur des SSD et des HDD dans une [architecture hot/warm/cold](/docs/fr/concepts/features/operations/delete/ttl#implementing-a-hotwarmcold-architecture). Autre possibilité : utiliser [AWS S3](https://aws.amazon.com/s3/) pour le stockage afin de séparer les ressources de calcul et le stockage. Consultez notre guide sur l’utilisation de ClickHouse open source avec séparation des ressources de calcul et du stockage [ici](/docs/fr/guides/oss/deployment-and-scaling/separation-storage-compute). La séparation des ressources de calcul et du stockage est disponible par défaut dans ClickHouse Cloud.

<div id="cpu">
  ## CPU
</div>

<div id="which-cpu-should-i-use">
  ### Quel CPU dois-je utiliser ?
</div>

Le type de CPU à utiliser dépend de votre profil d’utilisation. De manière générale, toutefois, les applications qui exécutent de nombreuses requêtes concurrentes fréquentes, qui traitent plus de données ou qui utilisent des UDF gourmandes en calcul nécessiteront davantage de cœurs CPU.

**Applications à faible latence ou orientées client**

Pour des exigences de latence de l’ordre de quelques dizaines de millisecondes, comme pour des charges de travail orientées client, nous recommandons la [gamme i3](https://aws.amazon.com/ec2/instance-types/i3/) ou la [gamme i4i](https://aws.amazon.com/ec2/instance-types/i4i/) d’AWS, ou une offre équivalente de votre fournisseur cloud, optimisées pour les IO.

**Applications à forte concurrence**

Pour les charges de travail qui doivent être optimisés pour la concurrence (plus de 100 requêtes par seconde), nous recommandons la [série C optimisée pour le calcul](https://aws.amazon.com/ec2/instance-types/#Compute_Optimized) d’AWS, ou une offre équivalente de votre fournisseur cloud.

**Cas d’usage de data warehousing**

Pour les charges de travail de data warehousing et les requêtes analytiques ad hoc, nous recommandons la [série de type R](https://aws.amazon.com/ec2/instance-types/#Memory_Optimized) d’AWS, ou une offre équivalente de votre fournisseur cloud, car elle est optimisée pour la mémoire.

***

<div id="what-should-cpu-utilization-be">
  ### Quel taux d’utilisation du CPU viser ?
</div>

Il n’existe pas d’objectif standard en matière d’utilisation du CPU pour ClickHouse. Utilisez un outil tel que [iostat](https://linux.die.net/man/1/iostat) pour mesurer l’utilisation moyenne du CPU, puis ajustez en conséquence la taille de vos serveurs afin d’absorber les pics de trafic imprévus. En revanche, pour les cas d’usage analytiques ou de data warehousing avec des requêtes ad hoc, visez un taux d’utilisation du CPU de 10 à 20 %.

<div id="how-many-cpu-cores-should-i-use">
  ### Combien de cœurs CPU dois-je utiliser ?
</div>

Le nombre de CPU à utiliser dépend de votre charge de travail. Cependant, nous recommandons généralement les ratios mémoire/cœur CPU suivants selon votre type de CPU :

* **[M-type](https://aws.amazon.com/ec2/instance-types/) (cas d’usage généraux) :** ratio mémoire/cœur CPU de 4 Go:1
* **[R-type](https://aws.amazon.com/ec2/instance-types/#Memory_Optimized) (cas d’usage de data warehousing) :** ratio mémoire/cœur CPU de 8 Go:1
* **[C-type](https://aws.amazon.com/ec2/instance-types/#Compute_Optimized) (cas d’usage optimisés pour le calcul) :** ratio mémoire/cœur CPU de 2 Go:1

Par exemple, avec des CPU de type M, nous recommandons d’allouer 100 Go de mémoire pour 25 cœurs CPU. Pour déterminer la quantité de mémoire adaptée à votre application, il est nécessaire de profiler votre utilisation de la mémoire. Vous pouvez consulter [ce guide sur le débogage des problèmes de mémoire](/docs/fr/concepts/features/performance/troubleshoot/debugging-memory-issues) ou utiliser le [tableau de bord d’observabilité intégré](/docs/fr/guides/oss/deployment-and-scaling/monitoring/monitoring) pour surveiller ClickHouse.

<div id="memory">
  ## Mémoire
</div>

Comme pour le choix du CPU, le choix du ratio mémoire/stockage et du ratio mémoire/CPU dépend de votre cas d’utilisation.

Le volume de RAM requis dépend généralement de :

* La complexité des requêtes.
* La quantité de données traitées par les requêtes.

De manière générale, toutefois, plus vous disposez de mémoire, plus vos requêtes s’exécuteront rapidement.
Si votre cas d’utilisation est sensible au prix, des quantités de mémoire plus faibles peuvent convenir, car il est possible d’activer des paramètres ([`max_bytes_before_external_group_by`](/docs/fr/reference/settings/session-settings#max_bytes_before_external_group_by) et [`max_bytes_before_external_sort`](/docs/fr/reference/settings/session-settings#max_bytes_before_external_sort)) pour autoriser l’écriture des données sur disque, mais notez que cela peut affecter significativement les performances des requêtes.

<div id="what-should-the-memory-to-storage-ratio-be">
  ### Quel devrait être le ratio mémoire/stockage ?
</div>

Pour de faibles volumes de données, un ratio mémoire/stockage de 1:1 est acceptable, mais la mémoire totale ne doit pas être inférieure à 8 Go.

Pour les cas d’utilisation impliquant une longue période de rétention des données ou des volumes de données élevés, nous recommandons un ratio mémoire/stockage de 1:100 à 1:130. Par exemple, 100 Go de RAM par réplique si vous stockez 10 To de données.

Pour les cas d’utilisation avec des accès fréquents, comme les charges de travail orientées client, nous recommandons d’utiliser davantage de mémoire, avec un ratio mémoire/stockage de 1:30 à 1:50.

<div id="replicas">
  ## Répliques
</div>

Nous recommandons d’avoir au moins trois répliques par segment (ou deux répliques avec [Amazon EBS](https://aws.amazon.com/ebs/)). De plus, nous vous conseillons d’augmenter verticalement les ressources de toutes les répliques avant d’ajouter des répliques supplémentaires (mise à l’échelle horizontale).

ClickHouse n’effectue pas le sharding automatiquement, et repartitionner votre jeu de données nécessitera une puissance de calcul importante. Par conséquent, nous recommandons généralement d’utiliser le plus grand serveur disponible afin d’éviter d’avoir à repartitionner vos données à l’avenir.

Envisagez d’utiliser [ClickHouse Cloud](https://clickhouse.com/cloud), qui se met à l’échelle automatiquement et vous permet de contrôler facilement le nombre de répliques selon votre cas d’utilisation.

<div id="example-configurations-for-large-workloads">
  ## Exemples de configurations pour de fortes charges de travail
</div>

Les configurations de ClickHouse dépendent fortement des exigences propres à votre application. Veuillez [contacter l’équipe commerciale](https://clickhouse.com/company/contact?loc=docs-sizing-and-hardware-recommendations) si vous souhaitez que nous vous aidions à optimiser votre architecture en termes de coût et de performances.

À titre indicatif uniquement, et non comme recommandation, voici quelques exemples de configurations d’utilisateurs de ClickHouse en production :

<div id="fortune-500-b2b-saas">
  ### SaaS B2B du classement Fortune 500
</div>

<table>
  <tr>
    <td col="2"><strong><em>Stockage</em></strong></td>
  </tr>

  <tr>
    <td><strong>Volume mensuel de nouvelles données</strong></td>
    <td>30TB</td>
  </tr>

  <tr>
    <td><strong>Stockage total (compressé)</strong></td>
    <td>540TB</td>
  </tr>

  <tr>
    <td><strong>Rétention des données</strong></td>
    <td>18 mois</td>
  </tr>

  <tr>
    <td><strong>Disque par nœud</strong></td>
    <td>25TB</td>
  </tr>

  <tr>
    <td col="2"><strong><em>CPU</em></strong></td>
  </tr>

  <tr>
    <td><strong>Concurrence</strong></td>
    <td>200+ requêtes simultanées</td>
  </tr>

  <tr>
    <td><strong># de répliques (y compris la paire HA)</strong></td>
    <td>44</td>
  </tr>

  <tr>
    <td><strong>vCPU par nœud</strong></td>
    <td>62</td>
  </tr>

  <tr>
    <td><strong>Total des vCPU</strong></td>
    <td>2700</td>
  </tr>

  <tr>
    <td col="2"><strong><em>Mémoire</em></strong></td>
  </tr>

  <tr>
    <td><strong>RAM totale</strong></td>
    <td>11TB</td>
  </tr>

  <tr>
    <td><strong>RAM par réplique</strong></td>
    <td>256GB</td>
  </tr>

  <tr>
    <td><strong>Ratio RAM/vCPU</strong></td>
    <td>4 GB:1</td>
  </tr>

  <tr>
    <td><strong>Ratio RAM/disque</strong></td>
    <td>1:50</td>
  </tr>
</table>

<div id="fortune-500-telecom-operator-for-a-logging-use-case">
  ### Opérateur télécom du Fortune 500 pour un cas d’usage de logs
</div>

<table>
  <tr>
    <td col="2"><strong><em>Stockage</em></strong></td>
  </tr>

  <tr>
    <td><strong>Volume mensuel de données de logs</strong></td>
    <td>4860TB</td>
  </tr>

  <tr>
    <td><strong>Stockage total (compressé)</strong></td>
    <td>608TB</td>
  </tr>

  <tr>
    <td><strong>Rétention des données</strong></td>
    <td>30 jours</td>
  </tr>

  <tr>
    <td><strong>Disque par nœud</strong></td>
    <td>13TB</td>
  </tr>

  <tr>
    <td col="2"><strong><em>CPU</em></strong></td>
  </tr>

  <tr>
    <td><strong># de répliques (y compris la paire HA)</strong></td>
    <td>38</td>
  </tr>

  <tr>
    <td><strong>vCPU par nœud</strong></td>
    <td>42</td>
  </tr>

  <tr>
    <td><strong>Total vCPU</strong></td>
    <td>1600</td>
  </tr>

  <tr>
    <td col="2"><strong><em>Mémoire</em></strong></td>
  </tr>

  <tr>
    <td><strong>RAM totale</strong></td>
    <td>10TB</td>
  </tr>

  <tr>
    <td><strong>RAM par réplique</strong></td>
    <td>256GB</td>
  </tr>

  <tr>
    <td><strong>Ratio RAM/vCPU</strong></td>
    <td>6 GB:1</td>
  </tr>

  <tr>
    <td><strong>Ratio RAM/disque</strong></td>
    <td>1:60</td>
  </tr>
</table>

<div id="further-reading">
  ## Pour en savoir plus
</div>

Voici des articles de blog publiés sur les architectures d’entreprises qui utilisent ClickHouse open source :

* [Cloudflare](https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/?utm_source=linkedin\&utm_medium=social\&utm_campaign=blog)
* [eBay](https://innovation.ebayinc.com/tech/engineering/ou-online-analytical-processing/)
* [GitLab](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/clickhouse_usage/)
* [Lyft](https://eng.lyft.com/druid-deprecation-and-clickhouse-adoption-at-lyft-120af37651fd)
* [MessageBird](https://clickhouse.com/blog/how-messagebird-uses-clickhouse-to-monitor-the-delivery-of-billions-of-messages)
* [Microsoft](https://clickhouse.com/blog/self-service-data-analytics-for-microsofts-biggest-web-properties)
* [Uber](https://www.uber.com/en-ES/blog/logging/)
* [Zomato](https://blog.zomato.com/building-a-cost-effective-logging-platform-using-clickhouse-for-petabyte-scale)