Caractéristiques distinctives de ClickHouse

Comprenez ce qui distingue ClickHouse des autres systèmes de gestion de bases de données

​

Véritable système de gestion de base de données orienté colonnes

Dans un véritable SGBD orienté colonnes, aucune donnée supplémentaire n’est stockée avec les valeurs. Cela signifie que les valeurs de longueur fixe doivent être prises en charge afin d’éviter de stocker, à côté des valeurs, leur indication de longueur. Par exemple, un milliard de valeurs de type UInt8 devraient consommer environ 1 Go non compressé, faute de quoi l’utilisation du CPU s’en trouve fortement affectée. Il est essentiel de stocker les données de manière compacte (sans aucune donnée parasite), même lorsqu’elles ne sont pas compressées, car la vitesse de décompression (et donc l’utilisation du CPU) dépend principalement du volume de données non compressées.

Cela contraste avec les systèmes capables de stocker séparément les valeurs de différentes colonnes, mais qui ne peuvent pas traiter efficacement les requêtes analytiques en raison de leur optimisation pour d’autres usages, comme HBase, Bigtable, Cassandra et Hypertable. Avec ces systèmes, vous obtiendriez un débit d’environ cent mille lignes par seconde, mais pas des centaines de millions de lignes par seconde.

Enfin, ClickHouse est un système de gestion de base de données, et non une base de données unique. Il permet de créer des tables et des bases de données à l’exécution, de charger des données et d’exécuter des requêtes sans reconfigurer ni redémarrer le serveur.

​

Compression des données

Certains SGBD orientés colonnes n’utilisent pas la compression des données. Pourtant, la compression des données joue un rôle essentiel pour obtenir d’excellentes performances.

Outre des codecs de compression généralistes efficaces, offrant différents compromis entre l’espace disque et l’utilisation du CPU, ClickHouse propose des codecs spécialisés pour certains types de données, ce qui lui permet de rivaliser avec des bases de données plus spécialisées, comme les bases de données de séries temporelles, voire de les surpasser.

​

Stockage des données sur disque

Le fait de conserver les données physiquement triées selon la clé primaire permet d’extraire des données à partir de valeurs spécifiques ou de plages de valeurs avec une faible latence, en moins de quelques dizaines de millisecondes. Certains SGBD orientés colonnes, comme SAP HANA et Google PowerDrill, ne peuvent fonctionner qu’en RAM. Cette approche nécessite un budget matériel plus important que ce qui est nécessaire pour l’analyse en temps réel.

ClickHouse est conçu pour fonctionner sur des disques durs standard, ce qui signifie que le coût par Go de stockage des données est faible, tout en exploitant pleinement les SSD et la RAM supplémentaire lorsqu’ils sont disponibles.

​

Traitement parallèle sur plusieurs cœurs

Les requêtes volumineuses sont naturellement parallélisées et utilisent toutes les ressources nécessaires disponibles sur le serveur actuel.

​

Traitement distribué sur plusieurs serveurs

Presque aucun des SGBD colonnaires mentionnés ci-dessus n’offre de prise en charge du traitement distribué des requêtes.

Dans ClickHouse, les données peuvent être réparties sur différents segments. Chaque segment peut être constitué d’un groupe de répliques assurant la tolérance aux pannes. Tous les segments sont utilisés pour exécuter une requête en parallèle, de façon transparente pour l’utilisateur.

​

Prise en charge de SQL

ClickHouse prend en charge un langage de requête déclaratif basé sur SQL, largement compatible avec la norme ANSI SQL.

Les requêtes prises en charge incluent GROUP BY, ORDER BY, les sous-requêtes dans FROM, la clause JOIN, l’opérateur IN, les window functions et les sous-requêtes scalaires.

Les sous-requêtes corrélées (dépendantes) ne sont pas prises en charge au moment de la rédaction, mais pourraient l’être à l’avenir.

​

Moteur de calcul vectoriel

Les données ne sont pas seulement stockées par colonnes, elles sont aussi traitées sous forme de vecteurs (des portions de colonnes), ce qui permet d’obtenir une grande efficacité CPU.

