ClickHouse étant un système spécialisé, il est important de prendre en compte les particularités de son architecture lors de son utilisation. Dans ce rapport, Alexey parlera d'exemples d'erreurs typiques lors de l'utilisation de ClickHouse, qui peuvent conduire à un travail inefficace. À l'aide d'exemples pratiques, nous montrerons comment le choix de l'un ou l'autre schéma de traitement des données peut modifier les performances de plusieurs ordres de grandeur.
Salut tout le monde! Je m'appelle Alexey, je crée ClickHouse.
Tout d'abord, je m'empresse de vous faire plaisir tout de suite, je ne vous dirai pas aujourd'hui ce qu'est ClickHouse. Pour être honnête, j'en ai marre. Je vous dis à chaque fois ce que c'est. Et probablement que tout le monde le sait déjà.
Au lieu de cela, je vais vous dire quel est le râteau possible, c'est-à-dire comment ClickHouse peut être utilisé à mauvais escient. En fait, vous ne devriez pas avoir peur, car nous développons ClickHouse comme un système simple, pratique et prêt à l'emploi. Tout installé, pas de problème.
Mais encore faut-il garder à l'esprit que ce système est spécialisé et vous pouvez facilement tomber sur un cas d'utilisation inhabituel qui sortira ce système de sa zone de confort.
Alors, quels sont les râteaux? Fondamentalement, je vais parler des choses évidentes. Tout est évident pour tout le monde, tout le monde comprend tout et peut être heureux d'être si intelligent, et ceux qui ne comprennent pas apprendront quelque chose de nouveau.
Le premier exemple le plus simple, qui se produit malheureusement souvent, est un grand nombre d'inserts avec de petits lots, c'est-à-dire un grand nombre de petits inserts.
Si nous considérons comment ClickHouse effectue une insertion, vous pouvez envoyer au moins un téraoctet de données en une seule requête. Ce n'est pas un problème.
Et voyons quelles seront les performances typiques. Par exemple, nous avons une table avec des données Yandex.Metrica. Les coups. 105 quelques colonnes. 700 octets non compressés. Et nous insèrerons dans le bon sens des lots d'un million de lignes.
Nous insérons dans la table MergeTree, un demi-million de lignes par seconde sont obtenues. Super. Dans une table répliquée, ce sera un peu moins, environ 400 000 lignes par seconde.
Et si vous activez l'insert de quorum, vous obtenez un peu moins, mais toujours des performances décentes, 250 000 fois par seconde. L'insertion de quorum est une fonctionnalité non documentée dans ClickHouse*.
* à partir de 2020, .
Que se passe-t-il si vous le faites mal ? Nous insérons une ligne dans la table MergeTree et nous obtenons 59 lignes par seconde. C'est 10 000 fois lent. Dans ReplicatedMergeTree - 6 lignes par seconde. Et si le quorum s'active, alors 2 lignes par seconde sont obtenues. À mon avis, c'est une sorte de merde totale. Comment peux-tu ralentir comme ça ? Il est même dit sur mon T-shirt que ClickHouse ne doit pas ralentir. Mais néanmoins cela arrive parfois.
En fait, c'est notre défaut. Nous aurions pu le faire fonctionner très bien, mais nous ne l'avons pas fait. Et nous ne l'avons pas fait, car notre script n'en avait pas besoin. Nous avions déjà des lots. Nous venons de recevoir des lots à l'entrée, et aucun problème. Branchez-le et tout fonctionne bien. Mais, bien sûr, toutes sortes de scénarios sont possibles. Par exemple, lorsque vous avez un tas de serveurs sur lesquels des données sont générées. Et ils n'insèrent pas de données aussi souvent, mais ils reçoivent toujours des insertions fréquentes. Et vous devez en quelque sorte éviter cela.
D'un point de vue technique, l'essentiel est que lorsque vous effectuez une insertion dans ClickHouse, les données n'entrent dans aucune memtable. Nous n'avons même pas une véritable structure de journal MergeTree, mais juste un MergeTree, car il n'y a ni log ni memTable. Nous écrivons juste immédiatement les données dans le système de fichiers, déjà décomposées en colonnes. Et si vous avez 100 colonnes, plus de 200 fichiers devront être écrits dans un répertoire séparé. Tout cela est très encombrant.
Et la question se pose: "Comment bien faire les choses?" Dans une telle situation, vous devez toujours en quelque sorte écrire des données sur ClickHouse.
Méthode 1. C'est la méthode la plus simple. Utilisez une sorte de file d'attente distribuée. Par exemple, Kafka. Vous venez de retirer des données de Kafka, nous les regroupons une fois par seconde. Et tout ira bien, vous enregistrez, tout fonctionne bien.
Les inconvénients sont que Kafka est un autre système distribué encombrant. Je comprends aussi si vous avez déjà Kafka dans votre entreprise. C'est bien, c'est pratique. Mais s'il ne s'y trouve pas, réfléchissez-y à trois fois avant d'intégrer un autre système distribué dans votre projet. Et il vaut donc la peine d'envisager des alternatives.
Méthode 2. Voici une alternative à l'ancienne et en même temps très simple. Avez-vous une sorte de serveur qui génère vos journaux. Et il écrit simplement vos journaux dans un fichier. Et une fois par seconde, par exemple, on renomme ce fichier, on en ouvre un nouveau. Et un script séparé, soit par cron, soit par un démon, prend le fichier le plus ancien et l'écrit dans ClickHouse. Si vous écrivez des journaux une fois par seconde, tout ira bien.
Mais l'inconvénient de cette méthode est que si votre serveur sur lequel les journaux sont générés a disparu quelque part, alors les données disparaîtront également.
Méthode 3. Il existe une autre méthode intéressante, sans aucun fichier temporaire. Par exemple, vous avez une sorte de spinner publicitaire ou un autre démon intéressant qui génère des données. Et vous pouvez accumuler un tas de données directement dans la RAM, dans la mémoire tampon. Et lorsqu'un laps de temps suffisant s'est écoulé, vous mettez ce tampon de côté, en créez un nouveau et insérez ce qui s'est déjà accumulé dans ClickHouse dans un fil séparé.
D'autre part, les données disparaissent également avec kill -9. Si votre serveur tombe en panne, vous perdrez ces données. Et un autre problème est que si vous ne pouvez pas écrire dans la base de données, vos données s'accumuleront dans la RAM. Et soit la RAM est épuisée, soit vous perdez simplement des données.
Méthode 4. Une autre façon intéressante. Avez-vous un processus serveur. Et il peut envoyer des données à ClickHouse à la fois, mais le faire en une seule connexion. Par exemple, j'ai envoyé une requête http avec transfer-encoding: chunked with insert. Et il génère des morceaux pas trop rarement, vous pouvez envoyer chaque ligne, bien qu'il y ait une surcharge pour encadrer ces données.
Cependant, dans ce cas, les données seront immédiatement envoyées à ClickHouse. Et ClickHouse lui-même les mettra en mémoire tampon.
Mais il y a aussi des problèmes. Maintenant, vous perdrez des données, y compris lorsque votre processus est tué et si le processus ClickHouse est tué, car il s'agira d'une insertion incomplète. Et dans ClickHouse, les inserts sont atomiques jusqu'à un certain seuil spécifié dans la taille des lignes. En principe, c'est une voie intéressante. Peut également être utilisé.
Méthode 5. Voici une autre méthode intéressante. Il s'agit d'une sorte de serveur développé par la communauté pour le traitement par lots de données. Je ne l'ai pas regardé moi-même, donc je ne peux rien garantir. Cependant, il n'y a aucune garantie pour ClickHouse lui-même. C'est également open source, mais d'un autre côté, vous pourriez vous habituer à certaines normes de qualité que nous essayons de fournir. Mais pour cette chose - je ne sais pas, allez sur GitHub, regardez le code. Peut-être qu'ils ont écrit quelque chose de bien.
*à partir de 2020, devrait également être ajouté à la considération .
Méthode 6. Une autre méthode consiste à utiliser les tables Buffer. L'avantage de cette méthode est qu'elle est très facile à utiliser. Créez une table Buffer et insérez-la dedans.
Mais l'inconvénient est que le problème n'est pas complètement résolu. Si à un taux de type MergeTree vous devez regrouper les données par un lot par seconde, alors à un taux dans une table tampon, vous devez regrouper au moins jusqu'à plusieurs milliers par seconde. S'il y en a plus de 10 000 par seconde, ce sera toujours mauvais. Et si vous insérez par lots, alors vous avez vu que cent mille lignes par seconde y sont obtenues. Et c'est déjà sur des données assez lourdes.
De plus, les tables tampons n'ont pas de journal. Et si quelque chose ne va pas avec votre serveur, les données seront perdues.
Et en prime, nous avons récemment eu l'opportunité de collecter des données de Kafka dans ClickHouse. Il existe un moteur de table - Kafka. Vous créez simplement. Et vous pouvez y accrocher des vues matérialisées. Dans ce cas, il sortira les données de Kafka et les insèrera dans les tables dont vous avez besoin.
Et ce qui est particulièrement réjouissant dans cette opportunité, c'est que nous ne l'avons pas fait. Il s'agit d'une fonctionnalité communautaire. Et quand je dis "fonctionnalité communautaire", je le dis sans aucun mépris. Nous avons lu le code, fait une révision, ça devrait bien fonctionner.
* à partir de 2020, il existe un support similaire pour .
Quoi d'autre peut être gênant ou inattendu lors de l'insertion de données ? Si vous faites une requête d'insertion de valeurs et écrivez des expressions calculées dans values. Par exemple, now() est également une expression évaluée. Et dans ce cas, ClickHouse est obligé de lancer l'interpréteur de ces expressions pour chaque ligne, et les performances chuteront par ordre de grandeur. Mieux vaut l'éviter.
* pour le moment, le problème est complètement résolu, il n'y a plus de régression des performances lors de l'utilisation d'expressions dans VALUES.
Un autre exemple où il peut y avoir des problèmes est lorsque vos données sur un lot appartiennent à un groupe de partitions. Par défaut, ClickHouse partitionne par mois. Et si vous insérez un lot d'un million de lignes et qu'il y a des données pendant plusieurs années, vous aurez alors plusieurs dizaines de partitions. Et cela équivaut au fait qu'il y aura des lots plusieurs dizaines de fois plus petits, car à l'intérieur ils sont toujours d'abord divisés en partitions.
* Récemment, dans ClickHouse en mode expérimental, la prise en charge du format compact de morceaux et de morceaux dans la RAM avec journal à écriture anticipée a été ajoutée, ce qui résout presque complètement le problème.
Considérons maintenant le deuxième type de problème - le typage des données.
Le typage des données peut être strict et parfois une chaîne. Chaîne - c'est lorsque vous venez de prendre et de déclarer que vous avez tous les champs de type chaîne. C'est nul. Vous n'avez pas à le faire.
Voyons comment le faire correctement dans les cas où vous voulez dire que nous avons un champ, une chaîne, et laissons ClickHouse le comprendre tout seul, mais je ne prendrai pas de bain de vapeur. Mais cela vaut quand même la peine de faire des efforts.
Par exemple, nous avons une adresse IP. Dans un cas, nous l'avons enregistré sous forme de chaîne. Par exemple, 192.168.1.1. Sinon, ce sera un nombre de type UInt32*. 32 bits suffisent pour une adresse IPv4.
Tout d'abord, curieusement, les données seront compressées à peu près de la même manière. Il y aura une différence, bien sûr, mais pas si grande. Il n'y a donc pas de problèmes particuliers avec les E/S de disque.
Mais il existe une différence sérieuse entre le temps CPU et le temps d'exécution des requêtes.
Comptons le nombre d'adresses IP uniques si elles sont stockées sous forme de nombres. Il s'avère que 137 millions de lignes par seconde. Si la même chose que les lignes, alors 37 millions de lignes par seconde. Je ne sais pas pourquoi cette coïncidence s'est produite. J'ai fait ces demandes moi-même. Mais néanmoins environ 4 fois plus lent.
Et si vous calculez la différence d'espace disque, il y a aussi une différence. Et la différence est d'environ un quart, car il y a beaucoup d'adresses IP uniques. Et s'il y avait des lignes avec un petit nombre de valeurs différentes, elles auraient été discrètement compressées dans le dictionnaire à peu près dans le même volume.
Et le quadruple décalage horaire n'est pas couché sur la route. Peut-être que vous, bien sûr, ne vous en souciez pas, mais quand je vois une telle différence, je me sens triste.
Considérons différents cas.
1. Un cas où vous avez peu de valeurs uniques différentes. Dans ce cas, nous utilisons une pratique simple que vous connaissez probablement et que vous pouvez utiliser pour n'importe quel SGBD. Tout cela a du sens non seulement pour ClickHouse. Écrivez simplement les identifiants numériques dans la base de données. Et vous pouvez convertir en chaînes et revenir sur le côté de votre application.
Par exemple, vous avez une région. Et vous essayez de l'enregistrer en tant que chaîne. Et il y sera écrit : Moscou et la région de Moscou. Et quand je vois que "Moscou" y est écrit, alors ce n'est toujours rien, et quand c'est MO, ça devient en quelque sorte complètement triste. C'est combien d'octets.
Au lieu de cela, nous écrivons simplement le numéro Ulnt32 et 250. Nous avons 250 dans Yandex, mais le vôtre peut être différent. Juste au cas où, je dirai que ClickHouse a une capacité intégrée à travailler avec une géobase. Vous écrivez simplement un répertoire avec des régions, y compris une hiérarchie, c'est-à-dire qu'il y aura Moscou, la région de Moscou et tout ce dont vous avez besoin. Et vous pouvez convertir au niveau de la demande.
La deuxième option est à peu près la même, mais avec un support à l'intérieur de ClickHouse. C'est un type de données Enum. Vous écrivez simplement toutes les valeurs dont vous avez besoin à l'intérieur de l'énumération. Par exemple, le type d'appareil et écrivez-y : ordinateur de bureau, mobile, tablette, TV. Seulement 4 options.
L'inconvénient est que vous devez modifier périodiquement. Une seule option a été ajoutée. Nous faisons modifier la table. En fait, modifier la table dans ClickHouse est gratuit. Particulièrement gratuit pour Enum car les données sur le disque ne changent pas. Mais néanmoins, alter acquiert un verrou * sur la table et doit attendre que toutes les sélections soient terminées. Et seulement après que cette modification sera exécutée, c'est-à-dire qu'il y a encore quelques inconvénients.
* dans les versions récentes de ClickHouse, ALTER est entièrement non bloquant.
Une autre option tout à fait unique pour ClickHouse est la connexion de dictionnaires externes. Vous pouvez écrire des nombres dans ClickHouse et conserver vos répertoires dans n'importe quel système qui vous convient. Par exemple, vous pouvez utiliser : MySQL, Mongo, Postgres. Vous pouvez même créer votre propre microservice, qui enverra ces données via http. Et au niveau de ClickHouse, vous écrivez une fonction qui convertira ces données de nombres en chaînes.
Il s'agit d'un moyen spécialisé mais très efficace d'effectuer une jointure sur une table externe. Et il y a deux options. Dans une option, ces données seront entièrement mises en cache, entièrement présentes dans la RAM et mises à jour à certains intervalles. Et dans une autre option, si ces données ne rentrent pas dans la RAM, vous pouvez les mettre partiellement en cache.
Voici un exemple. Il y a Yandex.Direct. Et il y a une agence de publicité et des bannières. Il existe probablement des dizaines de millions de sociétés de publicité. Et à peu près tenir dans la RAM. Et il y a des milliards de bannières, elles ne rentrent pas. Et nous utilisons un dictionnaire en cache de MySQL.
Le seul problème est que le dictionnaire en cache fonctionnera correctement si le taux de réussite est proche de 100 %. S'il est plus petit, alors lors du traitement des requêtes pour chaque pack de données, il faudra effectivement prendre les clés manquantes et aller prendre les données de MySQL. À propos de ClickHouse, je peux toujours garantir que - oui, cela ne ralentit pas, je ne parlerai pas d'autres systèmes.
Et en prime, les dictionnaires sont un moyen très simple de mettre à jour rétroactivement les données dans ClickHouse. Autrement dit, vous aviez un rapport sur les agences de publicité, l'utilisateur a simplement changé d'agence de publicité et dans toutes les anciennes données, dans tous les rapports, ces données ont également changé. Si vous écrivez des lignes directement dans la table, vous ne pourrez pas les mettre à jour.
Une autre façon lorsque vous ne savez pas où obtenir les identifiants de vos chaînes. vous pouvez simplement hacher. Et l'option la plus simple consiste à prendre un hachage 64 bits.
Le seul problème est que si le hachage est 64 bits, vous aurez presque certainement des collisions. Parce que s'il y a un milliard de lignes, alors la probabilité devient déjà tangible.
Et ce ne serait pas très bon de hacher les noms des agences de publicité comme ça. Si les campagnes publicitaires de différentes entreprises se mélangent, il y aura quelque chose d'incompréhensible.
Et il y a une astuce simple. Certes, il n'est pas non plus très adapté aux données sérieuses, mais si quelque chose n'est pas très sérieux, ajoutez simplement un autre identifiant client à la clé du dictionnaire. Et puis vous aurez des collisions, mais seulement au sein d'un client. Et nous utilisons cette méthode pour la carte des liens dans Yandex.Metrica. Nous avons des URL là-bas, nous stockons des hachages. Et nous savons qu'il y a des conflits, bien sûr. Mais lorsqu'une page est affichée, alors la probabilité que ce soit sur une page pour un utilisateur que certaines URL collent ensemble et que cela soit remarqué, alors cela peut être négligé.
En prime, pour de nombreuses opérations, seuls les hachages suffisent et les chaînes elles-mêmes ne peuvent être stockées nulle part.
Un autre exemple si les chaînes sont courtes, comme les domaines de sites Web. Ils peuvent être stockés tels quels. Ou, par exemple, la langue du navigateur ru est de 2 octets. Bien sûr, je suis désolé pour les octets, mais ne vous inquiétez pas, 2 octets ne sont pas dommage. Veuillez le garder tel quel, ne vous inquiétez pas.
Un autre cas est celui où, au contraire, il y a beaucoup de chaînes et en même temps il y en a beaucoup de uniques, et même l'ensemble est potentiellement illimité. Un exemple typique est les expressions de recherche ou les URL. Phrases de recherche, y compris en raison de fautes de frappe. Voyons combien de phrases de recherche uniques par jour. Et il s'avère qu'ils représentent près de la moitié de tous les événements. Et dans ce cas, vous pourriez penser que vous devez normaliser les données, compter les identifiants, les mettre dans une table séparée. Mais vous n'êtes pas obligé de le faire. Gardez simplement ces lignes telles quelles.
Mieux - n'inventez rien, car si vous le stockez séparément, vous devrez faire une jointure. Et cette jointure est au mieux un accès aléatoire à la mémoire, si elle tient encore en mémoire. Si cela ne rentre pas, il y aura des problèmes en général.
Et si les données sont stockées sur place, elles sont simplement lues dans le bon ordre à partir du système de fichiers et tout va bien.
Si vous avez des URL ou une autre longue chaîne complexe, vous devriez penser au fait que vous pouvez calculer une compression à l'avance et l'écrire dans une colonne séparée.
Pour les URL, par exemple, vous pouvez stocker le domaine séparément. Et si vous avez vraiment besoin d'un domaine, utilisez simplement cette colonne, et les URL mentiront, et vous ne les toucherez même pas.
Voyons quelle est la différence. ClickHouse a une fonction spécialisée qui calcule le domaine. C'est très rapide, nous l'avons optimisé. Et, pour être honnête, il n'est même pas conforme à la RFC, mais il considère néanmoins tout ce dont nous avons besoin.
Et dans un cas, nous obtiendrons simplement les URL et calculerons le domaine. Il s'avère 166 millisecondes. Et si vous prenez un domaine prêt à l'emploi, il ne s'avère que 67 millisecondes, soit presque trois fois plus vite. Et plus rapide, non pas parce que nous devons faire des calculs, mais parce que nous lisons moins de données.
Pour une raison quelconque, une requête, qui est plus lente, obtient plus de vitesse en gigaoctets par seconde. Parce qu'il lit plus de gigaoctets. Ce sont des données complètement redondantes. La demande semble s'exécuter plus rapidement, mais prend plus de temps à se terminer.
Et si vous regardez la quantité de données sur le disque, il s'avère que l'URL est de 126 mégaoctets et que le domaine n'est que de 5 mégaoctets. Il s'avère 25 fois moins. Cependant, la requête n'est toujours que 4 fois plus rapide. Mais c'est parce que les données sont chaudes. Et s'il faisait froid, ce serait probablement 25 fois plus rapide grâce aux E/S disque.
Soit dit en passant, si vous évaluez à quel point le domaine est inférieur à l'URL, il s'avère être environ 4. Mais pour une raison quelconque, les données sur le disque prennent 25 fois moins. Pourquoi? En raison de la compression. Et l'URL est compressée, et le domaine est compressé. Mais souvent, l'URL contient un tas d'ordures.
Et, bien sûr, cela vaut la peine d'utiliser les bons types de données qui sont spécifiquement conçus pour les bonnes valeurs ou qui correspondent. Si vous êtes en IPv4, stockez UInt32 *. Si IPv6, alors FixedString(16), car une adresse IPv6 est de 128 bits, c'est-à-dire stockée directement au format binaire.
Mais que se passe-t-il si vous avez parfois des adresses IPv4 et parfois IPv6 ? Oui, vous pouvez garder les deux. Une colonne pour IPv4, une autre pour IPv6. Bien sûr, il existe une option pour mapper IPv4 à IPv6. Cela fonctionnera également, mais si vous avez souvent besoin d'une adresse IPv4 dans vos requêtes, ce serait bien de la mettre dans une colonne séparée.
* ClickHouse dispose désormais de types de données IPv4 et IPv6 distincts qui stockent les données aussi efficacement que des nombres, mais les représentent aussi facilement que des chaînes.
Il est également important de noter qu'il vaut la peine de prétraiter les données à l'avance. Par exemple, certaines bûches brutes viennent à vous. Et, peut-être, vous ne devriez pas les mettre tout de suite dans ClickHouse, bien qu'il soit très tentant de ne rien faire et tout fonctionnera. Mais il vaut toujours la peine d'effectuer les calculs possibles.
Par exemple, la version du navigateur. Dans un département voisin, que je ne veux pas pointer du doigt, la version du navigateur y est stockée comme ceci, c'est-à-dire sous forme de chaîne : 12.3. Et puis, pour faire un rapport, ils prennent cette chaîne et la divisent par un tableau, puis par le premier élément du tableau. Naturellement, tout ralentit. J'ai demandé pourquoi ils faisaient ça. Ils m'ont dit qu'ils n'aiment pas l'optimisation prématurée. Et je n'aime pas le pessimisme prématuré.
Donc dans ce cas il serait plus correct de diviser en 4 colonnes. N'ayez pas peur ici, car c'est ClickHouse. ClickHouse est une base de données de colonnes. Et plus les petites colonnes sont soignées, mieux c'est. Il y aura 5 BrowserVersion, faites 5 colonnes. C'est bon.
Considérez maintenant ce qu'il faut faire si vous avez beaucoup de très longues chaînes, de très longs tableaux. Ils n'ont pas du tout besoin d'être stockés dans ClickHouse. Au lieu de cela, vous ne pouvez stocker qu'un identifiant dans ClickHouse. Et ces longues files d'attente les poussent dans un autre système.
Par exemple, l'un de nos services d'analyse a des paramètres d'événement. Et si beaucoup de paramètres viennent aux événements, nous sauvegardons simplement les premiers 512 qui arrivent, parce que 512 n'est pas dommage.
Et si vous ne pouvez pas décider de vos types de données, vous pouvez également écrire des données dans ClickHouse, mais dans une table temporaire de type Log, qui est spéciale pour les données temporaires. Après cela, vous pouvez analyser le type de distribution de valeurs que vous avez là-bas, ce qui s'y trouve généralement et créer les types corrects.
* Maintenant, ClickHouse a un type de données ce qui vous permet de stocker efficacement des chaînes avec moins d'effort.
Considérons maintenant un autre cas intéressant. Parfois, les choses fonctionnent d'une manière étrange pour les gens. Je vais voir ça. Et il semble immédiatement que cela ait été fait par un administrateur très expérimenté et intelligent qui possède une vaste expérience dans la configuration de MySQL version 3.23.
On voit ici mille tables, dont chacune contient le reste de la division on ne sait quoi par mille.
En principe, je respecte l'expérience des autres, y compris la compréhension du type de souffrance que cette expérience peut entraîner.
Et les raisons sont plus ou moins claires. Ce sont de vieux stéréotypes qui peuvent s'être accumulés en travaillant avec d'autres systèmes. Par exemple, les tables MyISAM n'ont pas de clé primaire en cluster. Et cette façon de partager des données peut être une tentative désespérée d'obtenir la même fonctionnalité.
Une autre raison est qu'il est difficile d'effectuer des opérations de modification sur de grandes tables. Tout sera bloqué. Bien que dans les versions modernes de MySQL, ce problème ne soit plus si grave.
Ou, par exemple, le microsharding, mais nous en reparlerons plus tard.
Dans ClickHouse, vous n'avez pas besoin de le faire, car, premièrement, la clé primaire est regroupée, les données sont classées par clé primaire.
Et parfois, les gens me demandent : "Comment les performances des requêtes de plage dans ClickHouse changent-elles avec la taille de la table ?". Je dis que ça ne change pas du tout. Par exemple, vous avez une table avec un milliard de lignes et vous lisez une plage d'un million de lignes. Tout va bien. Si le tableau contient un billion de lignes et que vous lisez un million de lignes, ce sera presque la même chose.
Et, deuxièmement, toutes les pièces comme les partitions manuelles ne sont pas nécessaires. Si vous entrez et regardez ce qui se trouve sur le système de fichiers, vous verrez qu'une table est une chose assez sérieuse. Et là, à l'intérieur, il y a quelque chose comme des cloisons. Autrement dit, ClickHouse fait tout pour vous et vous n'avez pas besoin de souffrir.
Modifier dans ClickHouse est gratuit si vous modifiez la colonne d'ajout/dépose.
Et vous ne devriez pas créer de petits tableaux, car si vous avez 10 lignes ou 10 000 lignes dans votre tableau, cela n'a pas d'importance du tout. ClickHouse est un système qui optimise le débit, pas la latence, donc cela n'a aucun sens de traiter 10 lignes.
Il est correct d'utiliser une grande table. Débarrassez-vous des vieux stéréotypes, tout ira bien.
Et en prime, dans la dernière version, nous avons la possibilité de créer une clé de partitionnement arbitraire afin d'effectuer toutes sortes d'opérations de maintenance sur des partitions individuelles.
Par exemple, vous avez besoin de nombreuses petites tables, par exemple, lorsqu'il est nécessaire de traiter certaines données intermédiaires, vous recevez des blocs et vous devez effectuer une transformation sur eux avant d'écrire dans la table finale. Pour ce cas, il existe un merveilleux moteur de table - StripeLog. C'est comme TinyLog, mais en mieux.
* Maintenant, ClickHouse a plus .
Un autre anti-modèle est le microsharding. Par exemple, vous avez besoin de partitionner des données et vous avez 5 serveurs, et demain il y aura 6 serveurs. Et vous pensez comment rééquilibrer ces données. Et à la place, vous ne vous divisez pas en 5 fragments, mais en 1 000 fragments. Et puis vous mappez chacun de ces microshards sur un serveur séparé. Et vous réussirez sur un serveur, par exemple, 200 ClickHouse, par exemple. Instance distincte sur des ports distincts ou des bases de données distinctes.
Mais dans ClickHouse, ce n'est pas très bon. Parce que même une instance de ClickHouse essaie d'utiliser toutes les ressources disponibles du serveur pour traiter une demande. Autrement dit, vous avez une sorte de serveur et là, par exemple, 56 cœurs de processeur. Vous exécutez une requête qui prend une seconde et qui utilisera 56 cœurs. Et si vous avez placé 200 ClickHouses sur un serveur là-bas, il s'avère que 10 000 threads vont démarrer. En général, tout ira très mal.
Une autre raison est que la répartition du travail entre ces instances sera inégale. Certains finiront plus tôt, d'autres finiront plus tard. Si tout cela se produisait en un seul cas, alors ClickHouse lui-même aurait compris comment répartir correctement les données entre les flux.
Et une autre raison est que vous aurez une communication interprocesseur via TCP. Les données devront être sérialisées, désérialisées, et cela représente un nombre énorme de microshards. Cela ne fonctionnera tout simplement pas.
Un autre anti-modèle, bien qu'on puisse difficilement l'appeler un anti-modèle. Il s'agit d'une grande quantité de pré-agrégation.
En général, la préagrégation est bonne. Vous aviez un milliard de lignes, vous l'avez agrégé et il est devenu 1 000 lignes, et maintenant la requête est exécutée instantanément. Tout est bon. C'est comme ça que vous pouvez le faire. Et pour cela, même ClickHouse a un type de table spécial AggregatingMergeTree qui effectue une agrégation incrémentielle au fur et à mesure que les données sont insérées.
Mais il y a des moments où vous pensez que nous allons agréger des données comme celle-ci et agréger des données comme celle-ci. Et dans certains départements voisins, je ne veux pas dire lequel non plus, ils utilisent des tables SummingMergeTree pour résumer par la clé primaire, et 20 colonnes sont utilisées comme clé primaire. Au cas où, j'ai changé les noms de certaines colonnes pour conspiration, mais c'est à peu près tout.
Et de tels problèmes se posent. Tout d'abord, la quantité de données dont vous disposez n'est pas trop réduite. Par exemple, il est réduit de trois fois. Trois fois serait un bon prix pour s'offrir les analyses illimitées qui accompagnent les données non agrégées. Si les données sont agrégées, vous n'obtenez que des statistiques misérables au lieu d'analyses.
Et qu'est-ce qui est particulièrement bon ? Que ces gens du département suivant, aillent demander parfois d'ajouter une colonne de plus à la clé primaire. Autrement dit, nous avons agrégé les données comme ceci, et maintenant nous en voulons un peu plus. Mais il n'y a pas de clé primaire alternée dans ClickHouse. Par conséquent, vous devez écrire des scripts en C ++. Et je n'aime pas les scripts, même s'ils sont en C++.
Et si vous regardez pour quoi ClickHouse a été créé, alors les données non agrégées sont exactement le scénario pour lequel elles sont nées. Si vous utilisez ClickHouse pour des données non agrégées, vous faites tout correctement. Si vous regroupez, cela est parfois pardonnable.
Un autre cas intéressant est celui des requêtes dans une boucle infinie. Je vais parfois sur un serveur de production et je regarde show processlist là-bas. Et à chaque fois je découvre qu'il se passe quelque chose de terrible.
Par exemple, voici ceci. Il est immédiatement clair qu'il était possible de tout faire en une seule demande. Écrivez simplement l'URL et la liste là-bas.
Pourquoi de nombreuses requêtes de ce type dans une boucle infinie sont-elles mauvaises ? Si l'index n'est pas utilisé, vous aurez plusieurs passages sur les mêmes données. Mais si un index est utilisé, par exemple, vous avez une clé primaire sur ru et vous y écrivez url = quelque chose. Et vous pensez qu'une URL sera lue ponctuellement à partir du tableau, tout ira bien. Mais vraiment non. Parce que ClickHouse fait tout par lots.
Lorsqu'il a besoin de lire une plage de données, il lit un peu plus, car l'index dans ClickHouse est clairsemé. Cet index ne vous permet pas de trouver une ligne individuelle dans la table, seulement une sorte de plage. Et les données sont compressées en blocs. Pour lire une ligne, vous devez prendre tout le bloc et le décompresser. Et si vous exécutez un tas de requêtes, vous aurez beaucoup d'intersections de celles-ci, et vous aurez beaucoup de travail à faire encore et encore.
Et en prime, vous pouvez voir que dans ClickHouse, vous ne devriez pas avoir peur de transférer même des mégaoctets et même des centaines de mégaoctets vers la section IN. Je me souviens de notre pratique que si nous passons un tas de valeurs dans la section IN de MySQL, par exemple, nous y passons 100 mégaoctets de certains nombres, puis MySQL consomme 10 gigaoctets de mémoire et rien d'autre ne lui arrive, tout fonctionne mal.
Et la deuxième chose est que dans ClickHouse, si vos requêtes utilisent un index, alors ce n'est toujours pas plus lent qu'une analyse complète, c'est-à-dire que si vous avez besoin de lire presque toute la table, elle ira séquentiellement et lira toute la table. En général, il comprendra.
Cependant, il y a quelques difficultés. Par exemple, ce IN avec une sous-requête n'utilise pas l'index. Mais c'est notre problème et nous devons le résoudre. Il n'y a là rien de fondamental. Faisons-le*.
Et une autre chose intéressante est que si vous avez une très longue requête et que le traitement des requêtes distribuées est en cours, alors cette très longue requête sera envoyée à chaque serveur sans compression. Par exemple, 100 mégaoctets et 500 serveurs. Et, en conséquence, 50 gigaoctets seront transférés sur le réseau. Il sera transféré et ensuite tout sera exécuté avec succès.
* utilise déjà ; tout a été réparé comme promis.
Et c'est assez courant si les requêtes proviennent de l'API. Par exemple, vous avez rendu une sorte de service. Et si quelqu'un a besoin de votre service, alors vous ouvrez l'API et littéralement deux jours plus tard, vous voyez que quelque chose d'incompréhensible se passe. Tout est surchargé et de terribles demandes arrivent qui n'auraient jamais dû arriver.
Et il n'y a qu'une solution. Si vous avez ouvert l'API, vous devrez la couper. Par exemple, pour entrer des quotas. Il n'y a pas d'autres options raisonnables. Sinon, ils écriront immédiatement un script et il y aura des problèmes.
Et ClickHouse a une particularité - c'est le calcul des quotas. De plus, vous pouvez transférer votre clé de quota. Il s'agit, par exemple, d'un ID utilisateur interne. Et les quotas seront calculés indépendamment pour chacun d'eux.
Maintenant une autre chose intéressante. Il s'agit d'une réplication manuelle.
Je connais de nombreux cas où, bien que ClickHouse ait un support de réplication intégré, les gens répliquent ClickHouse manuellement.
C'est quoi le principe ? Vous avez un pipeline de traitement de données. Et cela fonctionne indépendamment, par exemple, dans différents centres de données. Vous écrivez les mêmes données de la même manière dans ClickHouse, pour ainsi dire. Certes, la pratique montre que les données divergeront toujours en raison de certaines particularités de votre code. J'espère que dans le vôtre.
Et périodiquement, vous devez toujours synchroniser manuellement. Par exemple, une fois par mois, les administrateurs effectuent rsync.
En fait, il est beaucoup plus facile d'utiliser la réplication intégrée dans ClickHouse. Mais il peut y avoir des contre-indications, car pour cela, vous devez utiliser ZooKeeper. Je ne dirai rien de mal à propos de ZooKeeper, en principe, le système fonctionne, mais il arrive que les gens ne l'utilisent pas à cause de la phobie de Java, car ClickHouse est un si bon système écrit en C ++ que vous pouvez utiliser et tout ira bien. Et ZooKeeper en Java. Et d'une manière ou d'une autre, vous ne voulez même pas regarder, mais vous pouvez ensuite utiliser la réplication manuelle.
ClickHouse est un système pratique. Il tient compte de vos besoins. Si vous avez une réplication manuelle, vous pouvez créer une table distribuée qui examine vos répliques manuelles et effectue un basculement entre elles. Et il y a même une option spéciale qui permet d'éviter les flops, même si vos lignes sont systématiquement divergentes.
De plus, il peut y avoir des problèmes si vous utilisez des moteurs de table primitifs. ClickHouse est un tel constructeur qui a un tas de moteurs de table différents. Pour tous les cas graves, comme écrit dans la documentation, utilisez les tables de la famille MergeTree. Et tout le reste - c'est ainsi, pour des cas individuels ou pour des tests.
Dans une table MergeTree, vous n'avez pas besoin d'avoir de date et d'heure. Vous pouvez toujours utiliser. S'il n'y a pas de date et d'heure, écrivez que la valeur par défaut est 2000. Cela fonctionnera et ne nécessitera pas de ressources.
Et dans la nouvelle version du serveur, vous pouvez même spécifier que vous avez un partitionnement personnalisé sans clé de partition. Ce sera pareil.
D'autre part, des moteurs de table primitifs peuvent être utilisés. Par exemple, remplissez les données une fois et voyez, tordez et supprimez. Vous pouvez utiliser Journal.
Ou stocker de petits volumes pour un traitement intermédiaire est StripeLog ou TinyLog.
La mémoire peut être utilisée s'il y a une petite quantité de données et simplement tordre quelque chose dans la RAM.
ClickHouse n'aime pas beaucoup les données renormalisées.
Voici un exemple typique. Il s'agit d'un grand nombre d'urls. Vous les placez dans le tableau adjacent. Et puis nous avons décidé de faire JOIN avec eux, mais cela ne fonctionnera pas, en règle générale, car ClickHouse ne prend en charge que Hash JOIN. S'il n'y a pas assez de RAM pour beaucoup de données avec lesquelles se connecter, alors JOIN ne fonctionnera pas *.
Si les données ont une cardinalité élevée, ne vous inquiétez pas, stockez-les sous une forme dénormalisée, les URL sont directement en place dans la table principale.
* et maintenant ClickHouse a aussi une jointure de fusion, et cela fonctionne dans des conditions où les données intermédiaires ne rentrent pas dans la RAM. Mais cela est inefficace et la recommandation reste valable.
Quelques autres exemples, mais je doute déjà qu'il s'agisse d'anti-modèles ou non.
ClickHouse a un inconvénient connu. Il ne sait pas mettre à jour *. Dans un sens, c'est même bien. Si vous avez des données importantes, par exemple, la comptabilité, personne ne pourra les envoyer, car il n'y a pas de mises à jour.
* La prise en charge de la mise à jour et de la suppression en mode batch a été ajoutée depuis longtemps.
Mais il existe des moyens spéciaux qui permettent aux mises à jour d'apparaître en arrière-plan. Par exemple, les tables de type ReplaceMergeTree. Ils font des mises à jour pendant les fusions en arrière-plan. Vous pouvez forcer cela avec la table d'optimisation. Mais ne le faites pas trop souvent, car cela écrasera complètement la partition.
JOIN distribués dans ClickHouse - ceci est également mal géré par le planificateur de requêtes.
Mauvais, mais parfois correct.
Utiliser ClickHouse uniquement pour relire les données avec select*.
Je ne recommanderais pas d'utiliser ClickHouse pour des calculs volumineux. Mais ce n'est pas tout à fait vrai, car nous nous éloignons déjà de cette recommandation. Et nous avons récemment ajouté la possibilité d'appliquer des modèles d'apprentissage automatique dans ClickHouse - Catboost. Et ça m'inquiète, parce que je pense : « Quelle horreur. C'est le nombre de cycles par octet qu'il s'avère ! Il est dommage pour moi de démarrer des cycles d'horloge sur des octets.
Mais n'ayez pas peur, installez ClickHouse, tout ira bien. Si quoi que ce soit, nous avons une communauté. Au fait, la communauté, c'est vous. Et si vous avez des problèmes, vous pouvez au moins aller sur notre chat, et j'espère que vous serez aidé.
des questions
Merci pour le rapport ! Où se plaindre du crash de ClickHouse ?
Vous pouvez vous plaindre auprès de moi personnellement dès maintenant.
J'ai récemment commencé à utiliser ClickHouse. Immédiatement abandonné l'interface cli.
Tu as de la chance.
Un peu plus tard, j'ai lâché le serveur avec un petit select.
Tu as du talent.
J'ai ouvert un bogue GitHub, mais il a été ignoré.
Nous verrons bien.
Aleksey m'a piégé pour que j'assiste au rapport, promettant de me dire comment vous comprimez les données à l'intérieur.
Très simple.
C'est ce que j'ai compris hier. Plus de détails.
Il n'y a pas de trucs terribles. C'est juste une compression bloc par bloc. La valeur par défaut est LZ4, vous pouvez activer ZSTD*. Blocs de 64 kilo-octets à 1 mégaoctet.
* il existe également un support pour les codecs de compression spécialisés qui peuvent être utilisés en chaîne avec d'autres algorithmes.
Les blocs ne sont-ils que des données brutes ?
Pas vraiment cru. Il existe des tableaux. Si vous avez une colonne numérique, les nombres d'une ligne sont empilés dans un tableau.
Effacer.
Alexey, un exemple qui était avec uniqExact sur IP, c'est-à-dire le fait qu'uniqExact prend plus de temps à compter par chaînes que par nombres, et ainsi de suite. Et si nous appliquions une feinte avec nos oreilles et coulions au moment de la relecture ? Autrement dit, vous semblez avoir dit qu'il ne diffère pas beaucoup sur le disque. Si nous lisons les lignes du disque, les castons, aurons-nous des agrégats plus rapidement ou non ? Ou gagnons-nous encore marginalement ici ? Il me semble que vous l'avez testé, mais pour une raison quelconque ne l'avez pas indiqué dans le benchmark.
Je pense que ce sera plus lent que pas de casting. Dans ce cas, l'adresse IP doit être analysée à partir de la chaîne. Bien sûr, dans ClickHouse, l'analyse des adresses IP est également optimisée. Nous avons essayé très fort, mais au même endroit, vous avez les nombres écrits sous la forme dix millième. Très inconfortable. D'autre part, la fonction uniqExact fonctionnera plus lentement sur les chaînes, non seulement parce que ce sont des chaînes, mais aussi parce qu'une spécialisation différente de l'algorithme est choisie. Les chaînes sont simplement gérées différemment.
Et si nous prenions un type de données plus primitif ? Par exemple, ils ont écrit l'identifiant d'utilisateur que nous avons, l'ont écrit sous forme de ligne, puis l'ont diffusé, est-ce que ce sera plus amusant ou non ?
Je doute. Je pense que ce sera encore plus triste, car après tout, l'analyse des nombres est un problème sérieux. Il me semble que ce collègue a même eu un rapport sur la difficulté d'analyser les nombres sous la forme dix millième, mais peut-être pas.
Alexey, merci beaucoup pour le rapport! Et merci beaucoup pour ClickHouse ! J'ai une question sur les plans. Existe-t-il une fonctionnalité dans les plans pour mettre à jour les dictionnaires de manière incomplète ?
c'est-à-dire redémarrage partiel ?
Oui oui. Comme la possibilité d'y définir un champ MySQL, c'est-à-dire de le mettre à jour après pour que seules ces données soient chargées si le dictionnaire est très volumineux.
Fonctionnalité très intéressante. Et, il me semble, une personne l'a suggéré dans notre chat. C'était peut-être même toi.
Je ne pense pas.
Super, maintenant il s'avère que deux demandes. Et vous pouvez commencer à le faire lentement. Mais je tiens tout de suite à vous prévenir que cette fonctionnalité est assez simple à mettre en place. Autrement dit, en théorie, il vous suffit d'écrire le numéro de version dans le tableau, puis d'écrire : la version est inférieure à telle ou telle. Et cela signifie que, très probablement, nous l'offrirons aux passionnés. Êtes-vous un passionné?
Oui, mais malheureusement pas en C++.
Vos collègues savent-ils écrire en C++ ?
Je trouverai quelqu'un.
Super*.
* la fonctionnalité a été ajoutée deux mois après le rapport - elle a été développée par l'auteur de la question et soumise par son .
Je vous remercie!
Bonjour! Merci pour le rapport ! Vous avez mentionné que ClickHouse consomme très bien toutes les ressources à sa disposition. Et l'orateur à côté de Luxoft a parlé de sa décision pour la poste russe. Il a dit qu'ils aimaient vraiment ClickHouse, mais qu'ils ne l'utilisaient pas à la place de leur principal concurrent précisément parce qu'il mangeait tout le processeur. Et ils ne pouvaient pas l'intégrer dans leur architecture, dans leur ZooKeeper avec dockers. Est-il possible de restreindre d'une manière ou d'une autre ClickHouse afin qu'il ne consomme pas tout ce qui lui est disponible ?
Oui, c'est possible et très facile. Si vous voulez consommer moins de cœurs, écrivez simplement set max_threads = 1. Et c'est tout, il exécutera la requête dans un seul noyau. De plus, vous pouvez spécifier différents paramètres pour différents utilisateurs. Donc pas de problème. Et dites à vos collègues de Luxoft que ce n'est pas bien qu'ils n'aient pas trouvé ce paramètre dans la documentation.
Alexeï, bonjour ! J'aimerais poser cette question. Ce n'est pas la première fois que j'entends que de nombreuses personnes commencent à utiliser ClickHouse comme référentiel pour les journaux. Lors du rapport, vous avez dit de ne pas le faire, c'est-à-dire que vous n'avez pas besoin de stocker de longues lignes. Qu'est-ce que tu en penses?
Premièrement, les journaux ne sont généralement pas de longues lignes. Il y a, bien sûr, des exceptions. Par exemple, un service écrit en Java lève une exception, il est journalisé. Et donc dans une boucle sans fin, et à court d'espace sur le disque dur. La solution est très simple. Si les lignes sont très longues, coupez-les. Que signifie long ? Des dizaines de kilo-octets sont mauvais *.
* dans les versions récentes de ClickHouse, la "granularité adaptative de l'index" est activée, ce qui élimine le problème du stockage des chaînes longues pour la plupart.
Un kilo-octet est-il normal ?
Normalement.
Bonjour! Merci pour le rapport ! J'ai déjà posé la question dans le chat, mais je ne me souviens pas si j'ai reçu une réponse. Est-il prévu d'étendre la section WITH à la manière d'un CTE ?
Pas encore. La section AVEC est quelque peu frivole. C'est comme une petite fonctionnalité pour nous.
Je comprends. Merci!
Merci pour le rapport ! Très intéressant! interrogation globale. Est-il prévu de faire, peut-être sous la forme d'une sorte de stubs, la modification de la suppression des données ?
Nécessairement. C'est notre première tâche dans notre file d'attente. Nous réfléchissons maintenant activement à la façon de tout faire correctement. Et vous devriez commencer à appuyer sur le clavier*.
* appuyé sur les boutons du clavier et tout a été fait.
Cela affectera-t-il ou non les performances du système? L'insert sera-t-il aussi rapide qu'aujourd'hui ?
Peut-être que les suppressions elles-mêmes, les mises à jour elles-mêmes seront très lourdes, mais cela n'affectera en rien les performances des sélections et les performances des insertions.
Et encore une petite question. Lors de la présentation, vous avez parlé de la clé primaire. En conséquence, nous avons un partitionnement, qui est mensuel par défaut, n'est-ce pas ? Et lorsque nous définissons une plage de dates qui correspond à un mois, nous ne lisons que cette partition, n'est-ce pas ?
Oui.
Une question. Si nous ne pouvons sélectionner aucune clé primaire, alors est-il juste de le faire exactement par le champ "Date" afin qu'il y ait en arrière-plan une restructuration plus petite de ces données afin qu'elles s'intègrent de manière plus ordonnée ? Si vous n'avez pas de requêtes de plage et que vous ne pouvez même pas sélectionner de clé primaire, vaut-il la peine de mettre une date dans la clé primaire ?
Oui.
Peut-être est-il judicieux de mettre dans la clé primaire un champ par lequel les données seront mieux compressées si elles sont triées par ce champ. Par exemple, ID utilisateur. L'utilisateur, par exemple, va sur le même site. Dans ce cas, mettez l'identifiant de l'utilisateur et l'heure. Et alors vos données seront mieux compressées. En ce qui concerne la date, si vous n'avez vraiment pas et n'avez jamais de requêtes de plage sur les dates, vous ne pouvez pas mettre la date dans la clé primaire.
D'accord, merci beaucoup!
Source: habr.com