ClickHouse/docs/fr/introduction/performance.md
Ivan Blinkov d91c97d15d
[docs] replace underscores with hyphens (#10606)
* Replace underscores with hyphens

* remove temporary code

* fix style check

* fix collapse
2020-04-30 21:19:18 +03:00

4.2 KiB
Raw Blame History

machine_translated machine_translated_rev toc_priority toc_title
true f865c9653f 6 Performance

Performance

Selon les résultats des tests internes chez Yandex, ClickHouse affiche les meilleures performances (à la fois le débit le plus élevé pour les requêtes longues et la latence la plus faible pour les requêtes courtes) pour des scénarios dexploitation comparables parmi les systèmes de sa classe disponibles pour les tests. Vous pouvez afficher les résultats du test sur un page séparée.

De nombreux points de repère indépendants sont arrivés à des conclusions similaires. Ils ne sont pas difficiles à trouver en utilisant une recherche sur internet, ou vous pouvez voir notre petite collection de liens.

Débit Pour Une Seule Grande requête

Le débit peut être mesuré en lignes par seconde ou en mégaoctets par seconde. Si les données sont placées dans le cache de page, une requête pas trop complexe est traitée sur du matériel moderne à une vitesse denviron 2-10 GB / s de données non compressées sur un seul serveur (pour les cas les plus simples, la vitesse peut atteindre 30 GB/s). Si les données ne sont pas placées dans le cache de page, la vitesse dépend du sous-système de disque et du taux de compression des données. Par exemple, si le sous-système de disque permet de lire des données à 400 Mo/s et que le taux de compression des données est de 3, la vitesse devrait être denviron 1,2 Go/s. Pour obtenir la vitesse en lignes par seconde, divisez la vitesse en octets par seconde par la taille totale des colonnes utilisées dans la requête. Par exemple, si 10 octets de colonnes sont extraites, la vitesse devrait être denviron 100 à 200 millions de lignes par seconde.

La vitesse de traitement augmente presque linéairement pour le traitement distribué, mais seulement si le nombre de lignes résultant de lagrégation ou du tri nest pas trop important.

Latence Lors Du Traitement Des Requêtes Courtes

Si une requête utilise une clé primaire et ne sélectionne pas trop de colonnes et de lignes à traiter (des centaines de milliers), Vous pouvez vous attendre à moins de 50 millisecondes de latence (un seul chiffre de millisecondes dans le meilleur des cas) si les données sont placées dans le cache de page. Sinon, la latence est principalement dominée par le nombre de recherches. Si vous utilisez des lecteurs de disque rotatifs, pour un système qui nest pas surchargé, la latence peut être estimée avec cette formule: seek time (10 ms) * count of columns queried * count of data parts.

Débit Lors Du Traitement dune Grande quantité De requêtes Courtes

Dans les mêmes conditions, ClickHouse peut traiter plusieurs centaines de requêtes par seconde sur un seul serveur (jusquà plusieurs milliers dans le meilleur des cas). Étant donné que ce scénario nest pas typique pour les SGBD analytiques, nous vous recommandons dattendre un maximum de 100 requêtes par seconde.

Performances Lors De LInsertion De Données

Nous vous recommandons dinsérer des données dans des paquets dau moins 1000 lignes, ou pas plus quune seule demande par seconde. Lors de linsertion dans une table MergeTree à partir dun dump séparé par des tabulations, la vitesse dinsertion peut être de 50 à 200 Mo/s. Si les lignes insérées ont une taille denviron 1 KO, La vitesse sera de 50 000 à 200 000 lignes par seconde. Si les lignes sont petites, les performances peuvent être plus élevées en lignes par seconde (sur les données du système de bannière -> 500 000 lignes par seconde; sur les données de Graphite -> 1 000 000 lignes par seconde). Pour améliorer les performances, vous pouvez effectuer plusieurs requêtes Dinsertion en parallèle, qui sadaptent linéairement.

Article Original