​

Insertions de données en temps réel

ClickHouse prend en charge les tables avec une clé primaire. Pour exécuter rapidement des requêtes sur une plage de valeurs de la clé primaire, les données sont triées de manière incrémentielle à l’aide de MergeTree. Grâce à cela, des données peuvent être ajoutées en continu à la table. Aucun verrou n’est posé lors de l’ingestion de nouvelles données.

​

Index primaires

Le tri physique des données selon la clé primaire permet d’extraire des données correspondant à des valeurs spécifiques ou à des plages de valeurs avec une faible latence, en moins de quelques dizaines de millisecondes.

​

Index secondaires

Contrairement aux autres systèmes de gestion de bases de données, les index secondaires de ClickHouse ne pointent pas vers des lignes précises ni vers des plages de lignes. Ils permettent plutôt à la base de données de savoir à l’avance qu’aucune ligne de certaines parties de données ne correspondra aux conditions de filtrage de la requête, et donc de ne pas les lire du tout. C’est pourquoi on les appelle des index de saut de données.

​

Convient aux requêtes en ligne

La plupart des systèmes de gestion de bases de données OLAP ne sont pas conçus pour des requêtes en ligne avec une latence inférieure à la seconde. Dans les systèmes concurrents, un temps de génération de rapports de plusieurs dizaines de secondes, voire de plusieurs minutes, est souvent considéré comme acceptable. Il arrive même que cela prenne davantage de temps, ce qui oblige ces systèmes à préparer les rapports hors ligne (à l’avance ou en répondant « revenez plus tard »).

Dans ClickHouse, « faible latence » signifie que les requêtes peuvent être traitées sans délai et sans tenter de préparer une réponse à l’avance, au moment même où la page de l’UI se charge — autrement dit, en ligne.

​

Prise en charge des calculs approximatifs

ClickHouse propose plusieurs moyens de sacrifier de la précision au profit des performances :

1. Des fonctions d’agrégation pour le calcul approximatif du nombre de valeurs distinctes, des médianes et des quantiles.
2. Exécuter une requête sur une partie des données (SAMPLE) afin d’obtenir un résultat approximatif. Dans ce cas, proportionnellement moins de données sont lues depuis le disque.
3. Exécuter une agrégation sur un nombre limité de clés aléatoires, au lieu de le faire sur toutes les clés. Sous certaines conditions de distribution des clés dans les données, cela permet d’obtenir un résultat raisonnablement précis tout en utilisant moins de ressources.

​

Algorithme de jointure adaptatif

ClickHouse choisit de manière adaptative la façon d’exécuter des JOIN entre plusieurs tables, en privilégiant le hash join et en basculant vers le merge join lorsqu’il y a plusieurs grandes tables.

​

Prise en charge de la réplication et de l’intégrité des données

ClickHouse utilise une réplication multimaître asynchrone. Une fois les données écrites sur une réplique disponible, toutes les autres répliques récupèrent leur copie en arrière-plan. Le système maintient des données identiques sur les différentes répliques. La reprise après la plupart des pannes s’effectue automatiquement, ou semi-automatiquement dans les cas complexes.

Pour plus d’informations, consultez la section Réplication des données.

​

Contrôle d’accès basé sur les rôles

ClickHouse assure la gestion des comptes utilisateurs au moyen de requêtes SQL et prend en charge une configuration du contrôle d’accès basé sur les rôles similaire à celle que l’on trouve dans la norme ANSI SQL et dans les systèmes de gestion de bases de données relationnelles les plus répandus.

​

Fonctionnalités pouvant être considérées comme des inconvénients

1. Pas de véritables transactions.
2. Impossible de modifier ou de supprimer des données déjà insérées à haut débit et avec une faible latence. Des suppressions et des mises à jour par lots sont disponibles pour nettoyer ou modifier les données, par exemple pour se conformer au RGPD.
3. L’index sparse rend ClickHouse moins efficace pour les requêtes ponctuelles récupérant des lignes individuelles à partir de leurs clés.