ClickHouse/docs/fr/index.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

9.1 KiB
Raw Blame History

machine_translated machine_translated_rev toc_priority toc_title
true f865c9653f 3 Aperçu

Quest-ce Que ClickHouse?

ClickHouse est un système de gestion de base de données orienté colonne (SGBD) pour le traitement analytique en ligne des requêtes (OLAP).

Dans un “normal” SGBD orienté ligne, les données sont stockées dans cet ordre:

Rangée WatchID JavaEnable Intitulé GoodEvent EventTime
#0 89354350662 1 Relations Avec Les Investisseurs 1 2016-05-18 05:19:20
#1 90329509958 0 Contacter 1 2016-05-18 08:10:20
#2 89953706054 1 Mission 1 2016-05-18 07:38:00
#N

En dautres termes, toutes les valeurs liées à une ligne sont physiquement stockées lune à côté de lautre.

Des exemples dun SGBD orienté ligne sont MySQL, Postgres et MS SQL Server.

Dans un SGBD orienté colonne, les données sont stockées comme ceci:

Rangée: #0 #1 #2 #N
WatchID: 89354350662 90329509958 89953706054
JavaEnable: 1 0 1
Intitulé: Relations Avec Les Investisseurs Contacter Mission
GoodEvent: 1 1 1
EventTime: 2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00

Ces exemples montrent lordre que les données sont organisées en. Les valeurs de différentes colonnes sont stockés séparément, et les données de la même colonne sont stockées ensemble.

Exemples Dun SGBD orienté colonne: Vertica, Paraccel (matrice Actian et Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise et Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid et kdb+.

Different orders for storing data are better suited to different scenarios. The data access scenario refers to what queries are made, how often, and in what proportion; how much data is read for each type of query rows, columns, and bytes; the relationship between reading and updating data; the working size of the data and how locally it is used; whether transactions are used, and how isolated they are; requirements for data replication and logical integrity; requirements for latency and throughput for each type of query, and so on.

Plus la charge sur le système est élevée, plus il est important de personnaliser le système configuré pour correspondre aux exigences du scénario dutilisation, et plus cette personnalisation devient fine. Il ny a pas de système qui soit aussi bien adapté à des scénarios significativement différents. Si un système est adaptable à un large ensemble de scénarios, sous une charge élevée, le système traitera tous les scénarios de manière également médiocre, ou fonctionnera bien pour un ou quelques-uns des scénarios possibles.

Propriétés clés Du scénario OLAP

  • La grande majorité des demandes concernent laccès en lecture.
  • Les données sont mises à jour en lots assez importants (> 1000 lignes), pas par des lignes simples; ou elles ne sont pas mises à jour du tout.
  • Les données sont ajoutées à la base de données mais ne sont pas modifiées.
  • Pour les lectures, un assez grand nombre de lignes sont extraites de la base de données, mais seulement un petit sous-ensemble de colonnes.
  • Les Tables sont “wide,” ce qui signifie quils contiennent un grand nombre de colonnes.
  • Les requêtes sont relativement rares (généralement des centaines de requêtes par serveur ou moins par seconde).
  • Pour les requêtes simples, les latences autour de 50 ms sont autorisées.
  • Les valeurs de colonne sont assez petites: nombres et chaînes courtes (par exemple, 60 octets par URL).
  • Nécessite un débit élevé lors du traitement dune seule requête (jusquà des milliards de lignes par seconde par serveur).
  • Les Transactions ne sont pas nécessaires.
  • Faibles exigences en matière de cohérence des données.
  • Il y a une grande table par requête. Toutes les tables sont petites, sauf une.
  • Un résultat de requête est significativement plus petit que les données source. En dautres termes, les données sont filtrées ou agrégées, de sorte que le résultat sintègre dans la RAM dun seul serveur.

Il est facile de voir que le scénario OLAP est très différent des autres scénarios populaires (tels que OLTP ou key-Value access). Il nest donc pas logique dessayer Dutiliser OLTP ou une base de données clé-valeur pour traiter les requêtes analytiques si vous voulez obtenir des performances décentes. Par exemple, si vous essayez Dutiliser MongoDB ou Redis pour lanalyse, vous obtiendrez des performances très médiocres par rapport aux bases de données OLAP.

Pourquoi Les Bases De données orientées Colonne Fonctionnent Mieux Dans Le scénario OLAP

Les bases de données orientées colonne sont mieux adaptées aux scénarios OLAP: elles sont au moins 100 fois plus rapides dans le traitement de la plupart des requêtes. Les raisons sont expliquées en détail ci-dessous, mais le fait est plus facile de démontrer visuellement:

SGBD orienté ligne

Row-oriented

SGBD orienté colonne

Column-oriented

Vous voyez la différence?

Dentrée/sortie

  1. Pour une requête analytique, seul un petit nombre de colonnes de table doit être lu. Dans une base de données orientée colonne, vous pouvez lire uniquement les données dont vous avez besoin. Par exemple, si vous avez besoin de 5 colonnes sur 100, Vous pouvez vous attendre à une réduction de 20 fois des e / s.
  2. Puisque les données sont lues en paquets, il est plus facile de les compresser. Les données dans les colonnes sont également plus faciles à compresser. Cela réduit dautant le volume de/S.
  3. En raison de la réduction des E / S, Plus de données sinsèrent dans le cache du système.

Par exemple, la requête “count the number of records for each advertising platform” nécessite la lecture dun “advertising platform ID” colonne, qui prend 1 octet non compressé. Si la majeure partie du trafic ne provenait pas de plates-formes publicitaires, vous pouvez vous attendre à une compression dau moins 10 fois de cette colonne. Lors de lutilisation dun algorithme de compression rapide, la décompression des données est possible à une vitesse dau moins plusieurs gigaoctets de données non compressées par seconde. En dautres termes, cette requête ne peut être traitée quà une vitesse denviron plusieurs milliards de lignes par seconde sur un seul serveur. Cette vitesse est effectivement atteinte dans la pratique.

CPU

Étant donné que lexécution dune requête nécessite le traitement dun grand nombre de lignes, il est utile de répartir toutes les opérations pour des vecteurs entiers au lieu de lignes séparées, ou dimplémenter le moteur de requête de sorte quil ny ait presque aucun coût dexpédition. Si vous ne le faites pas, avec un sous-système de disque à moitié décent, linterpréteur de requête bloque inévitablement le processeur. Il est logique de stocker des données dans des colonnes et de les traiter, si possible, par des colonnes.

Il y a deux façons de le faire:

  1. Un moteur vectoriel. Toutes les opérations sont écrites pour les vecteurs, au lieu de valeurs séparées. Cela signifie que vous navez pas besoin dappeler les opérations très souvent, et les coûts dexpédition sont négligeables. Le code dopération contient un cycle interne optimisé.

  2. La génération de Code. Le code généré pour la requête contient tous les appels indirects.

Ce nest pas fait dans “normal” bases de données, car cela na pas de sens lors de lexécution de requêtes simples. Cependant, il y a des exceptions. Par exemple, MemSQL utilise la génération de code pour réduire la latence lors du traitement des requêtes SQL. (À titre de comparaison, les SGBD analytiques nécessitent une optimisation du débit, et non une latence.)

Notez que pour lefficacité du processeur, le langage de requête doit être déclaratif (SQL ou MDX), ou au moins un vecteur (J, K). La requête ne doit contenir que des boucles implicites, permettant une optimisation.

{## Article Original ##}