est un système de gestion de base de données en colonnes open source pour le traitement des requêtes analytiques en ligne (OLAP) créé par Yandex. Il est utilisé par Yandex, CloudFlare, VK.com, Badoo et d'autres services dans le monde pour stocker de très grandes quantités de données (insertion de milliers de lignes par seconde ou pétaoctets de données stockées sur disque).
Dans un SGBD normal à « chaîne », dont des exemples sont MySQL, Postgres, MS SQL Server, les données sont stockées dans cet ordre :
Dans ce cas, les valeurs liées à une ligne sont physiquement stockées côte à côte. Dans le SGBD en colonnes, les valeurs de différentes colonnes sont stockées séparément et les données d'une colonne sont stockées ensemble :
Des exemples de SGBD en colonnes sont Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
L'entreprise est un transitaire de courrier a commencé à utiliser Clickhouse en 2018 pour la création de rapports et a été très impressionné par sa simplicité, son évolutivité, sa prise en charge SQL et sa rapidité. La vitesse de ce SGBD frôlait la magie.
Facilité
Clickhouse s'installe sur Ubuntu avec une seule commande. Si vous connaissez SQL, vous pouvez immédiatement commencer à utiliser Clickhouse pour vos besoins. Cependant, cela ne signifie pas que vous pouvez « afficher la table de création » dans MySQL et copier-coller SQL dans Clickhouse.
Par rapport à MySQL, il existe des différences importantes entre les types de données dans les définitions de schéma de table de ce SGBD, vous avez donc encore besoin de temps pour modifier les définitions de schéma de table et apprendre les moteurs de table pour vous familiariser.
Clickhouse fonctionne très bien sans aucun logiciel supplémentaire, mais si vous souhaitez utiliser la réplication, vous devrez installer ZooKeeper. L'analyse des performances des requêtes montre d'excellents résultats : les tables système contiennent toutes les informations et toutes les données peuvent être obtenues à l'aide d'un SQL ancien et ennuyeux.
Performance
- Comparaisons Clickhouse avec Vertica et MySQL sur le serveur de configuration : deux sockets CPU Intel® Xeon® E5-2650 v2 à 2.60 GHz ; 128 Go de RAM ; md RAID-5 sur 8 disques durs SATA de 6 To, ext4.
- comparaison de Clickhouse avec le stockage cloud Amazon RedShift.
- Extraits de blog :
La base de données ClickHouse a une conception très simple : tous les nœuds du cluster ont les mêmes fonctionnalités et utilisent uniquement ZooKeeper pour la coordination. Nous avons construit un petit cluster de plusieurs nœuds et effectué des tests au cours desquels nous avons constaté que le système avait des performances assez impressionnantes, ce qui correspond aux avantages revendiqués dans les benchmarks analytiques des SGBD. Nous avons décidé d'examiner de plus près le concept derrière ClickHouse. Le premier obstacle à la recherche était le manque d’outils et la petite communauté de ClickHouse, nous nous sommes donc plongés dans la conception de ce SGBD pour comprendre son fonctionnement.
ClickHouse ne prend pas en charge la réception de données directement depuis Kafka, car il s'agit simplement d'une base de données. Nous avons donc écrit notre propre service d'adaptateur dans Go. Il a lu les messages codés Cap'n Proto de Kafka, les a convertis en TSV et les a insérés dans ClickHouse par lots via l'interface HTTP. Nous avons ensuite réécrit ce service pour utiliser la bibliothèque Go en conjonction avec notre propre interface ClickHouse afin d'améliorer les performances. Lors de l'évaluation des performances de réception des paquets, nous avons découvert une chose importante : il s'est avéré que pour ClickHouse, ces performances dépendent fortement de la taille du paquet, c'est-à-dire du nombre de lignes insérées en même temps. Pour comprendre pourquoi cela se produit, nous avons étudié comment ClickHouse stocke les données.
Le moteur principal, ou plutôt une famille de moteurs de table utilisée par ClickHouse pour stocker des données, est MergeTree. Ce moteur est conceptuellement similaire à l'algorithme LSM utilisé dans Google BigTable ou Apache Cassandra, mais évite de créer une table mémoire intermédiaire et écrit les données directement sur le disque. Cela lui confère un excellent débit d'écriture, car chaque paquet inséré est uniquement trié par la clé primaire « clé primaire », compressé et écrit sur le disque pour former un segment.
L'absence de table mémoire ou de toute notion de « fraîcheur » des données signifie également qu'elles peuvent uniquement être ajoutées ; le système ne prend pas en charge la modification ou la suppression. Actuellement, la seule façon de supprimer des données est de les supprimer par mois civil, car les segments ne dépassent jamais la limite d'un mois. L'équipe ClickHouse travaille activement pour rendre cette fonctionnalité personnalisable. D'un autre côté, cela permet d'écrire et de fusionner les segments sans conflit, donc le débit de réception évolue linéairement avec le nombre d'insertions simultanées jusqu'à ce que les E/S ou la saturation du cœur se produisent.
Cependant, cette circonstance signifie également que le système n'est pas adapté aux petits paquets, c'est pourquoi les services et les inséreurs Kafka sont utilisés pour la mise en mémoire tampon. De plus, ClickHouse en arrière-plan continue de fusionner continuellement les segments, de sorte que de nombreux petits éléments d'information soient combinés et enregistrés plusieurs fois, augmentant ainsi l'intensité de l'enregistrement. Cependant, un trop grand nombre de pièces non liées entraîneront une limitation agressive des insertions tant que la fusion se poursuit. Nous avons constaté que le meilleur compromis entre l'ingestion de données en temps réel et les performances d'ingestion consiste à accepter un nombre limité d'insertions par seconde dans la table.
La clé des performances de lecture des tables réside dans l’indexation et l’emplacement des données sur le disque. Quelle que soit la rapidité du traitement, lorsque le moteur doit analyser des téraoctets de données à partir du disque et n'en utiliser qu'une fraction, cela prendra du temps. ClickHouse est un magasin de colonnes, donc chaque segment contient un fichier pour chaque colonne (colonne) avec des valeurs triées pour chaque ligne. Ainsi, des colonnes entières non présentes dans la requête peuvent d'abord être ignorées, puis plusieurs cellules peuvent être traitées en parallèle avec une exécution vectorisée. Pour éviter une analyse complète, chaque segment possède un petit fichier d'index.
Etant donné que toutes les colonnes sont triées par la "clé primaire", le fichier d'index ne contient que les étiquettes (lignes capturées) de chaque Nième ligne, afin de pouvoir les conserver en mémoire même pour de très grandes tables. Par exemple, vous pouvez définir les paramètres par défaut sur « marquer toutes les 8192 1 lignes », puis une indexation « maigre » d'une table avec 122 070 milliards. les lignes qui tiennent facilement en mémoire ne prendraient que XNUMX XNUMX caractères.
Développement de système
Le développement et l'amélioration de Clickhouse peuvent être retracés sur et assurez-vous que le processus de « grandir » se déroule à un rythme impressionnant.
Popularité
Il semble que la popularité de Clickhouse augmente de façon exponentielle, notamment au sein de la communauté russophone. La conférence High Load 2018 de l'année dernière (Moscou, 8 et 9 novembre 2018) a montré que des monstres comme vk.com et Badoo utilisent Clickhouse, qui insère simultanément des données (par exemple des journaux) provenant de dizaines de milliers de serveurs. Dans une vidéo de 40 minutes . Bientôt, nous publierons la transcription sur Habr pour faciliter le travail avec le matériel.
Applications
Après avoir passé du temps à faire des recherches, je pense qu'il existe des domaines dans lesquels ClickHouse peut être utile ou capable de remplacer complètement d'autres solutions plus traditionnelles et populaires telles que MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot et Druide. Voici les détails de l'utilisation de ClickHouse pour mettre à niveau ou remplacer complètement le SGBD ci-dessus.
Extension de MySQL et PostgreSQL
Plus récemment, nous avons partiellement remplacé MySQL par ClickHouse pour la plateforme de newsletter . Le problème était que MySQL, en raison d'une conception mal conçue, enregistrait chaque e-mail envoyé et chaque lien contenu dans cet e-mail avec un hachage base64, créant ainsi une énorme table MySQL (email_stats). Après avoir envoyé seulement 10 millions d'e-mails aux abonnés du service, cette table occupait 150 Go d'espace fichier, et MySQL a commencé à être « stupide » sur de simples requêtes. Pour résoudre le problème d'espace fichier, nous avons utilisé avec succès la compression de table InnoDB, ce qui l'a réduit d'un facteur 4. Cependant, cela n'a toujours pas de sens de stocker plus de 20 à 30 millions d'e-mails dans MySQL uniquement pour le plaisir de lire l'historique, car toute requête simple qui, pour une raison quelconque, doit effectuer une analyse complète entraîne des échanges et des E/S lourdes. frais généraux, à propos desquels nous recevions régulièrement des avertissements Zabbix.
Clickhouse utilise deux algorithmes de compression qui réduisent la quantité de données d'environ , mais dans ce cas particulier, les données étaient surtout « compressibles ».
Remplacement de l'ELK
D'après ma propre expérience, la pile ELK (ElasticSearch, Logstash et Kibana, dans ce cas particulier ElasticSearch) nécessite beaucoup plus de ressources pour fonctionner que nécessaire pour stocker les journaux. ElasticSearch est un excellent moteur si vous souhaitez une bonne recherche de journaux en texte intégral (dont je ne pense pas que vous ayez vraiment besoin), mais je me demande pourquoi il est devenu le moteur de journalisation standard de facto. Ses performances d'ingestion, combinées à Logstash, nous ont posé des problèmes même avec des charges de travail assez légères et ont nécessité l'ajout de plus en plus de RAM et d'espace disque. En tant que base de données, Clickhouse est meilleur qu'ElasticSearch pour les raisons suivantes :
- Prise en charge du dialecte SQL ;
- Le meilleur degré de compression des données stockées ;
- Prise en charge de la recherche Regex au lieu de la recherche en texte intégral ;
- Planification des requêtes améliorée et performances globales plus élevées.
Actuellement, le plus gros problème qui se pose lorsque l'on compare ClickHouse avec ELK est le manque de solutions pour télécharger les journaux, ainsi que le manque de documentation et de didacticiels sur le sujet. De plus, chaque utilisateur peut configurer ELK à l'aide du manuel Digital Ocean, ce qui est très important pour la mise en œuvre rapide de telles technologies. Il existe un moteur de base de données, mais il n'y a pas encore de Filebeat pour ClickHouse. Oui il y a et un système pour travailler avec des journaux , il existe un outil pour saisir les données du fichier journal dans ClickHouse, mais tout cela prend plus de temps. Cependant, ClickHouse ouvre toujours la voie en raison de sa simplicité, de sorte que même les débutants peuvent facilement l'installer et commencer à l'utiliser pleinement en seulement 10 minutes.
Préférant les solutions minimalistes, j'ai essayé d'utiliser FluentBit, un outil de téléchargement de journaux à très faible mémoire, avec ClickHouse tout en essayant d'éviter d'utiliser Kafka. Cependant, des incompatibilités mineures doivent être corrigées, telles que avant que cela puisse être fait sans la couche proxy qui convertit les données de FluentBit en ClickHouse.
Comme alternative à Kibana, vous pouvez utiliser ClickHouse comme backend . D'après ce que je comprends, cela peut entraîner des problèmes de performances lors du rendu d'un grand nombre de points de données, en particulier avec les anciennes versions de Grafana. Chez Qwintry, nous n'avons pas encore essayé cela, mais des plaintes à ce sujet apparaissent de temps en temps sur le canal d'assistance ClickHouse dans Telegram.
Remplacement de Google Big Query et Amazon RedShift (solution pour les grandes entreprises)
Le cas d'utilisation idéal de BigQuery consiste à charger 1 To de données JSON et à y exécuter des requêtes analytiques. Big Query est un excellent produit dont l'évolutivité est difficile à surestimer. Il s'agit d'un logiciel beaucoup plus complexe que ClickHouse fonctionnant sur un cluster interne, mais du point de vue du client, il a beaucoup en commun avec ClickHouse. BigQuery peut rapidement « augmenter le prix » une fois que vous commencez à payer pour chaque SELECT. Il s'agit donc d'une véritable solution SaaS avec tous ses avantages et inconvénients.
ClickHouse est le meilleur choix lorsque vous exécutez de nombreuses requêtes coûteuses en termes de calcul. Plus vous exécutez de requêtes SELECT chaque jour, plus il est logique de remplacer Big Query par ClickHouse, car un tel remplacement peut vous faire économiser des milliers de dollars lorsqu'il s'agit de traiter plusieurs téraoctets de données. Cela ne s'applique pas aux données stockées, qui sont relativement peu coûteuses à traiter dans Big Query.
Dans un article d'Alexander Zaitsev, co-fondateur d'Altinity parle des avantages d'une telle migration de SGBD.
Remplacement de TimescaleDB
TimescaleDB est une extension PostgreSQL qui optimise le travail avec des séries temporelles dans une base de données standard (, ).
Bien que ClickHouse ne soit pas un concurrent sérieux dans le créneau des séries chronologiques, mais en termes de structure en colonnes et d'exécution de requêtes vectorielles, il est beaucoup plus rapide que TimescaleDB dans la plupart des cas de traitement de requêtes analytiques. Dans le même temps, les performances de réception des données par paquets ClickHouse sont environ 3 fois supérieures, de plus, elles utilisent 20 fois moins d'espace disque, ce qui est vraiment important pour traiter de gros volumes de données historiques : .
Contrairement à ClickHouse, le seul moyen d'économiser de l'espace disque dans TimescaleDB est d'utiliser ZFS ou des systèmes de fichiers similaires.
Les prochaines mises à jour de ClickHouse introduiront probablement la compression delta, ce qui le rendra encore plus adapté au traitement et au stockage de données de séries chronologiques. TimescaleDB peut être un meilleur choix que ClickHouse nu dans les cas suivants :
- petites installations avec très peu de RAM (<3 Go) ;
- un grand nombre de petits INSERT que vous ne souhaitez pas mettre en mémoire tampon en gros fragments ;
- une meilleure cohérence, uniformité et exigences ACID ;
- Prise en charge de PostGIS ;
- fusionner avec les tables PostgreSQL existantes, puisque Timescale DB est essentiellement PostgreSQL.
Concurrence avec les systèmes Hadoop et MapReduce
Hadoop et d'autres produits MapReduce peuvent effectuer de nombreux calculs complexes, mais ils ont tendance à s'exécuter avec une latence énorme. ClickHouse résout ce problème en traitant des téraoctets de données et en produisant des résultats presque instantanément. Ainsi, ClickHouse est beaucoup plus efficace pour effectuer des recherches analytiques rapides et interactives, ce qui devrait intéresser les data scientists.
Concurrence avec le Pinot et le Druide
Les concurrents les plus proches de ClickHouse sont les produits open source en colonnes et évolutifs linéairement Pinot et Druid. Un excellent travail comparant ces systèmes est publié dans l'article 1 Février 2018
Cet article doit être mis à jour - il indique que ClickHouse ne prend pas en charge les opérations UPDATE et DELETE, ce qui n'est pas entièrement vrai pour les dernières versions.
Nous n'avons pas beaucoup d'expérience avec ces SGBD, mais je n'aime pas la complexité de l'infrastructure sous-jacente requise pour exécuter Druid et Pinot - c'est tout un tas de "pièces mobiles" entourées de Java de tous côtés.
Druid et Pinot sont des projets d'incubateur Apache, qui sont traités en détail par Apache sur leurs pages de projets GitHub. Pinot est apparu dans l'incubateur en octobre 2018 et Druid est né 8 mois plus tôt, en février.
Le manque d’informations sur le fonctionnement d’AFS me soulève des questions, peut-être stupides. Je me demande si les auteurs de Pinot ont remarqué que la Fondation Apache est plus disposée envers Druid, et une telle attitude envers un concurrent a-t-elle suscité un sentiment d'envie ? Le développement du Druide va-t-il ralentir et celui du Pinot s'accélérer si les sponsors soutenant le premier s'intéressent soudainement au second ?
Inconvénients de ClickHouse
Immaturité : Évidemment, ce n'est toujours pas une technologie ennuyeuse, mais en tout cas, rien de tel n'est observé dans d'autres SGBD en colonnes.
Les petites insertions ne fonctionnent pas bien à grande vitesse : les insertions doivent être divisées en gros morceaux car les performances des petites insertions se dégradent proportionnellement au nombre de colonnes dans chaque ligne. C'est ainsi que ClickHouse stocke les données sur le disque - chaque colonne signifie 1 fichier ou plus, donc pour insérer 1 ligne contenant 100 colonnes, vous devez ouvrir et écrire au moins 100 fichiers. C'est pourquoi la mise en mémoire tampon d'insertion nécessite un intermédiaire (sauf si le client lui-même fournit la mise en mémoire tampon) - généralement Kafka ou une sorte de système de file d'attente. Vous pouvez également utiliser le moteur de table Buffer pour copier ultérieurement de gros morceaux de données dans des tables MergeTree.
Les jointures de tables sont limitées par la RAM du serveur, mais au moins elles sont là ! Par exemple, Druid et Pinot ne disposent pas du tout de telles connexions, car elles sont difficiles à mettre en œuvre directement dans des systèmes distribués qui ne prennent pas en charge le déplacement de gros morceaux de données entre nœuds.
résultats
Dans les années à venir, nous prévoyons d'utiliser largement ClickHouse dans Qwintry, car ce SGBD offre un excellent équilibre entre performances, faible surcharge, évolutivité et simplicité. Je suis presque sûr qu'il se propagera rapidement une fois que la communauté ClickHouse aura trouvé davantage de façons de l'utiliser dans les petites et moyennes installations.
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com