la fonction de table input<\/a><\/noindex>.<\/p>\n<\/p>\n
<\/p>\n
Un autre anti-pattern est le micro-sharding. Par exemple, vous devez shard les donn\u00e9es et vous avez 5 serveurs, mais demain il y en aura 6. Et vous r\u00e9fl\u00e9chissez \u00e0 la mani\u00e8re de r\u00e9\u00e9quilibrer ces donn\u00e9es. Au lieu de cela, vous divisez non pas en 5 shards, mais en 1 000 shards. Ensuite, vous assignez chacun de ces micro-shards \u00e0 un serveur distinct. Ainsi, vous pouvez vous retrouver avec par exemple 200 ClickHouse sur un seul serveur. Des instances s\u00e9par\u00e9es sur des ports distincts ou des bases de donn\u00e9es distinctes. <\/p>\n
<\/p>\n
<\/p>\n
Mais dans ClickHouse, c'est pas tr\u00e8s bien. Parce qu'une seule instance de ClickHouse essaie d'utiliser toutes les ressources disponibles du serveur pour traiter une seule requ\u00eate. C'est-\u00e0-dire que si vous avez un serveur avec par exemple 56 c\u0153urs de processeur. Vous effectuez une requ\u00eate qui dure une seconde, et elle utilisera 56 c\u0153urs. Si vous avez plac\u00e9 200 ClickHouse sur un serveur, cela signifie qu'il y aura 10 000 threads qui d\u00e9marre. En gros, tout ira tr\u00e8s mal.<\/p>\n
<\/p>\n
Une autre raison est que la r\u00e9partition du travail entre ces instances sera in\u00e9gale. Certaines termineront plus t\u00f4t, d'autres plus tard. Si tout cela se d\u00e9roulait dans une seule instance, ClickHouse saurait lui-m\u00eame r\u00e9partir correctement les donn\u00e9es entre les threads. <\/p>\n
<\/p>\n
Et une autre raison est que vous aurez une interaction interprocessus via TCP. Les donn\u00e9es devront \u00eatre s\u00e9rialis\u00e9es, d\u00e9s\u00e9rialis\u00e9es et cela implique un nombre \u00e9norme de micro-shards. Ce sera tout simplement inefficace.<\/p>\n
<\/p>\n
<\/p>\n
Un autre anti-pattern, bien qu'il soit difficile de le qualifier d\u2019anti-pattern. C'est une grande quantit\u00e9 de pr\u00e9-agr\u00e9gation.<\/p>\n
<\/p>\n
En g\u00e9n\u00e9ral, la pr\u00e9-agr\u00e9gation, c'est bien. Vous aviez un milliard de lignes, vous l'avez agr\u00e9g\u00e9 et cela a donn\u00e9 1 000 lignes, ce qui fait que la requ\u00eate s'ex\u00e9cute instantan\u00e9ment. Tout est merveilleux. C'est possible. Et pour cela, ClickHouse dispose m\u00eame d'un type de table sp\u00e9cial, AggregatingMergeTree, qui effectue une agr\u00e9gation incr\u00e9mentale lors de l'insertion des donn\u00e9es. <\/p>\n
<\/p>\n
Mais il arrive que vous pensiez que nous allons agr\u00e9ger les donn\u00e9es de cette mani\u00e8re et encore de cette mani\u00e8re. Et dans un d\u00e9partement voisin, sans vouloir dire lequel, ils utilisent des tables SummingMergeTree pour faire des sommes par cl\u00e9 primaire, et comme cl\u00e9 primaire, ils utilisent une vingtaine de colonnes. J'ai chang\u00e9 par pr\u00e9caution les noms de certaines colonnes pour des raisons de confidentialit\u00e9, mais c'est \u00e0 peu pr\u00e8s \u00e7a.<\/p>\n
<\/p>\n
<\/p>\n
Et cela pose certains probl\u00e8mes. Tout d'abord, le volume de donn\u00e9es ne diminue pas beaucoup. Par exemple, il est r\u00e9duit par trois. Trois fois \u2014 ce serait un bon rapport pour permettre des possibilit\u00e9s d'analyse illimit\u00e9es qui \u00e9mergent si vos donn\u00e9es ne sont pas agr\u00e9g\u00e9es. Si les donn\u00e9es sont agr\u00e9g\u00e9es, vous recevez au lieu de l'analyse, une simple statistique mis\u00e9rable. <\/p>\n
<\/p>\n
Et ce qui est particuli\u00e8rement aga\u00e7ant ? C'est que ces personnes du d\u00e9partement voisin viennent parfois et demandent d'ajouter encore une colonne \u00e0 la cl\u00e9 primaire. C'est-\u00e0-dire que nous avions agr\u00e9gu\u00e9 les donn\u00e9es de cette mani\u00e8re, et maintenant nous en voulons un peu plus. Mais dans ClickHouse, il n'y a pas de commande pour modifier la cl\u00e9 primaire. Donc, il faut \u00e9crire des scripts en C++. Et je n'aime pas les scripts, m\u00eame s'ils sont en C++.<\/p>\n
<\/p>\n
Et si l'on regarde \u00e0 quoi ClickHouse a \u00e9t\u00e9 con\u00e7u, les donn\u00e9es non agr\u00e9g\u00e9es sont exactement le sc\u00e9nario pour lequel il a \u00e9t\u00e9 cr\u00e9\u00e9. Si vous utilisez ClickHouse pour des donn\u00e9es non agr\u00e9g\u00e9es, vous faites tout correctement. Si vous agglom\u00e9rez, c'est parfois pardonnable. <\/p>\n
<\/p>\n
<\/p>\n
Un autre cas int\u00e9ressant concerne les requ\u00eates en boucle infinie. Il m'arrive parfois de me connecter \u00e0 un serveur de production et de v\u00e9rifier la liste des processus. Et \u00e0 chaque fois, je d\u00e9couvre que quelque chose d'horrible se produit. <\/p>\n
<\/p>\n
Par exemple, cela. Ici, il est \u00e9vident que tout aurait pu \u00eatre ex\u00e9cut\u00e9 dans une seule requ\u00eate. Il suffit d'\u00e9crire l\u00e0-dedans url in et la liste.<\/p>\n
<\/p>\n
<\/p>\n
Pourquoi avoir beaucoup de telles requ\u00eates en boucle infinie est-il mauvais ? Si l'index n'est pas utilis\u00e9, vous aurez de nombreux passages sur les m\u00eames donn\u00e9es. Mais si l'index est utilis\u00e9, par exemple, vous avez une cl\u00e9 primaire sur ru et vous \u00e9crivez url = quelque chose. Et vous pensez qu'il sera lu pr\u00e9cis\u00e9ment un url de la table, cela ira. Mais en r\u00e9alit\u00e9, non. Parce que ClickHouse fait tout par lots. <\/p>\n
<\/p>\n
Lorsqu'il doit lire une certaine plage de donn\u00e9es, il en lit un peu plus, car l'index dans ClickHouse est sparse. Cet index ne permet pas de trouver une seule ligne individuelle dans la table, seulement une certaine plage. De plus, les donn\u00e9es sont compress\u00e9es par blocs. Pour lire une ligne, il faut prendre un bloc entier et le d\u00e9compresser. Et si vous ex\u00e9cutez beaucoup de requ\u00eates, il y aura de nombreux chevauchements et une grande quantit\u00e9 de travail sera effectu\u00e9e encore et encore.<\/p>\n
<\/p>\n
<\/p>\n
Et en bonus, on peut noter qu'il n'est pas n\u00e9cessaire d'avoir peur de transmettre m\u00eame des m\u00e9gaoctets, voire des centaines de m\u00e9gaoctets dans la section IN dans ClickHouse. Je me souviens de notre exp\u00e9rience, que si dans MySQL on transmet une multitude de valeurs dans la section IN, par exemple, si l'on y met 100 m\u00e9gaoctets de chiffres, MySQL consume 10 gigaoctets de m\u00e9moire et ensuite rien ne se passe, tout fonctionne mal. <\/p>\n
<\/p>\n
Et la deuxi\u00e8me chose est que dans ClickHouse, si vos requ\u00eates utilisent un index, cela n'est jamais plus lent qu'un scan complet, c'est-\u00e0-dire que si presque toute la table doit \u00eatre lue, il va le faire de mani\u00e8re s\u00e9quentielle et lire toute la table. En g\u00e9n\u00e9ral, il comprend tout lui-m\u00eame.<\/p>\n
<\/p>\n
Cependant, il y a certaines difficult\u00e9s. Par exemple, le fait que IN avec une sous-requ\u00eate n'utilise pas l'index. Mais c'est notre probl\u00e8me et nous devons le corriger. Il n'y a rien de fondamental ici. Nous allons le r\u00e9parer. <\/p>\n
<\/p>\n
Et une autre chose int\u00e9ressante est que si vous avez une tr\u00e8s longue requ\u00eate et que le traitement des requ\u00eates est distribu\u00e9, alors cette tr\u00e8s longue requ\u00eate sera envoy\u00e9e \u00e0 chaque serveur sans compression. Par exemple, 100 m\u00e9gaoctets et 500 serveurs. Et, par cons\u00e9quent, vous aurez 50 gigaoctets transmis sur le r\u00e9seau. Ils seront transmis et ensuite tout s'ex\u00e9cutera avec succ\u00e8s.<\/p>\n
<\/p>\n
* utilise d\u00e9j\u00e0 ; tout est r\u00e9par\u00e9, comme promis.<\/p>\n
<\/p>\n
<\/p>\n
Et c'est assez fr\u00e9quent que les requ\u00eates viennent de l'API. Par exemple, vous avez cr\u00e9\u00e9 votre propre service. Et si votre service est n\u00e9cessaire \u00e0 quelqu'un, vous avez ouvert une API et litt\u00e9ralement deux jours plus tard, vous voyez que quelque chose d'incompr\u00e9hensible se produit. Tout est surcharg\u00e9 et des requ\u00eates horribles arrivent, qui n'auraient jamais d\u00fb exister. <\/p>\n
<\/p>\n
Et la solution ici est simple. Si vous avez ouvert l'API, vous devrez la limiter. Par exemple, introduire des quotas. Il n'y a pas d'autres options normales. Sinon, quelqu'un \u00e9crira imm\u00e9diatement un script et il y aura des probl\u00e8mes. <\/p>\n
<\/p>\n
ClickHouse dispose d'une fonctionnalit\u00e9 sp\u00e9ciale : le comptage des quotas. Vous pouvez \u00e9galement transmettre votre cl\u00e9 de quota, par exemple, un identifiant interne d'utilisateur. Les quotas seront compt\u00e9s ind\u00e9pendamment pour chacun d'eux. <\/p>\n
<\/p>\n
<\/p>\n
Maintenant, une autre chose int\u00e9ressante. C'est la r\u00e9plication manuelle. <\/p>\n
<\/p>\n
Je connais de nombreux cas o\u00f9, m\u00eame si ClickHouse prend en charge la r\u00e9plication int\u00e9gr\u00e9e, les gens r\u00e9pliquent ClickHouse manuellement.<\/p>\n
<\/p>\n
Quel est le principe ? Vous avez un pipeline de traitement des donn\u00e9es qui fonctionne ind\u00e9pendamment, par exemple, dans diff\u00e9rents centres de donn\u00e9es. Vous enregistrez les m\u00eames donn\u00e9es de la m\u00eame mani\u00e8re dans ClickHouse. Cependant, en pratique, il s'av\u00e8re que les donn\u00e9es vont quand m\u00eame diverger en raison de certaines particularit\u00e9s de votre code. J'esp\u00e8re que cela ne sera pas le cas dans le v\u00f4tre. <\/p>\n
<\/p>\n
Et p\u00e9riodiquement, vous devrez quand m\u00eame synchroniser manuellement. Par exemple, une fois par mois, les administrateurs effectuent un rsync.<\/p>\n
<\/p>\n
En r\u00e9alit\u00e9, il est beaucoup plus simple d'utiliser la r\u00e9plication int\u00e9gr\u00e9e \u00e0 ClickHouse. Mais cela peut avoir certaines contre-indications, car cela n\u00e9cessite d'utiliser ZooKeeper. Je ne dirai rien de mal sur ZooKeeper, en principe, c'est un syst\u00e8me fonctionnel, mais il arrive que les gens ne l'utilisent pas en raison d'une phobie de Java, car ClickHouse est un bon syst\u00e8me \u00e9crit en C++, qui fonctionne tr\u00e8s bien. Et ZooKeeper est en Java. Il est donc parfois difficile de regarder cela, mais dans ce cas, vous pouvez utiliser la r\u00e9plication manuelle. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse est un syst\u00e8me pragmatique. Il prend en compte vos besoins. Si vous avez une r\u00e9plication manuelle, vous pouvez cr\u00e9er une table Distributed qui regarde vos r\u00e9pliques manuelles et effectue elle-m\u00eame un failover entre elles. Il existe m\u00eame une option sp\u00e9ciale qui permet d'\u00e9viter les flaps, m\u00eame si vos r\u00e9pliques divergent syst\u00e9matiquement.<\/p>\n
<\/p>\n
<\/p>\n
Par la suite, des probl\u00e8mes peuvent survenir si vous utilisez des moteurs de table primitifs. ClickHouse est un constructeur qui dispose d'une multitude de diff\u00e9rents moteurs de table. Pour tous les cas s\u00e9rieux, comme indiqu\u00e9 dans la documentation, utilisez des tables de la famille MergeTree. Les autres options sont juste pour des cas sp\u00e9cifiques ou pour des tests.<\/p>\n
<\/p>\n
Dans une table MergeTree, il n'est pas n\u00e9cessaire d'avoir une date et une heure. Vous pouvez utiliser cette option. Si vous n'avez pas de date et d'heure, indiquez que la valeur par d\u00e9faut est l'ann\u00e9e 2000. Cela fonctionnera et ne n\u00e9cessitera pas beaucoup de ressources. <\/p>\n
<\/p>\n
Dans la nouvelle version du serveur, vous pouvez m\u00eame sp\u00e9cifier que vous souhaitez un partitionnement personnalis\u00e9 sans cl\u00e9 de partition. Ce sera la m\u00eame chose. <\/p>\n
<\/p>\n
<\/p>\n
D'un autre c\u00f4t\u00e9, vous pouvez utiliser des moteurs de table primitifs. Par exemple, chargez les donn\u00e9es une fois et regardez, manipulez et supprimez. Vous pouvez utiliser Log.<\/p>\n
<\/p>\n
Ou stocker de petits volumes pour un traitement interm\u00e9diaire \u2013 c'est StripeLog ou TinyLog.<\/p>\n
<\/p>\n
Memory peut \u00eatre utilis\u00e9 si le volume de donn\u00e9es est petit et que vous devez simplement manipuler quelque chose en m\u00e9moire. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse n'aime pas vraiment les donn\u00e9es sur-normalis\u00e9es. <\/p>\n
<\/p>\n
Voici un exemple typique. Il s'agit d'un \u00e9norme nombre d'URLs. Vous les avez mises dans une table adjacente. Ensuite, vous avez d\u00e9cid\u00e9 de faire un JOIN avec elles, mais cela ne fonctionnera g\u00e9n\u00e9ralement pas, car ClickHouse ne prend en charge que les Hash JOIN. Si vous manquez de m\u00e9moire pour un grand volume de donn\u00e9es \u00e0 relier, le JOIN ne pourra pas \u00eatre effectu\u00e9*. <\/p>\n
<\/p>\n
Si les donn\u00e9es ont une grande cardinalit\u00e9, ne vous inqui\u00e9tez pas, conservez-les sous une forme d\u00e9normalis\u00e9e, les URLs directement inplace dans la table principale. <\/p>\n
<\/p>\n
* En fait, ClickHouse dispose maintenant \u00e9galement d'un merge join, et il fonctionne lorsque les donn\u00e9es interm\u00e9diaires ne tiennent pas en m\u00e9moire. Mais ce n'est pas efficace, et la recommandation reste valable.<\/p>\n
<\/p>\n
<\/p>\n
Encore quelques exemples, mais je commence \u00e0 douter s'ils sont antipattern ou non. <\/p>\n
<\/p>\n
ClickHouse a un inconv\u00e9nient bien connu. Il ne prend pas en charge les mises \u00e0 jour*. D'une certaine mani\u00e8re, c'est m\u00eame une bonne chose. Si vous avez des donn\u00e9es importantes, par exemple la comptabilit\u00e9, personne ne pourra les modifier, car il n'y a pas de mises \u00e0 jour.<\/p>\n
<\/p>\n
* Le support des mises \u00e0 jour et des suppressions en mode batch a \u00e9t\u00e9 ajout\u00e9 depuis longtemps.<\/p>\n
<\/p>\n
Mais il existe quelques m\u00e9thodes sp\u00e9ciales qui permettent de faire des mises \u00e0 jour en quelque sorte en arri\u00e8re-plan. Par exemple, les tables de type ReplaceMergeTree. Elles effectuent des mises \u00e0 jour lors des fusions en arri\u00e8re-plan. Vous pouvez forcer cela en utilisant optimize table. Mais ne le faites pas trop souvent, car cela entra\u00eenera une r\u00e9\u00e9criture compl\u00e8te de la partition. <\/p>\n
<\/p>\n
Les JOIN distribu\u00e9s dans ClickHouse sont \u00e9galement mal g\u00e9r\u00e9s par le planificateur de requ\u00eates. <\/p>\n
<\/p>\n
C'est mauvais, mais parfois \u00e7a va.<\/p>\n
<\/p>\n
Utiliser ClickHouse uniquement pour lire les donn\u00e9es avec un select*.<\/p>\n
<\/p>\n
Je ne recommanderais pas d'utiliser ClickHouse pour des calculs intensifs. Cependant, cela ne refl\u00e8te pas tout \u00e0 fait la r\u00e9alit\u00e9, car nous nous \u00e9loignons d\u00e9j\u00e0 de cette recommandation. Nous avons r\u00e9cemment ajout\u00e9 la possibilit\u00e9 d'appliquer des mod\u00e8les d'apprentissage automatique dans ClickHouse \u2013 Catboost. Cela m'inqui\u00e8te, car je me dis : \u00ab Quel d\u00e9sastre. Combien de cycles par octet cela repr\u00e9sente-t-il ! \u00bb. Je d\u00e9teste voir des cycles utilis\u00e9s pour des octets. <\/p>\n
<\/p>\n
<\/p>\n
Mais ne vous inqui\u00e9tez pas, installez ClickHouse, tout ira bien. En cas de probl\u00e8me, nous avons une communaut\u00e9. N'oubliez pas, cette communaut\u00e9, c'est vous. Et si vous rencontrez des difficult\u00e9s, vous pouvez au moins rejoindre notre chat, et j'esp\u00e8re que vous recevrez de l'aide. <\/p>\n
<\/p>\n
Questions<\/p>\n
<\/p>\n
Merci pour la pr\u00e9sentation ! O\u00f9 puis-je signaler une chute de ClickHouse ?<\/em><\/p>\n<\/p>\n
Vous pouvez me signaler personnellement d\u00e8s maintenant. <\/p>\n
<\/p>\n
J'ai r\u00e9cemment commenc\u00e9 \u00e0 utiliser ClickHouse. J'ai imm\u00e9diatement plant\u00e9 l'interface CLI.<\/em><\/p>\n<\/p>\n
Vous avez de la chance. <\/p>\n
<\/p>\n
Un peu plus tard, j'ai fait planter le serveur avec une simple requ\u00eate SELECT.<\/em><\/p>\n<\/p>\n
Vous avez un talent. <\/p>\n
<\/p>\n
J'ai ouvert un bug sur GitHub, mais il a \u00e9t\u00e9 ignor\u00e9.<\/em> <\/p>\n<\/p>\n
Nous verrons. <\/p>\n
<\/p>\n
Alexey m'a tromp\u00e9 pour me convaincre d'assister \u00e0 la pr\u00e9sentation en promettant de montrer comment vous compressez les donn\u00e9es.<\/em><\/p>\n<\/p>\n
C'est tr\u00e8s simple. <\/p>\n
<\/p>\n
Je l'ai compris hier. Plus de pr\u00e9cision.<\/em> <\/p>\n<\/p>\n
Il n'y a pas de trucs horribles. C'est simplement une compression par blocs. Par d\u00e9faut, LZ4 est utilis\u00e9, ZSTD peut \u00eatre activ\u00e9. Les blocs vont de 64 Ko \u00e0 1 Mo.<\/p>\n
<\/p>\n
* il existe \u00e9galement un soutien pour des codecs de compression sp\u00e9cialis\u00e9s qui peuvent \u00eatre utilis\u00e9s en cha\u00eene avec d'autres algorithmes.<\/p>\n
<\/p>\n
Les blocs contiennent simplement des donn\u00e9es brutes ?<\/em><\/p>\n<\/p>\n
Pas tout \u00e0 fait brutes. Cela contient des tableaux. Si vous avez une colonne num\u00e9rique, les nombres seront organis\u00e9s dans un tableau. <\/p>\n
<\/p>\n
Compris.<\/em> <\/p>\n<\/p>\n
Alexey, l'exemple avec uniqExact sur les adresses IP, c'est-\u00e0-dire le fait que uniqExact prend plus de temps \u00e0 calculer sur des cha\u00eenes que sur des nombres, etc. Et si nous utilisons un stratag\u00e8me et castons au moment de la lecture ? C'est-\u00e0-dire, vous avez dit que sur le disque, cela ne diff\u00e8re pas beaucoup. Si nous lisons des cha\u00eenes sur le disque et castons, alors nos agr\u00e9gats seront-ils plus rapides ou non ? Ou allons-nous tout de m\u00eame gagner ici de mani\u00e8re n\u00e9gligeable ? J'ai l'impression que vous avez test\u00e9 cela, mais vous ne l'avez pas mentionn\u00e9 dans le benchmark.<\/em> <\/p>\n<\/p>\n
Je pense que cela sera plus lent qu'en dehors du cast. Dans ce cas, l'adresse IP doit \u00eatre analys\u00e9e \u00e0 partir de la cha\u00eene. Bien s\u00fbr, dans ClickHouse, l'analyse des adresses IP est \u00e9galement optimis\u00e9e. Nous avons vraiment fait des efforts, mais vous avez des nombres \u00e9crits en forme de dizaines de milliers. C'est tr\u00e8s peu pratique. D'un autre c\u00f4t\u00e9, la fonction uniqExact va fonctionner plus lentement sur des cha\u00eenes, non seulement parce que ce sont des cha\u00eenes, mais aussi parce qu'une autre sp\u00e9cialisation de l'algorithme est choisie. Les cha\u00eenes sont simplement trait\u00e9es diff\u00e9remment.<\/p>\n
<\/p>\n
Et si on prenait un type de donn\u00e9es plus primitif ? Par exemple, on a \u00e9crit l'user id, qui est dans notre cas, on l'a \u00e9crit sous forme de cha\u00eene, et puis on a fait un cast, ce sera plus amusant ou pas ?<\/em><\/p>\n<\/p>\n
J'en doute. Je pense que ce sera m\u00eame plus triste, car analyser des nombres est un v\u00e9ritable probl\u00e8me. Il me semble que l'un de mes coll\u00e8gues avait m\u00eame fait une pr\u00e9sentation sur la difficult\u00e9 d'analyser des nombres sous la forme de dizaines de milliers, ou peut-\u00eatre pas. <\/p>\n
<\/p>\n
Alexey, merci beaucoup pour ta pr\u00e9sentation ! Et encore merci pour ClickHouse ! J'ai une question concernant les fonctionnalit\u00e9s. Y a-t-il des projets pour une mise \u00e0 jour partielle des dictionnaires ?<\/em><\/p>\n<\/p>\n
C'est-\u00e0-dire un rechargement partiel ?<\/p>\n
<\/p>\n
Oui, oui. Une sorte de possibilit\u00e9 de d\u00e9finir un champ MySQL, c'est-\u00e0-dire de mettre \u00e0 jour apr\u00e8s, pour que seules ces donn\u00e9es soient charg\u00e9es, si le dictionnaire est tr\u00e8s volumineux.<\/em><\/p>\n<\/p>\n
C'est une fonction tr\u00e8s int\u00e9ressante. Et, il me semble qu'une personne l'a propos\u00e9e dans notre chat. C'\u00e9tait peut-\u00eatre m\u00eame vous. <\/p>\n
<\/p>\n
Je ne pense pas.<\/em><\/p>\n<\/p>\n
Super, donc cela fait deux requ\u00eates. Et on peut commencer \u00e0 le faire tranquillement. Mais je veux vous pr\u00e9venir tout de suite que cette fonctionnalit\u00e9 est assez simple \u00e0 mettre en \u0153uvre. C'est-\u00e0-dire qu'en th\u00e9orie, il suffit d'\u00e9crire le num\u00e9ro de version dans la table et ensuite d'\u00e9crire : version inf\u00e9rieure \u00e0 telle version. Et cela signifie que, tr\u00e8s probablement, nous proposerons de le faire aux enthousiastes. \u00cates-vous un enthousiaste ? <\/p>\n
<\/p>\n
Oui, mais, malheureusement, pas en C++.<\/em><\/p>\n<\/p>\n
Vos coll\u00e8gues savent-ils \u00e9crire en C++ ? <\/p>\n
<\/p>\n
Je vais trouver quelqu'un.<\/em><\/p>\n<\/p>\n
Super*.<\/p>\n
<\/p>\n
* la fonctionnalit\u00e9 a \u00e9t\u00e9 ajout\u00e9e deux mois apr\u00e8s la pr\u00e9sentation \u2013 elle a \u00e9t\u00e9 d\u00e9velopp\u00e9e par l'auteur de la question et a \u00e9t\u00e9 envoy\u00e9 pull request<\/a><\/noindex>.<\/p>\n<\/p>\n
Merci!<\/em><\/p>\n<\/p>\n
Bonjour ! Merci pour la pr\u00e9sentation ! Vous avez mentionn\u00e9 que ClickHouse consomme tr\u00e8s bien toutes les ressources qui lui sont disponibles. Et le pr\u00e9sentateur voisin de Luxoft a parl\u00e9 de sa solution pour la Poste de Russie. Il a dit qu'ils aimaient beaucoup ClickHouse, mais qu'ils ne l'avaient pas utilis\u00e9 \u00e0 la place de leur principal concurrent pr\u00e9cis\u00e9ment parce qu'il utilisait tout le processeur. Et ils n'ont pas pu l'int\u00e9grer dans leur architecture, dans leur ZooKeeper avec des Docker. Existe-t-il un moyen de limiter ClickHouse afin qu'il ne consomme pas tout ce qui lui est accessible ?<\/em><\/p>\n<\/p>\n
Oui, c'est possible et tr\u00e8s facile. Si vous souhaitez qu'il consomme moins de c\u0153urs, il suffit d'\u00e9crire set max_threads = 1<\/code>. Et voil\u00e0, il ex\u00e9cutera la requ\u00eate sur un seul c\u0153ur. De plus, vous pouvez indiquer cette configuration diff\u00e9rente pour divers utilisateurs. Donc, aucun probl\u00e8me. Et dites \u00e0 vos coll\u00e8gues de Luxoft qu'il n'est pas bon qu'ils n'aient pas trouv\u00e9 cette option dans la documentation. <\/p>\n<\/p>\n
Alexei, bonjour ! J'aimerais poser une question. Je n'entends pas pour la premi\u00e8re fois que beaucoup commencent \u00e0 utiliser ClickHouse comme stockage pour les journaux. Lors de votre pr\u00e9sentation, vous avez dit de ne pas faire cela, c'est-\u00e0-dire qu'il ne faut pas stocker de longues cha\u00eenes. Que pensez-vous de cela ?<\/em><\/p>\n<\/p>\n
Tout d'abord, les journaux ne sont g\u00e9n\u00e9ralement pas de longues cha\u00eenes. Il y a bien s\u00fbr des exceptions. Par exemple, un service \u00e9crit en Java g\u00e9n\u00e8re une exception qui est enregistr\u00e9e. Et cela dans une boucle infinie, et l'espace sur le disque dur se termine. La solution est tr\u00e8s simple. Si les cha\u00eenes sont tr\u00e8s longues, coupez-les. Et que signifie longues ? Des dizaines de kilo-octets, c'est mauvais*.<\/p>\n
<\/p>\n
* dans les derni\u00e8res versions de ClickHouse, l'\u00ab adaptabilit\u00e9 de la granularit\u00e9 de l'index \u00bb a \u00e9t\u00e9 int\u00e9gr\u00e9e, ce qui r\u00e9sout en grande partie le probl\u00e8me du stockage de longues cha\u00eenes.<\/p>\n
<\/p>\n
Et un kilo-octet, c'est normal ?<\/em><\/p>\n<\/p>\n
C'est normal. <\/p>\n
<\/p>\n
Bonjour ! Merci pour la pr\u00e9sentation ! J'ai d\u00e9j\u00e0 demand\u00e9 cela dans le chat, mais je ne me souviens pas si j'ai re\u00e7u une r\u00e9ponse. Pr\u00e9voyez-vous d'\u00e9largir la section WITH \u00e0 la mani\u00e8re des CTE ?<\/em><\/p>\n<\/p>\n
Pas pour l'instant. La section WITH n'est pas tr\u00e8s s\u00e9rieuse chez nous. C'est une petite fonctionnalit\u00e9.<\/p>\n
<\/p>\n
J'ai compris. Merci !<\/em><\/p>\n<\/p>\n
Merci pour la pr\u00e9sentation ! C'\u00e9tait tr\u00e8s int\u00e9ressant ! Une question globale. Pr\u00e9voyez-vous de faire, peut-\u00eatre sous forme de quelques placeholders, une modification pour la suppression de donn\u00e9es ?<\/em><\/p>\n<\/p>\n
C'est s\u00fbr. C'est notre premi\u00e8re t\u00e2che dans notre file d'attente. Nous avons actuellement r\u00e9fl\u00e9chi de mani\u00e8re active \u00e0 la mani\u00e8re de tout faire correctement. Il est temps de commencer \u00e0 frapper sur le clavier*.<\/p>\n
<\/p>\n
*Nous avons appuy\u00e9 sur les touches du clavier et tout est fait.<\/p>\n
<\/p>\n
Cela va-t-il affecter la performance du syst\u00e8me ou non ? L'insertion sera-t-elle aussi rapide qu'actuellement ?<\/em><\/p>\n<\/p>\n
Il est possible que les suppressions et les mises \u00e0 jour soient tr\u00e8s lourdes, mais cela n'affectera pas les performances des s\u00e9lections et des insertions.<\/p>\n
<\/p>\n
Et une petite question. Lors de la pr\u00e9sentation, vous avez parl\u00e9 de la cl\u00e9 primaire. Donc, nous avons un partitionnement qui est par d\u00e9faut mensuel, n'est-ce pas ? Et quand nous sp\u00e9cifions une plage de dates qui rentre dans le mois, seule cette partition est lue, c'est bien \u00e7a ?<\/em><\/p>\n<\/p>\n
Oui.<\/p>\n
<\/p>\n
Une question. Si nous ne pouvons pas \u0432\u044b\u0434\u0435\u043b\u0438\u0442\u044c de cl\u00e9 primaire, est-il correct de la faire sur le champ \u00ab Date \u00bb afin de r\u00e9duire la r\u00e9organisation des donn\u00e9es en arri\u00e8re-plan pour qu'elles soient mieux ordonn\u00e9es ? Si vous n'avez pas de requ\u00eates par plages et que vous ne pouvez pas choisir de cl\u00e9 primaire, vaut-il mieux mettre la date en cl\u00e9 primaire ?<\/em><\/p>\n<\/p>\n
Oui.<\/p>\n
<\/p>\n
Peut-\u00eatre que cela vaut la peine d'inclure dans la cl\u00e9 primaire un champ qui permettra une meilleure compression des donn\u00e9es si elles sont tri\u00e9es par celui-ci. Par exemple, l'identifiant d'un utilisateur. Un utilisateur, par exemple, visite le m\u00eame site. Dans ce cas, vous mettez l'identifiant de l'utilisateur et le temps. Ainsi, vos donn\u00e9es seront mieux compress\u00e9es. Concernant la date, si vous n'avez vraiment jamais de requ\u00eates par plages de dates, il n'est pas n\u00e9cessaire d'inclure la date dans la cl\u00e9 primaire. <\/p>\n
<\/p>\n
Bien, merci beaucoup !<\/em><\/p>\nSource : habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0430\u043a \u043a\u0430\u043a ClickHouse \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439, \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 \u0432\u0430\u0436\u043d\u043e \u0443\u0447\u0438\u0442\u044b\u0432\u0430\u0442\u044c \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u043f\u0440\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 ClickHouse, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043d\u0435\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u0435. \u041d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0438\u0437 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043a\u0430\u0437\u0430\u043d\u043e, \u043a\u0430\u043a \u0432\u044b\u0431\u043e\u0440 \u0442\u043e\u0439 \u0438\u043b\u0438 \u0438\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u044b \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043d\u0430 \u043f\u043e\u0440\u044f\u0434\u043a\u0438. \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91439,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Utilisation](\"\/wp-content\/uploads\/2020\/08\/8e42c1fffffcc964eacef240ea90bbc5.jpg\")
<\/p>\n