{"id":80775,"date":"2020-05-08T13:42:47","date_gmt":"2020-05-08T11:42:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah"},"modified":"2020-05-08T13:42:47","modified_gmt":"2020-05-08T11:42:47","slug":"clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","title":{"rendered":"ClickHouse pour les utilisateurs avanc\u00e9s dans les questions et r\u00e9ponses","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>En avril, les ing\u00e9nieurs d'Avito se sont r\u00e9unis pour des rencontres en ligne avec le d\u00e9veloppeur principal de ClickHouse, Alexey Milovidov, et Kirill Shvakov, un d\u00e9veloppeur Golang de la soci\u00e9t\u00e9 Integros. Ils ont discut\u00e9 de la mani\u00e8re dont nous utilisons le syst\u00e8me de gestion de base de donn\u00e9es et des difficult\u00e9s que nous rencontrons. <\/p>\n<p><\/p>\n<p>\u00c0 partir de cette r\u00e9union, nous avons r\u00e9dig\u00e9 un article avec des r\u00e9ponses d\u2019experts \u00e0 nos questions et celles du public sur les sauvegardes, le r\u00e9partition des donn\u00e9es, les dictionnaires externes, le pilote Golang et la mise \u00e0 jour des versions de ClickHouse. Cela peut \u00eatre utile pour les d\u00e9veloppeurs qui travaillent d\u00e9j\u00e0 activement avec le SGBD de \u00ab Yandex \u00bb et qui s'int\u00e9ressent \u00e0 son pr\u00e9sent et \u00e0 son avenir. Par d\u00e9faut, les r\u00e9ponses d'Alexey Milovidov, sauf indication contraire. <\/p>\n<p><\/p>\n<p>Attention, il y a beaucoup de texte sous le lien. Nous esp\u00e9rons que le contenu des questions vous aidera \u00e0 vous rep\u00e9rer.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse pour les utilisateurs avanc\u00e9s dans les questions et r\u00e9ponses\" src=\"\/wp-content\/uploads\/2020\/05\/242b1d8d002fe115614435c242297fd2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"soderzhanie\">Contenu<\/h2>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#old-data\">ClickHouse est en constante \u00e9volution, tandis que nos donn\u00e9es ne le sont pas. Que faire \u00e0 ce sujet ?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#backup-best-practicies\">Quelles sont les meilleures pratiques actuelles pour la sauvegarde des donn\u00e9es de ClickHouse ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#replication\">Est-il possible d'organiser un retard contr\u00f4l\u00e9 des r\u00e9pliques dans les flux ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#soooo-changeable\">Que faire si la structure de la table a chang\u00e9 ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-best-practices\">Quelles sont les meilleures pratiques actuelles en mati\u00e8re de r\u00e9partition des donn\u00e9es ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">ClickHouse dispose d'un utilitaire nomm\u00e9 clickhouse-copier. Pouvez-vous en parler ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">Vous aviez un projet pilote appel\u00e9 r\u00e9partition. Que s'est-il pass\u00e9 ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">Est-il possible de fusionner toutes les parties des donn\u00e9es avant de les transf\u00e9rer sur des disques lents ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">Comment passer \u00e0 de nouvelles versions de ClickHouse si je ne peux pas v\u00e9rifier la compatibilit\u00e9 \u00e0 l'avance ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#kill-query\">Kill query devrait tuer les requ\u00eates, mais ce n'est pas le cas. Pourquoi ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reading-time\">Comment calculer le temps de r\u00e9ponse en cas de charge de lecture ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">Que faut-il ajuster dans ClickHouse pour que plus de donn\u00e9es soient en cache ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">Comment configurer storage_configuration pour un stockage en m\u00e9moire ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">Jusqu'\u00e0 quel nombre de valeurs uniques Low Cardinality est-il efficace ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">Quelles sont les meilleures pratiques pour la recherche textuelle dans une table contenant cinq milliards de lignes ?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">Comment organiser l'acc\u00e8s \u00e0 ClickHouse pour un grand nombre d'utilisateurs ?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">Peut-on envoyer les r\u00e9sultats d'une requ\u00eate \u00e0 dix clients ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">Comment g\u00e9rer les op\u00e9rations asynchrones et les vues mat\u00e9rialis\u00e9es ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#dashboard\">ClickHouse g\u00e9n\u00e8re beaucoup de journaux. Comment puis-je voir tout ce qui se passe avec le serveur \u00e0 un moment donn\u00e9 ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zen\">Comment influencer les fusionnements pour \u00e9viter que le serveur ne tombe en OOM ?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">Comment se d\u00e9roulera le d\u00e9veloppement du pilote Golang pour ClickHouse ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">Le dictionnaire externe ne se l\u00e8ve pas apr\u00e8s un red\u00e9marrage avec l'option lazy_load activ\u00e9e. Que faire ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">Que faire si system reload dictionaries ne charge aucun des nombreux dictionnaires, si au moins un d'entre eux \u00e9choue avec une erreur ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">Y a-t-il un moyen de configurer les informations dans la config de ClickHouse sans les exposer lors des erreurs ?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Bonus : fonds pour Zoom lors de r\u00e9unions<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Si vous ne souhaitez pas lire le texte, vous pouvez regarder l'enregistrement des soir\u00e9es <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">sur notre cha\u00eene YouTube<\/a><\/noindex>. Les timestamps se trouvent dans le premier commentaire sous la vid\u00e9o.<\/p><\/blockquote>\n<p><\/p>\n<h2 id=\"anchorold-dataanchorclickhouse-postoyanno-obnovlyaetsya-a-nashi-dannyenbsp-net-chto-snbspetim-delat\"><noindex><a rel=\"nofollow\" name=\"old-data\"><\/a><\/noindex>ClickHouse se met \u00e0 jour constamment, mais nos donn\u00e9es ne le sont pas. Que faire \u00e0 ce sujet ?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse se met \u00e0 jour constamment, mais nos donn\u00e9es qui ont \u00e9t\u00e9 trait\u00e9es avec optimize final ne sont pas mises \u00e0 jour et restent dans la sauvegarde. <\/p>\n<p>Supposons qu'un probl\u00e8me se soit produit et que des donn\u00e9es aient \u00e9t\u00e9 perdues. Nous avons d\u00e9cid\u00e9 de restaurer et avons d\u00e9couvert que d'anciennes partitions stock\u00e9es sur les serveurs de sauvegarde diff\u00e8rent \u00e9norm\u00e9ment de la version de ClickHouse actuellement utilis\u00e9e. Que faire dans une telle situation, et est-ce possible ?<\/p><\/blockquote>\n<p>La situation o\u00f9 vous restaurez des donn\u00e9es \u00e0 partir d'une sauvegarde dans un ancien format, alors qu'elles ne se connectent pas dans la nouvelle version, est impossible. Nous veillons \u00e0 ce que le format des donn\u00e9es dans ClickHouse reste toujours r\u00e9trocompatible. Cela est bien plus important que la r\u00e9trocompatibilit\u00e9 fonctionnelle, surtout si le comportement d'une fonction peu utilis\u00e9e a chang\u00e9. Les donn\u00e9es stock\u00e9es sur disque doivent toujours pouvoir \u00eatre lues par la nouvelle version de ClickHouse. C'est une loi. <\/p>\n<p><\/p>\n<h2 id=\"anchorbackup-best-practiciesanchorkakie-luchshie-praktiki-est-nanbspdannyy-moment-ponbsprezervnomu-kopirovaniyu-dannyh-iznbspclickhouse\"><noindex><a rel=\"nofollow\" name=\"backup-best-practicies\"><\/a><\/noindex>Quelles sont les meilleures pratiques actuelles pour la sauvegarde des donn\u00e9es de ClickHouse ?<\/h2>\n<p><\/p>\n<blockquote><p>Comment faire des sauvegardes en tenant compte des op\u00e9rations optimize final, avec une base de donn\u00e9es de plusieurs t\u00e9raoctets, et des donn\u00e9es qui sont mises \u00e0 jour, disons, au cours des trois derniers jours, sans qu'aucune proc\u00e9dure ne soit effectu\u00e9e par la suite ? <\/p>\n<p>Nous pouvons bricoler notre propre solution et \u00e9crire sur Bash : collecte de ces sauvegardes. Peut-\u00eatre qu'il n'est pas n\u00e9cessaire de bricoler, et que le v\u00e9lo a d\u00e9j\u00e0 \u00e9t\u00e9 invent\u00e9 ? <\/p><\/blockquote>\n<p>Tout d'abord, concernant les meilleures pratiques. Mes coll\u00e8gues conseillent toujours, en r\u00e9ponse aux questions sur les sauvegardes, de rappeler le service \u00ab Yandex.Cloud \u00bb, o\u00f9 cette t\u00e2che a d\u00e9j\u00e0 \u00e9t\u00e9 r\u00e9solue. Donc, utilisez-le si c'est possible. <\/p>\n<p><\/p>\n<p>Il n'existe pas de solution compl\u00e8te, \u00e0 cent pour cent int\u00e9gr\u00e9e dans ClickHouse, pour les sauvegardes. Il y a quelques pr\u00e9parations que l'on peut utiliser. Pour obtenir une solution compl\u00e8te, il faudra soit travailler un peu manuellement, soit cr\u00e9er des wrappers sous forme de scripts.<\/p>\n<p><\/p>\n<p>Je commencerai par les solutions les plus simples et je finirai par les plus sophistiqu\u00e9es en fonction du volume de donn\u00e9es et de la taille du cluster. Plus le cluster est grand, plus la solution devient complexe.<\/p>\n<p><\/p>\n<p>Si le tableau de donn\u00e9es ne fait que quelques gigaoctets, vous pouvez effectuer une sauvegarde de cette mani\u00e8re : <\/p>\n<p><\/p>\n<ol>\n<li>Enregistrer la d\u00e9finition des tables, c'est-\u00e0-dire les m\u00e9tadonn\u00e9es \u2014 <strong>show create table<\/strong>.<\/li>\n<li>Effectuer un dump \u00e0 l'aide du client ClickHouse \u2014 <strong>select<\/strong> * <strong>from table<\/strong> dans un fichier. Par d\u00e9faut, vous obtiendrez un fichier au format TabSeparated. Si vous souhaitez quelque chose de plus efficace, vous pouvez utiliser le format Native. <\/li>\n<\/ol>\n<p><\/p>\n<p>Si le volume de donn\u00e9es est plus important, la sauvegarde prendra plus de temps et occupera beaucoup d'espace. Cela s'appelle une sauvegarde logique, qui n'est pas li\u00e9e au format des donn\u00e9es ClickHouse. Si elle existe, dans le pire des cas, vous pourrez prendre la sauvegarde et la charger dans MySQL pour la restauration. <\/p>\n<p><\/p>\n<p>Pour des cas plus avanc\u00e9s, ClickHouse int\u00e8gre la possibilit\u00e9 de cr\u00e9er un snapshot des partitions sur le syst\u00e8me de fichiers local. Cette fonctionnalit\u00e9 est disponible sous forme de requ\u00eate <strong>alter table freeze partition<\/strong>. Ou simplement <strong>alter table freeze<\/strong> \u2014 ceci est un snapshot de toute la table. <\/p>\n<p><\/p>\n<p>Le snapshot sera cr\u00e9\u00e9 de mani\u00e8re coh\u00e9rente pour une table sur un seul shard, c'est-\u00e0-dire qu'il n'est pas possible de cr\u00e9er un snapshot coh\u00e9rent de tout le cluster de cette mani\u00e8re. Mais pour la plupart des t\u00e2ches, cela n'est pas n\u00e9cessaire, et il suffit d'ex\u00e9cuter la requ\u00eate sur chaque shard pour obtenir un snapshot coh\u00e9rent. Il est cr\u00e9\u00e9 sous la forme de hard links et n'occupe donc pas d'espace suppl\u00e9mentaire. Ensuite, vous copiez ce snapshot sur le serveur de sauvegarde ou dans le stockage que vous utilisez pour les sauvegardes.<\/p>\n<p><\/p>\n<p>Restaurer une telle sauvegarde est assez simple. La premi\u00e8re \u00e9tape consiste \u00e0 cr\u00e9er les tables selon les d\u00e9finitions de tables existantes. Ensuite, vous copiez les snapshots de partitions sauvegard\u00e9s dans Directory-Detached pour les tables de donn\u00e9es et vous ex\u00e9cutez la requ\u00eate <strong>attach partition<\/strong>. Cette solution convient tout \u00e0 fait pour les volumes de donn\u00e9es les plus importants. <\/p>\n<p><\/p>\n<p>Parfois, quelque chose de encore plus puissant est n\u00e9cessaire \u2014 dans les cas o\u00f9 vous avez des dizaines, voire des centaines de t\u00e9raoctets sur chaque serveur et des centaines de serveurs. Il existe une solution que j'ai observ\u00e9e chez mes coll\u00e8gues de \u00ab Yandex.Metrica \u00bb. Je ne la recommanderais pas \u00e0 tout le monde \u2014 lisez et d\u00e9cidez par vous-m\u00eame si elle vous convient ou non. <\/p>\n<p><\/p>\n<p>Tout d'abord, vous devez cr\u00e9er plusieurs serveurs avec de grands espaces de stockage. Ensuite, sur ces serveurs, d\u00e9ployez plusieurs serveurs ClickHouse et configurez-les pour qu'ils fonctionnent comme une autre r\u00e9plique pour les m\u00eames shards. Ensuite, utilisez sur ces serveurs un syst\u00e8me de fichiers ou un outil qui permet de cr\u00e9er des snapshots. Il y a deux options. La premi\u00e8re option est les snapshots LVM, la deuxi\u00e8me option est ZFS sur Linux. <\/p>\n<p><\/p>\n<p>Apr\u00e8s cela, chaque jour, vous devez cr\u00e9er un snapshot, il occupera un certain espace. \u00c9videmment, si les donn\u00e9es changent, au fil du temps, l'espace occup\u00e9 augmentera. Ce snapshot peut \u00eatre r\u00e9cup\u00e9r\u00e9 \u00e0 tout moment pour restaurer les donn\u00e9es, c'est une solution assez \u00e9trange. De plus, il faut \u00e9galement limiter ces r\u00e9pliques dans la configuration pour qu'elles n'essaient pas de devenir des leaders.<\/p>\n<p><\/p>\n<h2 id=\"anchorreplicationanchormozhno-li-budet-organizovat-kontroliruemoe-otstavanie-replik-vnbspvalah\"><noindex><a rel=\"nofollow\" name=\"replication\"><\/a><\/noindex>Est-il possible d'organiser un retard contr\u00f4l\u00e9 des r\u00e9pliques dans les flux ?<\/h2>\n<p><\/p>\n<blockquote><p>Cette ann\u00e9e, vous pr\u00e9voyez de cr\u00e9er des vagues dans ClickHouse. Pourra-t-on organiser un retard contr\u00f4l\u00e9 des r\u00e9pliques ? Nous aimerions utiliser cela pour nous prot\u00e9ger contre des sc\u00e9narios n\u00e9gatifs avec des alter ego et d'autres changements. <\/p>\n<p>Peut-on effectuer des rollback pour les alters ? Par exemple, dans une vague existante, peut-on dire qu'\u00e0 partir de ce moment, appliquez les modifications, et \u00e0 partir de ce moment, cessez d'appliquer les modifications ?<\/p>\n<p>Si une \u00e9quipe est arriv\u00e9e dans notre cluster et l'a cass\u00e9, nous avons une r\u00e9plique conditionnelle avec un retard d'une heure, o\u00f9 nous pouvons dire, utilisons-la pour le moment, mais nous ne prendrons pas en compte les derni\u00e8res dix minutes de modifications ? <\/p><\/blockquote>\n<p>Pour commencer avec le retard contr\u00f4l\u00e9 des r\u00e9pliques. Cette demande a \u00e9t\u00e9 faite par les utilisateurs, et nous avons cr\u00e9\u00e9 une issue sur GitHub avec la demande : \u00ab Si quelqu'un en a besoin, mettez un like, mettez un c\u0153ur \u00bb. Personne n'a aim\u00e9, et l'issue a \u00e9t\u00e9 ferm\u00e9e. Cependant, il est d\u00e9j\u00e0 possible d'obtenir cette fonctionnalit\u00e9 en configurant ClickHouse. En effet, cela n'est possible qu'\u00e0 partir de la version 20.3.<\/p>\n<p><\/p>\n<p>ClickHouse effectue en permanence des fusions de donn\u00e9es en arri\u00e8re-plan. Lorsqu'une fusion est r\u00e9alis\u00e9e, un certain ensemble de morceaux de donn\u00e9es est remplac\u00e9 par un morceau plus grand. Pendant ce temps, les morceaux de donn\u00e9es pr\u00e9c\u00e9dents continuent de rester sur le disque pendant un certain temps.<\/p>\n<p><\/p>\n<p>Tout d'abord, ils continuent d'\u00eatre stock\u00e9s tant qu'il existe des requ\u00eates select qui les utilisent, afin de garantir un fonctionnement non bloquant. Les requ\u00eates select peuvent lire sans probl\u00e8me \u00e0 partir des anciens morceaux.<\/p>\n<p><\/p>\n<p>Deuxi\u00e8mement, il y a aussi un seuil de temps : les anciens morceaux de donn\u00e9es restent sur le disque pendant huit minutes. Ces huit minutes peuvent \u00eatre ajust\u00e9es et m\u00eame \u00e9tendues \u00e0 un jour. Cela aura un co\u00fbt en espace disque : selon le flux de donn\u00e9es, il se peut que les donn\u00e9es du dernier jour ne fassent pas que doubler, mais qu'elles augmentent jusqu'\u00e0 cinq fois. Cependant, en cas de probl\u00e8me majeur, vous pourrez arr\u00eater le serveur ClickHouse et tout r\u00e9gler.<\/p>\n<p><\/p>\n<p>La question se pose alors, comment cela prot\u00e8ge-t-il contre les alters. Il convient d'examiner cela de plus pr\u00e8s, car dans les anciennes versions de ClickHouse, l'alter fonctionnait de mani\u00e8re \u00e0 modifier directement les morceaux. Il y a un morceau de donn\u00e9es avec certains fichiers, et nous effectuons, par exemple, <strong>alter drop column<\/strong>. Ce faisant, cette colonne est physiquement supprim\u00e9e de tous les morceaux.<\/p>\n<p><\/p>\n<p>Mais \u00e0 partir de la version 20.3, le m\u00e9canisme des alters a \u00e9t\u00e9 compl\u00e8tement revu, et maintenant les morceaux de donn\u00e9es sont toujours immuables. Ils ne changent pas du tout : les alters fonctionnent d\u00e9sormais de mani\u00e8re similaire aux merges. Au lieu de modifier un morceau sur place, nous en cr\u00e9ons un nouveau. Dans le nouveau morceau, les fichiers qui n'ont pas \u00e9t\u00e9 modifi\u00e9s deviennent des hard links, et si nous avons supprim\u00e9 une colonne, elle sera simplement absente dans le nouveau morceau. L'ancien morceau sera supprim\u00e9 par d\u00e9faut apr\u00e8s huit minutes, et ici, il est possible d'ajuster les param\u00e8tres mentionn\u00e9s ci-dessus. <\/p>\n<p><\/p>\n<p>Il en va de m\u00eame pour les ALTERs de type mutations. Lorsque vous effectuez <strong>alter delete<\/strong> ou <strong>alter update<\/strong>, il ne modifie pas le fragment, mais en cr\u00e9e un nouveau. Puis, il supprime l'ancien.<\/p>\n<p><\/p>\n<h2 id=\"anchorsoooo-changeableanchorkak-byt-esli-struktura-tablicy-pomenyalas\"><noindex><a rel=\"nofollow\" name=\"soooo-changeable\"><\/a><\/noindex>Que faire si la structure de la table a chang\u00e9 ?<\/h2>\n<p><\/p>\n<blockquote><p>Comment restaurer une sauvegarde r\u00e9alis\u00e9e avec une ancienne structure ? Et la deuxi\u00e8me question concerne le cas des snapshots et des syst\u00e8mes de fichiers. Est-ce que Btrfs peut remplacer ZFS sur Linux LVM ?<\/p><\/blockquote>\n<p>Si vous r\u00e9alisez <strong>attach partition<\/strong> Si des partitions ont une autre structure, ClickHouse vous dira que ce n'est pas possible. La solution consiste \u00e0 cr\u00e9er d'abord une table temporaire de type MergeTree avec l'ancienne structure, y attacher les donn\u00e9es \u00e0 l'aide de attach, puis ex\u00e9cuter une requ\u00eate alter. Ensuite, vous pourrez soit copier ou d\u00e9placer ces donn\u00e9es et faire un attach \u00e0 nouveau, soit utiliser une requ\u00eate. <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>Maintenant, la deuxi\u00e8me question \u2014 peut-on utiliser Btrfs ? Pour commencer, si vous avez LVM, il suffit des snapshots LVM, et le syst\u00e8me de fichiers peut \u00eatre ext4, cela n'a pas d'importance. Pour Btrfs, tout d\u00e9pend de votre exp\u00e9rience de son utilisation. C'est un syst\u00e8me de fichiers mature, mais il reste des doutes sur son fonctionnement en pratique dans un sc\u00e9nario sp\u00e9cifique. Je ne conseillerais pas de l'utiliser si vous n'avez pas Btrfs en production.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-best-practicesanchorkakie-seychas-luchshie-praktiki-vnbspreshardinge-dannyh\"><noindex><a rel=\"nofollow\" name=\"resharding-best-practices\"><\/a><\/noindex>Quelles sont les meilleures pratiques actuelles en mati\u00e8re de r\u00e9partition des donn\u00e9es ?<\/h2>\n<p><\/p>\n<p>La question du resharding est complexe et multidimensionnelle. On peut y r\u00e9pondre de plusieurs mani\u00e8res. D'une part, on pourrait dire que ClickHouse n'a pas de fonctionnalit\u00e9 int\u00e9gr\u00e9e de resharding. Mais j'ai peur que cette r\u00e9ponse ne convienne \u00e0 personne. Donc, on peut aborder cela sous un autre angle et dire qu'il existe plusieurs fa\u00e7ons de resharder des donn\u00e9es dans ClickHouse. <\/p>\n<p><\/p>\n<p>Si l'espace sur le cluster est \u00e9puis\u00e9 ou s'il ne supporte plus la charge, vous ajoutez de nouveaux serveurs. Mais ces serveurs sont vides par d\u00e9faut, il n'y a pas de donn\u00e9es dessus, et aucune charge n'est appliqu\u00e9e. Vous devez transf\u00e9rer des donn\u00e9es pour qu'elles soient uniform\u00e9ment r\u00e9parties sur le nouveau cluster agrandi.<\/p>\n<p><\/p>\n<p>La premi\u00e8re m\u00e9thode pour le faire consiste \u00e0 copier certaines partitions sur les nouveaux serveurs \u00e0 l'aide d'une requ\u00eate. <strong>alter table fetch partition<\/strong>Par exemple, si vous aviez des partitions par mois, vous prenez le premier mois de 2017 et le copiez sur un nouveau serveur, puis vous copiez le troisi\u00e8me mois sur un autre nouveau serveur. Et vous continuez ainsi jusqu'\u00e0 ce que ce soit relativement \u00e9quilibr\u00e9.<\/p>\n<p><\/p>\n<p>Le transfert ne peut \u00eatre effectu\u00e9 que pour les partitions qui ne changent pas lors de l'\u00e9criture. Pour les nouvelles partitions, vous devrez d\u00e9sactiver l'\u00e9criture, car leur transfert n'est pas atomique. Sinon, vous obtiendrez des doublons ou des lacunes dans les donn\u00e9es. N\u00e9anmoins, cette m\u00e9thode est pratique et fonctionne assez efficacement. Les partitions compress\u00e9es pr\u00eates \u00e0 l'emploi sont transmises sur le r\u00e9seau, c'est-\u00e0-dire que les donn\u00e9es ne sont pas recompress\u00e9es ni reconverties.<\/p>\n<p><\/p>\n<p>Cette m\u00e9thode pr\u00e9sente un inconv\u00e9nient : elle d\u00e9pend de la strat\u00e9gie de sharding. Vous devez savoir si vous avez bas\u00e9 votre sch\u00e9ma de sharding sur celle-ci et quelle cl\u00e9 de sharding vous avez utilis\u00e9e. Dans votre exemple pour le cas des m\u00e9triques, la cl\u00e9 de sharding est le hash du chemin. Lorsque vous effectuez une s\u00e9lection dans une table Distributed, cela se fait directement sur tous les shards du cluster pour r\u00e9cup\u00e9rer les donn\u00e9es. <\/p>\n<p><\/p>\n<p>Cela signifie qu'en r\u00e9alit\u00e9, il n'a pas d'importance pour vous quels sont les donn\u00e9es qui se trouvent sur quel shard. L'essentiel est que les donn\u00e9es correspondant \u00e0 un m\u00eame chemin se trouvent sur un shard unique, peu importe lequel. Dans ce cas, le transfert de partitions pr\u00eates est tout \u00e0 fait ad\u00e9quat, car lors des s\u00e9lections, vous obtiendrez \u00e9galement des donn\u00e9es compl\u00e8tes, que ce soit avant ou apr\u00e8s le resharding, la structure n'a pas d'importance.<\/p>\n<p><\/p>\n<p>Cependant, il existe des cas plus complexes. Si au niveau de la logique de l'application vous partez d'un sch\u00e9ma de sharding sp\u00e9cifique, o\u00f9 ce client est situ\u00e9 sur un certain shard, vous pouvez envoyer la requ\u00eate directement l\u00e0-bas, au lieu d'aller dans une table Distributed. Ou vous utilisez une version assez r\u00e9cente de ClickHouse et avez activ\u00e9 le param\u00e8tre. <strong>optimize skip unused shards<\/strong>. Dans ce cas, lors de la requ\u00eate de s\u00e9lection, l'expression dans la clause where sera analys\u00e9e, et il sera d\u00e9termin\u00e9 sur quels shards aller selon le sch\u00e9ma de sharding. Cela fonctionne \u00e0 condition que les donn\u00e9es soient r\u00e9ellement dispos\u00e9es selon ce sch\u00e9ma de sharding. Si vous les avez r\u00e9organis\u00e9es manuellement, la correspondance peut changer.<\/p>\n<p><\/p>\n<p>Donc, c'est la premi\u00e8re m\u00e9thode. J'attends votre retour pour savoir si cela vous convient ou si nous allons plus loin.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev, administrateur syst\u00e8me principal chez Avito<\/strong>: Alexey, la m\u00e9thode que vous avez mentionn\u00e9e ne fonctionne pas tr\u00e8s bien lorsqu'il s'agit de r\u00e9partir la charge, y compris lors des lectures. Nous pouvons prendre une partition mensuelle et d\u00e9placer le mois pr\u00e9c\u00e9dent vers un autre n\u0153ud, mais lorsque la requ\u00eate pour ces donn\u00e9es arrive, nous ne chargerons que celui-ci. Nous aimerions r\u00e9partir la charge sur l'ensemble du cluster, car autrement, pendant un certain temps, toute la charge des lectures sera g\u00e9r\u00e9e par deux shards.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> La r\u00e9ponse ici est \u00e9trange : oui, c'est mauvais, mais cela pourrait fonctionner. Je vais expliquer comment. Il faut examiner le sc\u00e9nario de charge qui s'applique \u00e0 vos donn\u00e9es. Si ce sont des donn\u00e9es de surveillance, il est presque certain que la majorit\u00e9 des requ\u00eates portent sur des donn\u00e9es r\u00e9centes. <\/p>\n<p><\/p>\n<p>Vous avez install\u00e9 de nouveaux serveurs, transf\u00e9r\u00e9 d'anciennes partitions, mais vous avez \u00e9galement modifi\u00e9 la fa\u00e7on dont les nouvelles donn\u00e9es sont \u00e9crites. Et les nouvelles donn\u00e9es seront r\u00e9parties sur tout le cluster. Ainsi, d\u00e8s cinq minutes, les requ\u00eates des cinq derni\u00e8res minutes chargeront uniform\u00e9ment le cluster, et dans un jour, les requ\u00eates sur les derni\u00e8res 24 heures chargeront \u00e9galement le cluster de mani\u00e8re \u00e9quitable. Malheureusement, les requ\u00eates du mois pr\u00e9c\u00e9dent ne seront distribu\u00e9es que sur une partie des serveurs du cluster.<\/p>\n<p><\/p>\n<p>Mais souvent, vous n'aurez pas de requ\u00eates pour f\u00e9vrier 2019. Il est plus probable que si des requ\u00eates viennent de 2019, elles concernent l'ensemble de l'ann\u00e9e 2019 \u2014 un large intervalle de temps, et non une petite plage. Et ces types de requ\u00eates pourront \u00e9galement charger uniform\u00e9ment le cluster. Mais en g\u00e9n\u00e9ral, votre remarque est tout \u00e0 fait correcte, c\u2019est une solution ad hoc qui ne r\u00e9partit pas compl\u00e8tement les donn\u00e9es de mani\u00e8re uniforme.<\/p>\n<p><\/p>\n<p>J'ai encore quelques points \u00e0 aborder pour r\u00e9pondre \u00e0 la question. L'un d'eux concerne la mani\u00e8re de cr\u00e9er initialement le sch\u00e9ma de sharding de mani\u00e8re \u00e0 r\u00e9duire la douleur li\u00e9e au resharding. Ce n'est pas toujours possible.<\/p>\n<p><\/p>\n<p>Par exemple, vous avez des donn\u00e9es de surveillance. Les donn\u00e9es de surveillance augmentent pour trois raisons. La premi\u00e8re est l'accumulation de donn\u00e9es historiques. La seconde est la croissance du trafic. Et la troisi\u00e8me est l'augmentation du nombre d'\u00e9l\u00e9ments \u00e0 surveiller. De nouveaux microservices et des m\u00e9triques doivent \u00eatre conserv\u00e9s. <\/p>\n<p><\/p>\n<p>Il est possible que la plus forte augmentation soit li\u00e9e \u00e0 la troisi\u00e8me raison \u2014 l'augmentation de l'utilisation de la surveillance. Dans ce cas, il est pertinent d'examiner la nature de la charge, quels sont les principales requ\u00eates de s\u00e9lection. Les principales requ\u00eates de s\u00e9lection viendront probablement d'un certain sous-ensemble de m\u00e9triques.<\/p>\n<p><\/p>\n<p>Par exemple, l'utilisation du CPU sur certains serveurs par un certain service. Il existe un sous-ensemble de cl\u00e9s \u00e0 partir desquelles vous r\u00e9cup\u00e9rez ces donn\u00e9es. Et la requ\u00eate pour ces donn\u00e9es est probablement assez simple et s'ex\u00e9cute en quelques dizaines de millisecondes. Cela est utilis\u00e9 pour les services de surveillance, pour les tableaux de bord. J'esp\u00e8re que je le comprends correctement.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Le fait est que nous faisons souvent appel \u00e0 des donn\u00e9es historiques, car nous comparons en temps r\u00e9el la situation actuelle avec l'historique. Il est donc important pour nous d'avoir un acc\u00e8s rapide \u00e0 un grand volume de donn\u00e9es, et ClickHouse s'en charge parfaitement.<\/p>\n<p><\/p>\n<p>Vous avez tout \u00e0 fait raison, la plupart des requ\u00eates de lecture que nous traitons proviennent des derni\u00e8res 24 heures, comme toute autre syst\u00e8me de surveillance. Cependant, la charge sur les donn\u00e9es historiques est \u00e9galement assez lourde. Elle provient surtout du syst\u00e8me d'alerte qui, toutes les trente secondes, interroge ClickHouse : \u00ab Donne-moi les donn\u00e9es des six derni\u00e8res semaines. Maintenant, construis-moi une sorte de moyenne glissante \u00e0 partir de celles-ci, et comparons la valeur actuelle \u00e0 l'historique. \u00bb <\/p>\n<p><\/p>\n<p>Je tiens \u00e0 dire qu'il existe une petite table pour ces requ\u00eates tr\u00e8s r\u00e9centes, dans laquelle nous stockons uniquement deux jours de donn\u00e9es, et les principales requ\u00eates y sont envoy\u00e9es. Nous n'exp\u00e9dions les grandes requ\u00eates historiques que vers une vaste table shard\u00e9e.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Malheureusement, cela ne s'applique pas bien \u00e0 votre sc\u00e9nario, mais je vais vous d\u00e9crire deux sch\u00e9mas de sharding mauvais et compliqu\u00e9s, qu'il ne faut pas utiliser, mais qui sont toutefois employ\u00e9s par les services de mes amis. <\/p>\n<p><\/p>\n<p>Il y a un cluster principal avec des \u00e9v\u00e9nements \u00ab Yandex.Metrica \u00bb. Les \u00e9v\u00e9nements sont des vues de pages, des clics et des transitions. La plupart des requ\u00eates concernent un site web sp\u00e9cifique. Vous ouvrez le service \u00ab Yandex.Metrica \u00bb, vous avez un site - avito.ru, vous acc\u00e9dez au rapport, et une requ\u00eate est faite pour votre site.<\/p>\n<p><\/p>\n<p>Mais il existe aussi d'autres requ\u00eates - analytiques et globales, r\u00e9alis\u00e9es par les analystes internes. \u00c0 titre d'information, je pr\u00e9cise que les analystes internes effectuent des requ\u00eates uniquement sur les services de Yandex. Cependant, m\u00eame les services de Yandex repr\u00e9sentent une part importante de toutes les donn\u00e9es. Ce sont des requ\u00eates non pas sur des compteurs sp\u00e9cifiques, mais selon une filtration plus large.<\/p>\n<p><\/p>\n<p>Comment organiser les donn\u00e9es de mani\u00e8re \u00e0 ce qu'elles fonctionnent efficacement \u00e0 la fois pour un seul compteur et pour les requ\u00eates globales ? La difficult\u00e9 r\u00e9side \u00e9galement dans le fait que le nombre de requ\u00eates dans ClickHouse pour le cluster \u00ab Metrica \u00bb atteint plusieurs milliers par seconde. De plus, des requ\u00eates non triviales, par exemple, un serveur ClickHouse ne peut pas supporter plusieurs milliers de requ\u00eates par seconde.<\/p>\n<p><\/p>\n<p>La taille du cluster est d'environ six cents serveurs. Si l'on superpose simplement une table distribu\u00e9e sur ce cluster et que l'on envoie plusieurs milliers de requ\u00eates, cela sera encore pire que de les envoyer \u00e0 un seul serveur. D'un autre c\u00f4t\u00e9, si les donn\u00e9es sont r\u00e9parties uniform\u00e9ment et que nous faisons des requ\u00eates sur tous les serveurs, cela n'est pas une solution viable non plus.<\/p>\n<p><\/p>\n<p>Il existe une approche diam\u00e9tralement oppos\u00e9e. Imaginez que nous shardons les donn\u00e9es par sites, ce qui signifie qu'une requ\u00eate pour un site ira vers un seul shard. Maintenant, le cluster peut g\u00e9rer dix mille requ\u00eates par seconde, mais sur un shard, une seule requ\u00eate pourrait \u00eatre tr\u00e8s lente. Elle ne pourra plus se scalper en capacit\u00e9. Surtout si c'est le site avito.ru. Je ne vais pas r\u00e9v\u00e9ler un secret en disant qu'Avito est l'un des sites les plus visit\u00e9s du Runet. Traiter ce site sur un seul shard serait insens\u00e9.<\/p>\n<p><\/p>\n<p>Ainsi, le sch\u00e9ma de sharding est con\u00e7u de mani\u00e8re plus intelligente. L'ensemble du cluster est divis\u00e9 en un certain nombre de sous-clusters que nous appelons des couches. \u00c0 l'int\u00e9rieur de chaque sous-cluster, il y a de dix \u00e0 plusieurs dizaines de shards. Et il y a au total trente-neuf de ces sous-clusters. <\/p>\n<p><\/p>\n<p>Comment tout cela se met-il \u00e0 l'\u00e9chelle ? Le nombre de sous-clusters ne change pas \u2014 il y a toujours trente-neuf comme il y a quelques ann\u00e9es. Mais \u00e0 l'int\u00e9rieur de chacun d'eux, nous augmentons progressivement le nombre de shards \u00e0 mesure que les donn\u00e9es s'accumulent. Le principe de sharding dans son ensemble est le suivant : la division en ces sous-clusters se fait par sites web, et pour savoir quel site appartient \u00e0 quel cluster, une base de donn\u00e9es distincte est utilis\u00e9e dans MySQL. Un site \u2014 un sous-cluster. \u00c0 l'int\u00e9rieur, le sharding se fait par identifiants de visiteurs.<\/p>\n<p><\/p>\n<p>Lors de l'enregistrement, nous les partageons selon le reste de la division de l'identifiant du visiteur. Mais lorsque nous ajoutons un nouveau shard, le sch\u00e9ma de sharding change ; nous continuons \u00e0 partager, mais selon le reste de la division par un autre nombre. Cela signifie qu'un visiteur peut se retrouver sur plusieurs serveurs, et nous ne pouvons pas compter l\u00e0-dessus. Cela a \u00e9t\u00e9 fait uniquement pour permettre une meilleure compression des donn\u00e9es. Lors des requ\u00eates, nous utilisons la table Distributed, qui examine le cluster et consulte des dizaines de serveurs. Voil\u00e0 un sch\u00e9ma un peu absurde.<\/p>\n<p><\/p>\n<p>Mais mon histoire serait incompl\u00e8te si je ne disais pas que nous avons abandonn\u00e9 ce sch\u00e9ma. Dans le nouveau sch\u00e9ma, nous avons tout modifi\u00e9 et toutes les donn\u00e9es ont \u00e9t\u00e9 copi\u00e9es \u00e0 l'aide de clickhouse-copier.<\/p>\n<p><\/p>\n<p>Dans le nouveau sch\u00e9ma, tous les sites sont class\u00e9s en deux cat\u00e9gories : grands et petits. Je ne sais pas comment le seuil a \u00e9t\u00e9 d\u00e9termin\u00e9, mais au final, les grands sites sont enregistr\u00e9s sur un seul cluster, o\u00f9 il y a 120 shards avec trois r\u00e9pliques pour chacun, soit 360 serveurs au total. Le sch\u00e9ma de sharding est tel que toute requ\u00eate est directement envoy\u00e9e \u00e0 tous les shards. Si vous ouvrez une page de rapport pour avito.ru dans \u00ab Yandex.Metrica \u00bb, la requ\u00eate se dirigera vers 120 serveurs. Il y a peu de grands sites dans le Runet. Au final, les requ\u00eates ne s'\u00e9l\u00e8vent pas \u00e0 mille par seconde, mais m\u00eame moins d'une centaine. Tout cela est tranquillement trait\u00e9 par la table Distributed, qui est g\u00e9r\u00e9e par 120 serveurs.<\/p>\n<p><\/p>\n<p>Le deuxi\u00e8me cluster est destin\u00e9 aux petits sites. Ici, le sch\u00e9ma de sharding est bas\u00e9 sur l'identifiant du site, et chaque requ\u00eate est dirig\u00e9e vers un seul shard.<\/p>\n<p><\/p>\n<h2 id=\"anchorclickhouse-copieranchorv-clickhouse-est-utilita-clickhouse-copier-mozhete-pronbspneyo-rasskazat\"><noindex><a rel=\"nofollow\" name=\"clickhouse-copier\"><\/a><\/noindex>ClickHouse dispose d'un utilitaire nomm\u00e9 clickhouse-copier. Pouvez-vous en parler ?<\/h2>\n<p><\/p>\n<p>Je dois dire que cette solution est plus encombrante et l\u00e9g\u00e8rement moins performante. L'avantage est qu'elle r\u00e9partit compl\u00e8tement les donn\u00e9es selon le sch\u00e9ma que vous indiquerez. Mais le d\u00e9savantage de l'outil est qu'il ne r\u00e9alise pas de re-sharding. Il copie les donn\u00e9es d'un sch\u00e9ma de cluster \u00e0 un autre.<\/p>\n<p><\/p>\n<p>Cela signifie que, pour son fonctionnement, vous devez disposer de deux clusters. Ils peuvent \u00eatre situ\u00e9s sur les m\u00eames serveurs, mais n\u00e9anmoins, les donn\u00e9es ne seront pas d\u00e9plac\u00e9es de mani\u00e8re incr\u00e9mentale, mais seront copi\u00e9es. <\/p>\n<p><\/p>\n<p>Par exemple, il y avait quatre serveurs, maintenant il y en a huit. Vous cr\u00e9ez une nouvelle table Distributed sur tous les serveurs, de nouvelles tables locales et lancez clickhouse-copier en sp\u00e9cifiant le sch\u00e9ma de fonctionnement, qui doit lire depuis l\u00e0, accepter le nouveau sch\u00e9ma de sharding et transf\u00e9rer les donn\u00e9es. Vous aurez besoin d'un espace sur les anciens serveurs qui est un peu plus d'une fois et demie ce qu'il y a actuellement, car les anciennes donn\u00e9es doivent y rester, et par-dessus cela, une moiti\u00e9 de ces m\u00eames anciennes donn\u00e9es arrivera. Si vous avez pens\u00e9 \u00e0 l'avance \u00e0 ce que les donn\u00e9es doivent \u00eatre resharn\u00e9es et qu'il y a de l'espace, alors cette m\u00e9thode conviendra.<\/p>\n<p><\/p>\n<p>Comment fonctionne clickhouse-copier en interne ? Il divise tout le travail en un ensemble de t\u00e2ches pour le traitement d'une partition d'une table sur un shard. Toutes ces t\u00e2ches peuvent s'ex\u00e9cuter en parall\u00e8le, et clickhouse-copier peut \u00eatre lanc\u00e9 sur diff\u00e9rentes machines en plusieurs instances, mais ce qu'il fait pour une partition est tout simplement un insert select. Les donn\u00e9es sont lues, d\u00e9compress\u00e9es, redistribu\u00e9es, puis \u00e0 nouveau compress\u00e9es et \u00e9crites quelque part, re-tri\u00e9es. C'est une solution plus lourde.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-toolanchoru-vas-byla-pilotnaya-shtuka-kotoraya-nazyvalas-resharding-chto-snbspney\"><noindex><a rel=\"nofollow\" name=\"resharding-tool\"><\/a><\/noindex>Vous aviez un projet pilote appel\u00e9 r\u00e9partition. Que s'est-il pass\u00e9 ?<\/h2>\n<p><\/p>\n<blockquote><p>Vous aviez d\u00e9j\u00e0 une version pilote en 2017, qui s'appelait resharding. Il y a m\u00eame une option dans ClickHouse. Je crois comprendre que cela n'a pas pris. Pouvez-vous nous dire pourquoi cela s'est pass\u00e9 ? Cela semble pourtant tr\u00e8s pertinent.<\/p><\/blockquote>\n<p>Tout le probl\u00e8me est que lorsque le resharding des donn\u00e9es est n\u00e9cessaire, il faut une synchronisation assez complexe pour le faire de mani\u00e8re atomique. Quand nous avons commenc\u00e9 \u00e0 examiner comment cette synchronisation est organis\u00e9e, il est devenu \u00e9vident qu'il y a des probl\u00e8mes fondamentaux. Et ces probl\u00e8mes fondamentaux ne sont pas seulement th\u00e9oriques, mais se manifestent imm\u00e9diatement dans la pratique par quelque chose de tr\u00e8s simple \u00e0 expliquer : rien ne fonctionne.<\/p>\n<p><\/p>\n<h2 id=\"anchormove-to-slow-diskanchormozhno-li-slivat-vse-chasti-dannyh-voedino-perednbspperemescheniem-nanbspmedlennye-diski\"><noindex><a rel=\"nofollow\" name=\"move-to-slow-disk\"><\/a><\/noindex>Est-il possible de fusionner toutes les parties des donn\u00e9es avant de les transf\u00e9rer sur des disques lents ?<\/h2>\n<p><\/p>\n<blockquote><p>Une question sur le TTL avec l'option d\u00e9placer vers un disque lent dans le contexte des fusions. Y a-t-il un moyen, autre que par cron, de fusionner toutes les parties en une seule avant de les d\u00e9placer vers des disques lents ?<\/p><\/blockquote>\n<p>La r\u00e9ponse \u00e0 la question de savoir s'il est possible de fusionner automatiquement toutes les pi\u00e8ces en une avant leur transfert est non. Il me semble qu'il n'est pas n\u00e9cessaire de le faire. Vous pouvez ne pas fusionner toutes les parties en une seule, mais simplement compter sur le fait qu'elles seront transf\u00e9r\u00e9es sur des disques lents automatiquement. <\/p>\n<p><\/p>\n<p>Nous avons deux crit\u00e8res pour le d\u00e9placement. Le premier est bas\u00e9 sur le taux d'occupation. Si le niveau de stockage actuel a moins d'un certain pourcentage d'espace libre, nous s\u00e9lectionnons une partie et la transf\u00e9rons vers un stockage plus lent. En r\u00e9alit\u00e9, ce n'est pas un stockage plus lent, mais le suivant \u2014 selon votre configuration.<\/p>\n<p><\/p>\n<p>Le deuxi\u00e8me crit\u00e8re est bas\u00e9 sur la taille. Il concerne le d\u00e9placement de grandes portions. Vous pouvez ajuster le seuil d'espace libre sur le disque rapide, et les donn\u00e9es seront transf\u00e9r\u00e9es automatiquement.<\/p>\n<p><\/p>\n<h2 id=\"anchorup-to-dateanchorkak-pereezzhat-nanbspnovye-versii-clickhouse-esli-net-vozmozhnosti-zaranee-proverit-sovmestimost\"><noindex><a rel=\"nofollow\" name=\"up-to-date\"><\/a><\/noindex>Comment passer \u00e0 de nouvelles versions de ClickHouse si je ne peux pas v\u00e9rifier la compatibilit\u00e9 \u00e0 l'avance ?<\/h2>\n<p><\/p>\n<blockquote><p>Ce sujet est r\u00e9guli\u00e8rement discut\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/teleg.run\/clickhouse_ru\">dans le chat Telegram ClickHouse<\/a><\/noindex> en tenant compte des diff\u00e9rentes versions, et pourtant. Quelle est la s\u00e9curit\u00e9 d'une mise \u00e0 jour de la version 19.11 \u00e0 19.16 et, par exemple, de 19.16 \u00e0 20.3 ? Comment se d\u00e9placer vers de nouvelles versions sans avoir la possibilit\u00e9 de v\u00e9rifier la compatibilit\u00e9 dans un bac \u00e0 sable?<\/p><\/blockquote>\n<p>Il y a quelques r\u00e8gles d'or. La premi\u00e8re \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">lisez le changelog<\/a><\/noindex>. C'est volumineux, mais il y a des sections distinctes concernant les changements incompatibles avec les versions pr\u00e9c\u00e9dentes. Il ne faut pas consid\u00e9rer ces points comme un drapeau rouge. En g\u00e9n\u00e9ral, il s'agit de petites incompatibilit\u00e9s li\u00e9es \u00e0 certaines caract\u00e9ristiques marginales, qui, tr\u00e8s probablement, ne sont pas utilis\u00e9es chez vous.<\/p>\n<p><\/p>\n<p>Deuxi\u00e8me r\u00e8gle \u2014 s'il n'est pas possible de v\u00e9rifier la compatibilit\u00e9 dans un bac \u00e0 sable, et que vous souhaitez mettre \u00e0 jour directement en production, la recommandation est la suivante \u2014 ne le faites pas. Cr\u00e9ez d'abord un bac \u00e0 sable et testez. S'il n'y a pas d'environnement de test, il est probable que votre entreprise ne soit pas tr\u00e8s grande, donc vous pouvez copier une partie des donn\u00e9es sur votre ordinateur portable et v\u00e9rifier que tout fonctionne correctement. Vous pouvez m\u00eame lancer plusieurs r\u00e9pliques localement sur votre machine. Ou vous pouvez lever une nouvelle version quelque part \u00e0 proximit\u00e9 et y charger une partie des donn\u00e9es \u2014 c'est-\u00e0-dire cr\u00e9er un environnement de test improvis\u00e9. <\/p>\n<p><\/p>\n<p>Une autre r\u00e8gle \u2014 ne pas mettre \u00e0 jour durant une semaine apr\u00e8s la sortie d'une version \u00e0 cause de la collecte de bogues en production et des corrections rapides qui suivent. Examinons la num\u00e9rotation des versions ClickHouse pour ne pas se tromper. <\/p>\n<p><\/p>\n<p>Il existe une version 20.3.4. Le chiffre 20&nbsp;indique l'ann\u00e9e de sortie&nbsp;\u2014 2020. En ce qui concerne ce qui se trouve \u00e0 l'int\u00e9rieur, cela n'a pas vraiment d'importance, alors nous ne nous attarderons pas l\u00e0-dessus. Ensuite&nbsp;\u2014 20.3. Le deuxi\u00e8me chiffre&nbsp;\u2014 dans ce cas 3 \u2014 augmente chaque fois que nous publions une version avec une nouvelle fonctionnalit\u00e9. Si nous voulons ajouter une fonctionnalit\u00e9 dans ClickHouse, nous devons augmenter ce chiffre. Cela signifie que dans la version 20.4, ClickHouse fonctionnera encore mieux. Le troisi\u00e8me chiffre&nbsp;\u2014 20.3.4. Ici, 4 repr\u00e9sente le nombre de mises \u00e0 jour de correctifs, o\u00f9 nous n'avons pas ajout\u00e9 de nouvelles fonctionnalit\u00e9s, mais avons corrig\u00e9 des bogues. Et 4&nbsp;indique que nous avons fait cela quatre fois.<\/p>\n<p><\/p>\n<p>Il ne faut pas penser que c'est quelque chose de terrible. En g\u00e9n\u00e9ral, l'utilisateur peut installer la version la plus r\u00e9cente, et elle fonctionnera sans&nbsp;probl\u00e8mes pendant un an. Mais imaginez qu'avec une certaine fonction de traitement des bitmap, ajout\u00e9e par nos coll\u00e8gues chinois, le serveur plante lorsqu'on passe de mauvais arguments. Nous devons corriger cela. Nous publierons une nouvelle version de correctif, et ClickHouse deviendra plus stable.<\/p>\n<p><\/p>\n<p>Si ClickHouse fonctionne en production chez vous, et qu'une nouvelle version de ClickHouse avec des fonctionnalit\u00e9s suppl\u00e9mentaires sort \u2014 par exemple, 20.4.1 \u2014 ne soyez pas press\u00e9 de l'installer en production le jour m\u00eame. \u00c0 quoi bon? Si vous n'utilisez pas encore ClickHouse, vous pouvez l'installer, et tout ira probablement bien. Mais si ClickHouse fonctionne d\u00e9j\u00e0 de mani\u00e8re stable, surveillez les correctifs et les mises \u00e0 jour&nbsp;\u2014 quels probl\u00e8mes nous corrigeons.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov :<\/strong> Je voudrais ajouter un peu sur les environnements de test. Tout le monde craint les environnements de test et consid\u00e8re \u00e9trangement que si vous avez un tr\u00e8s grand cluster ClickHouse, alors l'environnement de test doit \u00eatre au moins aussi grand ou au moins dix fois plus petit. Ce n'est pas du tout le cas.<\/p>\n<p><\/p>\n<p>Je peux parler de mon exp\u00e9rience. J'ai un projet, et il y a ClickHouse. Notre environnement de test pour cela&nbsp;\u2014 c'est une petite machine virtuelle chez Hetzner pour vingt euros, o\u00f9 tout est d\u00e9ploy\u00e9. Pour cela, nous avons une automatisation compl\u00e8te en Ansible, donc il n'y a fondamentalement aucune diff\u00e9rence, que ce soit sur des serveurs physiques ou simplement d\u00e9ploy\u00e9s dans des machines virtuelles.<\/p>\n<p><\/p>\n<p>Que peut-on faire ? Il serait utile d'inclure dans la documentation de ClickHouse un exemple de d\u00e9ploiement d'un petit cluster chez soi \u2014 dans Docker, dans LXC, peut-\u00eatre m\u00eame de cr\u00e9er un playbook Ansible, car les d\u00e9ploiements varient d'une personne \u00e0 l'autre. Cela faciliterait beaucoup les choses. Quand on peut d\u00e9ployer un cluster en cinq minutes, c'est bien plus simple d'essayer de comprendre certaines choses. C'est beaucoup plus pratique, car d\u00e9ployer en production une version que vous n'avez pas test\u00e9e \u2014 c'est une voie sans issue. Parfois \u00e7a marche, et parfois non. Esp\u00e9rer un succ\u00e8s dans ce cas est donc peu judicieux.<\/p>\n<p><\/p>\n<p><strong>Maxim Kotyakov, ing\u00e9nieur backend senior chez Avito :<\/strong> Je vais ajouter quelques pr\u00e9cisions sur les environnements de test, issus de probl\u00e8mes rencontr\u00e9s par de grandes entreprises. Nous disposons d'un cluster ClickHouse de validation, qui est une copie exacte, tant des sch\u00e9mas de donn\u00e9es que des configurations, de ce qui se trouve en production. Ce cluster est d\u00e9ploy\u00e9 dans des conteneurs assez limit\u00e9s niveau ressources. Nous y \u00e9crivons un certain pourcentage des donn\u00e9es de production, fort heureusement, nous avons la possibilit\u00e9 de r\u00e9pliquer un flux dans Kafka. Tout est synchronis\u00e9 et scal\u00e9 \u2014 tant en puissance qu'en flux, et th\u00e9oriquement, \u00e0 conditions \u00e9gales, cela devrait se comporter comme la production sur les m\u00e9triques. Tout ce qui est potentiellement explosif est d'abord test\u00e9 sur cette infrastructure et reste l\u00e0 plusieurs jours jusqu'\u00e0 ce qu'il soit pr\u00eat. Naturellement, cette solution co\u00fbte cher, est complexe et engendre des frais de maintenance non n\u00e9gligeables. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Je vais vous parler de l'environnement de test de nos amis de Yandex.Metrica. Un cluster comptait plus de 600 serveurs, un autre 360, et il y a encore un troisi\u00e8me cluster et plusieurs autres. L'environnement de test pour l'un d'eux est simplement constitu\u00e9 de deux shards avec deux r\u00e9pliques chacun. Pourquoi deux shards ? Pour qu'il n'y en ait pas qu'un. Et des r\u00e9pliques \u00e9galement, pour en avoir. C'est juste un minimum que l'on peut se permettre.<\/p>\n<p><\/p>\n<p>Cet environnement de test permet de v\u00e9rifier la fonctionnalit\u00e9 des requ\u00eates et de s'assurer qu'il n'y a pas eu de grandes d\u00e9faillances. Mais des probl\u00e8mes d'un autre type surviennent souvent, lorsque tout fonctionne, mais qu'il y a des changements mineurs sous charge.<\/p>\n<p><\/p>\n<p>Je vais donner un exemple. Nous avons d\u00e9cid\u00e9 d'installer une nouvelle version de ClickHouse. Elle a \u00e9t\u00e9 d\u00e9ploy\u00e9e dans un environnement de test, des tests automatis\u00e9s ont \u00e9t\u00e9 effectu\u00e9s dans \"Yandex.Metrica\", qui comparent les donn\u00e9es de l'ancienne version et de la nouvelle, en faisant passer tout le pipeline. Et bien s\u00fbr, les tests de notre CI sont pass\u00e9s avec succ\u00e8s. Sinon, nous n'aurions m\u00eame pas propos\u00e9 cette version.<\/p>\n<p><\/p>\n<p>Tout va bien. Nous commen\u00e7ons \u00e0 d\u00e9ployer en production. Je re\u00e7ois un message indiquant que la charge sur les graphiques a consid\u00e9rablement augment\u00e9. Nous revenons \u00e0 la version pr\u00e9c\u00e9dente. Je regarde le graphique et je vois : la charge a effectivement augment\u00e9 plusieurs fois au moment du d\u00e9ploiement, puis a diminu\u00e9 lorsque nous avons d\u00e9ploy\u00e9 la version pr\u00e9c\u00e9dente. Ensuite, nous avons commenc\u00e9 \u00e0 revenir \u00e0 la version ant\u00e9rieure. Et la charge a \u00e9galement augment\u00e9, puis a chut\u00e9 de la m\u00eame mani\u00e8re. Donc, la conclusion est que la charge a augment\u00e9 en raison du d\u00e9ploiement, rien d'\u00e9tonnant.<\/p>\n<p><\/p>\n<p>Plus tard, il a \u00e9t\u00e9 difficile de convaincre mes coll\u00e8gues d'installer la nouvelle version. Je dis : \u00ab Tout va bien, d\u00e9ployez-la. Croisez les doigts, tout fonctionnera. La charge a augment\u00e9 sur les graphiques, mais tout est normal. Tenez bon \u00bb. Bref, nous avons fait cela, et voil\u00e0 \u2014 la version est d\u00e9ploy\u00e9e en production. Mais \u00e0 chaque d\u00e9ploiement, des probl\u00e8mes similaires apparaissent.<\/p>\n<p><\/p>\n<h2 id=\"anchorkill-queryanchorkill-query-dolzhen-ubivat-zaprosy-no-on-etogo-ne-delaet-pochemu\"><noindex><a rel=\"nofollow\" name=\"kill-query\"><\/a><\/noindex>Kill query devrait tuer les requ\u00eates, mais ce n'est pas le cas. Pourquoi ?<\/h2>\n<p><\/p>\n<blockquote><p>Un utilisateur, un analyste, est venu me voir et a cr\u00e9\u00e9 une requ\u00eate qui a paralys\u00e9 mon cluster ClickHouse. Une certaine n\u0153ud ou le cluster entier, selon la r\u00e9plique ou le shard o\u00f9 la requ\u00eate est tomb\u00e9e. Je vois que toutes les ressources CPU sur ce serveur sont \u00e0 la limite, tout est rouge. Pourtant, ClickHouse r\u00e9pond aux requ\u00eates. Et j'\u00e9crit : \u00ab Montre-moi, s'il te pla\u00eet, la liste des processus, quelle requ\u00eate a provoqu\u00e9 cette folie \u00bb.<\/p>\n<p>Je trouve cette requ\u00eate et je tape kill. Et je vois que rien ne se passe. Mon serveur est \u00e0 la limite, ClickHouse continue de me renvoyer des commandes, montrant que le serveur est vivant et tout va bien. Mais j'ai une d\u00e9gradation sur toutes les requ\u00eates utilisateurs, la d\u00e9gradation commence sur l'\u00e9criture dans ClickHouse, et mon kill query ne fonctionne pas. Pourquoi ? Je pensais que kill query devait tuer les requ\u00eates, mais cela ne se produit pas.<\/p><\/blockquote>\n<p>La r\u00e9ponse sera plut\u00f4t \u00e9trange. En fait, kill query ne tue pas les requ\u00eates. <\/p>\n<p><\/p>\n<p>L'option Kill query active une petite case intitul\u00e9e \u00ab je veux que cette requ\u00eate soit tu\u00e9e \u00bb. Lors du traitement de chaque bloc, la requ\u00eate v\u00e9rifie cette case. Si elle est coch\u00e9e, la requ\u00eate s'arr\u00eate. Ainsi, personne ne tue la requ\u00eate, elle doit elle-m\u00eame tout v\u00e9rifier et s'arr\u00eater. Cela devrait fonctionner dans tous les cas o\u00f9 la requ\u00eate est en train de traiter des blocs de donn\u00e9es. Elle traitera le prochain bloc de donn\u00e9es, v\u00e9rifiera la case et s'arr\u00eatera.<\/p>\n<p><\/p>\n<p>Cela ne fonctionne pas dans les cas o\u00f9 la requ\u00eate est bloqu\u00e9e sur une op\u00e9ration. Cependant, ce n'est probablement pas votre cas, car, selon vos dires, elle utilise beaucoup de ressources serveur. Il est possible que cela ne fonctionne pas en cas de tri externe et dans certains autres d\u00e9tails. Mais dans l'ensemble, cela ne devrait pas arriver, c'est un bug. Et la seule chose que je peux vous conseiller est de mettre \u00e0 jour ClickHouse.<\/p>\n<p><\/p>\n<h2 id=\"anchorreading-timeanchorkak-rasschitat-vremya-otveta-pri-chitayuschey-nagruzke\"><noindex><a rel=\"nofollow\" name=\"reading-time\"><\/a><\/noindex>Comment calculer le temps de r\u00e9ponse sous charge de lecture ?<\/h2>\n<p><\/p>\n<blockquote><p>Il existe une table qui contient des agr\u00e9gats par item - diff\u00e9rents compteurs. Le nombre de lignes est d'environ cent millions. Peut-on s'attendre \u00e0 un temps de r\u00e9ponse pr\u00e9visible si l'on envoie 1K RPS pour 1K items ? <\/p><\/blockquote>\n<p>D'apr\u00e8s le contexte, il s'agit d'une charge de lecture, car pour l'\u00e9criture, il n'y a pas de probl\u00e8mes - on peut ins\u00e9rer mille, cent mille, et parfois m\u00eame plusieurs millions de lignes. <\/p>\n<p><\/p>\n<p>Les requ\u00eates de lecture peuvent varier consid\u00e9rablement. Avec select 1, ClickHouse peut ex\u00e9cuter environ des dizaines de milliers de requ\u00eates par seconde, donc m\u00eame des requ\u00eates avec une seule cl\u00e9 n\u00e9cessiteront des ressources. Et ces requ\u00eates ponctuelles seront plus compliqu\u00e9es que dans les bases de donn\u00e9es key-value, car pour chaque lecture, il faut lire un bloc de donn\u00e9es par index. L'index adresse non pas chaque enregistrement, mais chaque plage. Il faudra donc lire toute la plage - c'est 8192 lignes par d\u00e9faut. Et il faudra d\u00e9compresser le bloc de donn\u00e9es compress\u00e9 de 64 Ko \u00e0 1 Mo. En g\u00e9n\u00e9ral, de telles requ\u00eates ponctuelles prennent de quelques millisecondes \u00e0 quelques millisecondes. Mais c'est le sc\u00e9nario le plus simple.<\/p>\n<p><\/p>\n<p>Essayons de faire une simple arithm\u00e9tique. Si l'on multiplie plusieurs millisecondes par mille, cela donne quelques secondes. C'est comme si maintenir mille requ\u00eates par seconde n'\u00e9tait pas possible, mais en r\u00e9alit\u00e9, c'est faisable car nous avons plusieurs c\u0153urs de processeur. Donc, en principe, ClickHouse peut parfois supporter 1000 RPS, mais cela pour des requ\u00eates courtes, pr\u00e9cis\u00e9ment cibl\u00e9es.<\/p>\n<p><\/p>\n<p>Si vous devez faire \u00e9voluer un cluster ClickHouse en fonction du nombre de requ\u00eates simples, je recommande la solution la plus simple : augmenter le nombre de r\u00e9pliques et envoyer les requ\u00eates sur une r\u00e9plique al\u00e9atoire. Si une r\u00e9plique peut g\u00e9rer cinq cents requ\u00eates par seconde, ce qui est tout \u00e0 fait r\u00e9aliste, alors trois r\u00e9pliques pourront g\u00e9rer mille cinq cents.<\/p>\n<p><\/p>\n<p>Parfois, bien s\u00fbr, il est aussi possible de configurer ClickHouse pour maximiser le nombre de lectures cibl\u00e9es. Que faut-il pour cela ? D'abord, diminuer la granularit\u00e9 de l'index. Cependant, cela ne doit pas \u00eatre r\u00e9duit \u00e0 l'unit\u00e9, mais en consid\u00e9rant que le nombre d'enregistrements dans l'index sera de quelques millions ou dizaines de millions par serveur. Si la table compte cent millions de lignes, vous pouvez d\u00e9finir la granularit\u00e9 sur 64.<\/p>\n<p><\/p>\n<p>Vous pouvez r\u00e9duire la taille du bloc compress\u00e9. Pour cela, il existe des r\u00e9glages. <strong>min compress block size<\/strong>, <strong>max compress block size<\/strong>Vous pouvez les diminuer, recharger les donn\u00e9es, et alors les requ\u00eates cibl\u00e9es seront plus rapides. Mais malgr\u00e9 tout, ClickHouse n'est pas une base de donn\u00e9es key-value. Un grand nombre de petites requ\u00eates constitue un anti-pattern de charge.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov :<\/strong> Je vais donner un conseil au cas o\u00f9 il y aurait des compteurs ordinaires. C'est une situation assez standard lorsque ClickHouse conserve un certain compteur. J'ai un utilisateur, il vient d'un certain pays, un troisi\u00e8me champ, et il faut incr\u00e9menter quelque chose. Prenez MySQL, cr\u00e9ez une cl\u00e9 unique \u2014 en MySQL, c'est une cl\u00e9 dupliqu\u00e9e, et en PostgreSQL, c'est un conflit \u2014 et ajoutez avec un plus. Cela fonctionnera beaucoup mieux. <\/p>\n<p><\/p>\n<p>Quand vous avez peu de donn\u00e9es, il n'y a pas vraiment de sens \u00e0 utiliser ClickHouse. Il existe des bases de donn\u00e9es ordinaires qui g\u00e8rent cela tr\u00e8s bien. <\/p>\n<p><\/p>\n<h2 id=\"anchorpimp-my-clickhouseanchorchto-podtyunit-v-clickhouse-chtoby-bolshe-dannyh-bylo-vnbspkeshe\"><noindex><a rel=\"nofollow\" name=\"pimp-my-clickhouse\"><\/a><\/noindex>Que faut-il ajuster dans ClickHouse pour qu'il y ait plus de donn\u00e9es dans le cache ?<\/h2>\n<p><\/p>\n<blockquote><p>Imaginons la situation : sur les serveurs, il y a 256 Go de RAM, dans la routine quotidienne, ClickHouse utilise environ 60 \u00e0 80 Go, et au maximum \u2014 jusqu'\u00e0 130. Que pouvez-vous activer et ajuster pour qu'il y ait plus de donn\u00e9es dans le cache et, par cons\u00e9quent, moins d'acc\u00e8s au disque ?<\/p><\/blockquote>\n<p>En g\u00e9n\u00e9ral, le cache de page de l'op\u00e9ration syst\u00e8me g\u00e8re bien cette t\u00e2che. Si vous ouvrez simplement le top, regardez s'il y a cached ou free \u2014 il est \u00e9galement indiqu\u00e9 combien est mis en cache \u2014 vous pouvez remarquer que toute la m\u00e9moire libre est utilis\u00e9e pour le cache. Et ces donn\u00e9es, lors de la lecture, seront lues non pas depuis le disque, mais depuis la RAM. Je peux dire que le cache est utilis\u00e9 efficacement, car il met en cache des donn\u00e9es compress\u00e9es.<\/p>\n<p><\/p>\n<p>Cependant, si vous souhaitez encore acc\u00e9l\u00e9rer certaines requ\u00eates simples, il est possible d'activer le cache pour les donn\u00e9es non compress\u00e9es \u00e0 l'int\u00e9rieur de ClickHouse. Cela s'appelle <strong>uncompressed cache<\/strong>. Dans le fichier de configuration config.xml, vous d\u00e9finissez la taille du cache non compress\u00e9 \u00e0 la valeur requise \u2014 je recommande de ne pas d\u00e9passer la moiti\u00e9 de la RAM libre, car le reste sera destin\u00e9 au cache de page. <\/p>\n<p><\/p>\n<p>De plus, il existe deux param\u00e8tres au niveau de la requ\u00eate. Le premier param\u00e8tre est <strong>utiliser le cache non compress\u00e9<\/strong> \u2014 permet son utilisation. Il est recommand\u00e9 de l'activer pour toutes les requ\u00eates, sauf pour celles lourdes qui peuvent lire toutes les donn\u00e9es et vider ce cache. La deuxi\u00e8me configuration est une sorte de nombre maximum de lignes \u00e0 utiliser pour le cache. Cela limite automatiquement les grandes requ\u00eates pour qu'elles passent \u00e0 c\u00f4t\u00e9 du cache.<\/p>\n<p><\/p>\n<h2 id=\"anchorstorage-configurationanchorkak-mozhno-nastroit-storage_configuration-dlya-hraneniya-v-operativke\"><noindex><a rel=\"nofollow\" name=\"storage-configuration\"><\/a><\/noindex>Comment configurer storage_configuration pour un stockage en m\u00e9moire ?<\/h2>\n<p><\/p>\n<blockquote><p>Dans la nouvelle documentation de ClickHouse, j'ai trouv\u00e9 une section relative <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.tech\/docs\/en\/single\/#table_engine-mergetree-multiple-volumes\">avec le stockage des donn\u00e9es<\/a><\/noindex>. Dans la description, un exemple avec un SSD rapide est donn\u00e9. <\/p>\n<p>Il est int\u00e9ressant de savoir comment configurer la m\u00eame chose avec la m\u00e9moire vive volumineuse. Une autre question. Comment fonctionne le select avec cette organisation des donn\u00e9es, va-t-il lire l'ensemble de l'ensemble ou seulement celui qui est sur le disque, et les donn\u00e9es sont-elles compress\u00e9es en m\u00e9moire ? Et comment fonctionne la section prewhere avec cette organisation des donn\u00e9es ?<\/p><\/blockquote>\n<p>Cette configuration influence le stockage des morceaux de donn\u00e9es, et leur format ne change pas.<br \/>\nExaminons cela plus en d\u00e9tail. <\/p>\n<p><\/p>\n<p>Il est possible de configurer le stockage des donn\u00e9es en RAM. Tout ce qui est configur\u00e9 pour le disque \u2014 c'est son chemin. Vous cr\u00e9ez une partition tmpfs, qui est mont\u00e9e \u00e0 un certain chemin dans le syst\u00e8me de fichiers. Vous indiquez ce chemin comme le chemin de stockage des donn\u00e9es pour la partition la plus chaude, o\u00f9 commencent \u00e0 entrer et \u00e0 \u00eatre enregistr\u00e9s des morceaux de donn\u00e9es, tout va bien. <\/p>\n<p><\/p>\n<p>Mais je ne recommande pas de le faire en raison de la fiabilit\u00e9 limit\u00e9e, bien que si vous avez au moins trois r\u00e9pliques dans diff\u00e9rents centres de donn\u00e9es, c'est possible. En cas de probl\u00e8me, les donn\u00e9es peuvent \u00eatre restaur\u00e9es. Imaginez que le serveur soit soudainement \u00e9teint puis rallum\u00e9. La partition a \u00e9t\u00e9 remont\u00e9e, mais il n'y a rien. Le serveur ClickHouse au d\u00e9marrage constate que ces morceaux sont absents, bien que, selon les m\u00e9tadonn\u00e9es de ZooKeeper, ils devraient \u00eatre pr\u00e9sents. Il v\u00e9rifie sur quelles r\u00e9pliques elles se trouvent, les demande et les t\u00e9l\u00e9charge. De cette mani\u00e8re, les donn\u00e9es seront restaur\u00e9es. <\/p>\n<p><\/p>\n<p>Dans ce sens, le stockage des donn\u00e9es en m\u00e9moire vive ne diff\u00e8re pas fondamentalement de leur stockage sur disque, car lors de l'\u00e9criture des donn\u00e9es sur le disque, elles passent d'abord dans le cache des pages et s'\u00e9crivent physiquement de mani\u00e8re diff\u00e9r\u00e9e. Cela d\u00e9pend de l'option de montage du syst\u00e8me de fichiers. Mais pour \u00eatre s\u00fbr, je dirai que ClickHouse ne r\u00e9alise pas de fsync lors de l'insertion.<\/p>\n<p><\/p>\n<p>Les donn\u00e9es en m\u00e9moire sont stock\u00e9es dans le m\u00eame format que sur disque. La requ\u00eate select choisit de la m\u00eame mani\u00e8re les morceaux \u00e0 lire, s\u00e9lectionne les plages de donn\u00e9es n\u00e9cessaires dans les morceaux et les lit. Et prewhere fonctionne exactement de la m\u00eame mani\u00e8re, que les donn\u00e9es soient en m\u00e9moire ou sur disque.<\/p>\n<p><\/p>\n<h2 id=\"anchorlow-cardinalityanchordo-kakogo-kolichestva-unikalnyh-znacheniy-effektiven-low-cardinality\"><noindex><a rel=\"nofollow\" name=\"low-cardinality\"><\/a><\/noindex>Jusqu'\u00e0 quel nombre de valeurs uniques Low Cardinality est-il efficace ?<\/h2>\n<p><\/p>\n<p>Low Cardinality est astucieusement con\u00e7u. Il compose des dictionnaires de donn\u00e9es, mais ils sont locaux. Premi\u00e8rement, chaque morceau a ses propres dictionnaires, deuxi\u00e8mement, m\u00eame \u00e0 l'int\u00e9rieur d'un morceau, ils peuvent \u00eatre diff\u00e9rents pour chaque plage. Lorsque le nombre de valeurs uniques atteint un seuil \u2014 je crois que c'est un million \u2014 le dictionnaire est simplement retard\u00e9, et un nouveau est cr\u00e9\u00e9.<\/p>\n<p><\/p>\n<p>La r\u00e9ponse en g\u00e9n\u00e9ral : pour chaque plage locale \u2014 disons pour chaque jour \u2014 jusqu'\u00e0 environ un million de valeurs uniques, Low Cardinality est efficace. Au-del\u00e0, il y aura simplement un fallback, o\u00f9 plusieurs dictionnaires diff\u00e9rents seront utilis\u00e9s au lieu d'un seul. Cela fonctionnera \u00e0 peu pr\u00e8s comme une colonne de type string, peut-\u00eatre un peu moins efficace, mais il n'y aura pas de d\u00e9gradation s\u00e9rieuse des performances. <\/p>\n<p><\/p>\n<h2 id=\"anchorfulltext-searchanchorkakie-luchshie-praktiki-ponbsppolnotekstovomu-poisku-ponbsptablice-snbsppyatyu-milliardami-strok\"><noindex><a rel=\"nofollow\" name=\"fulltext-search\"><\/a><\/noindex>Quelles sont les meilleures pratiques pour la recherche textuelle dans une table contenant cinq milliards de lignes ?<\/h2>\n<p><\/p>\n<p>Il existe diff\u00e9rentes options de r\u00e9ponse. La premi\u00e8re est de dire que ClickHouse n'est pas un syst\u00e8me pour la recherche en texte int\u00e9gral. Pour cela, il existe des syst\u00e8mes sp\u00e9ciaux comme <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/enterprise-search\">Elasticsearch<\/a><\/noindex> et <noindex><a rel=\"nofollow\" href=\"http:\/\/sphinxsearch.com\/\">Sphinx<\/a><\/noindex>. Cependant, je rencontre de plus en plus de personnes qui disent qu'elles migrent d'Elasticsearch vers ClickHouse.<\/p>\n<p><\/p>\n<p>Pourquoi cela se produit-il ? Ils expliquent que l'Elasticsearch cesse de g\u00e9rer la charge \u00e0 partir de certains volumes, notamment en ce qui concerne la construction d'index. Les index deviennent trop volumineux, et si l'on transf\u00e8re simplement les donn\u00e9es dans ClickHouse, cela s'av\u00e8re beaucoup plus efficace en termes de volume. Par ailleurs, les requ\u00eates de recherche \u00e9taient souvent de sorte qu'il ne s'agissait pas de trouver une phrase dans l'ensemble des donn\u00e9es en tenant compte de la morphologie, mais de choses compl\u00e8tement diff\u00e9rentes. Par exemple, trouver dans les logs des derni\u00e8res heures une certaine sous-s\u00e9quence de bytes.<\/p>\n<p><\/p>\n<p>Dans ce cas, vous cr\u00e9ez un index dans ClickHouse, dont le premier champ sera la date et l'heure. Et le plus grand tranchage des donn\u00e9es se fera pr\u00e9cis\u00e9ment par la plage de dates. \u00c0 l'int\u00e9rieur de la plage de dates choisie, on peut g\u00e9n\u00e9ralement effectuer une recherche en texte int\u00e9gral m\u00eame par m\u00e9thode brute \u00e0 l'aide de like. L'op\u00e9rateur like dans ClickHouse est l'op\u00e9rateur like le plus efficace que vous puissiez trouver. Si vous en trouvez un meilleur, faites-le moi savoir. <\/p>\n<p><\/p>\n<p>Mais malgr\u00e9 tout, like est un full scan. Et un full scan peut \u00eatre lent non seulement au niveau CPU, mais aussi au niveau disque. Si par exemple vous avez un t\u00e9raoctet de donn\u00e9es par jour, et que vous recherchez un mot en une journ\u00e9e, vous devrez scanner un t\u00e9raoctet. Et celui-ci sera probablement sur des disques durs classiques, ce qui signifie qu'ils seront charg\u00e9s au point que vous ne pourrez pas acc\u00e9der \u00e0 ce serveur par SSH.<\/p>\n<p><\/p>\n<p>Dans ce cas, je suis pr\u00eat \u00e0 proposer une petite astuce suppl\u00e9mentaire. C'est dans le domaine exp\u00e9rimental - \u00e7a peut fonctionner ou non. Dans ClickHouse, il existe des index en texte int\u00e9gral sous forme de filtres de Bloom trigrammes. Nos coll\u00e8gues de l'entreprise Arenadata ont d\u00e9j\u00e0 test\u00e9 ces index, et ils fonctionnent souvent comme pr\u00e9vu.<\/p>\n<p><\/p>\n<p>Pour les utiliser correctement, il est essentiel de bien comprendre comment ils fonctionnent : ce qu'est un filtre de Bloom trigramme et comment choisir sa taille. Je peux dire qu'ils seront utiles pour des requ\u00eates sur des phrases rares, des sous-cha\u00eenes qui apparaissent rarement dans les donn\u00e9es. Dans ce cas, des sous-plages seront choisies par les index, ce qui permettra de lire moins de donn\u00e9es.<\/p>\n<p><\/p>\n<p>ClickHouse a r\u00e9cemment introduit des fonctionnalit\u00e9s encore plus avanc\u00e9es pour la recherche en texte int\u00e9gral. Cela inclut, tout d'abord, la possibilit\u00e9 de rechercher plusieurs sous-cha\u00eenes en une seule passe, y compris des options tenant compte de la casse, sans consid\u00e9ration de casse, prenant en charge UTF-8 ou uniquement ASCII. Choisissez celle qui est la plus efficace pour vos besoins. <\/p>\n<p><\/p>\n<p>Il est \u00e9galement possible de rechercher plusieurs expressions r\u00e9guli\u00e8res en une seule passe. Vous n'avez pas besoin d'\u00e9crire X like une sous-cha\u00eene ou X like une autre sous-cha\u00eene. \u00c9crivez simplement et tout s'ex\u00e9cutera de mani\u00e8re optimale.<\/p>\n<p><\/p>\n<p>Troisi\u00e8mement, il existe d\u00e9sormais une recherche approximative par regex et une recherche approximative de sous-cha\u00eenes. Si quelqu'un a \u00e9crit un mot avec une faute de frappe, il sera recherch\u00e9 par la correspondance maximale.<\/p>\n<p><\/p>\n<h2 id=\"anchorhello-and-welcomeanchorkak-luchshe-organizovat-dostup-vnbspclickhouse-dlyanbspbolshogo-kolichestva-polzovateley\"><noindex><a rel=\"nofollow\" name=\"hello-and-welcome\"><\/a><\/noindex>Comment organiser l'acc\u00e8s \u00e0 ClickHouse pour un grand nombre d'utilisateurs ?<\/h2>\n<p><\/p>\n<blockquote><p>Expliquez comment mieux organiser l'acc\u00e8s pour un grand nombre de consommateurs et d'analystes. Comment former une file d'attente, prioriser les requ\u00eates max concurrent queries, et quels outils utiliser ?<\/p><\/blockquote>\n<p>Si le cluster est suffisamment grand, il sera judicieux de d\u00e9ployer deux serveurs suppl\u00e9mentaires qui serviront de point d'entr\u00e9e pour les analystes. Cela signifie ne pas permettre aux analystes d'acc\u00e9der \u00e0 des shards sp\u00e9cifiques du cluster, mais simplement de cr\u00e9er deux serveurs vides, sans donn\u00e9es, et d'y configurer les droits d'acc\u00e8s. Dans ce cas, les configurations des utilisateurs lors des requ\u00eates distribu\u00e9es sont transmises aux serveurs distants. Vous configurez tout sur ces deux serveurs, et les r\u00e9glages s'appliquent \u00e0 l'ensemble du cluster.<\/p>\n<p><\/p>\n<p>En principe, ces serveurs sont vides de donn\u00e9es, mais la quantit\u00e9 de RAM qu'ils contiennent est tr\u00e8s importante pour l'ex\u00e9cution des requ\u00eates. Le disque peut \u00e9galement \u00eatre utilis\u00e9 pour y stocker des donn\u00e9es temporaires si l'agr\u00e9gation ou le tri externe est activ\u00e9.<\/p>\n<p><\/p>\n<p>Il est important de se pencher sur les param\u00e8tres li\u00e9s \u00e0 tous les \u00e9ventuels plafonds. Si je me connecte maintenant au cluster \u00ab Yandex.Metrica \u00bb en tant qu'analyste et que je saisis une requ\u00eate <strong>select count from hits<\/strong>, il m'est imm\u00e9diatement signal\u00e9 que je ne peux pas ex\u00e9cuter la requ\u00eate. Le nombre maximum de lignes que j'ai le droit de scanner est de cent milliards, alors qu'il y en a en tout cinquante billions dans une seule table sur le cluster. C'est la premi\u00e8re limitation. <\/p>\n<p><\/p>\n<p>Supposons que je supprime la limitation concernant le nombre de lignes et que je r\u00e9ex\u00e9cute la requ\u00eate. Alors je verrai la suivante exception \u2014 la configuration est activ\u00e9e <strong>force index by date<\/strong>Je ne peux pas effectuer la requ\u00eate si je n'ai pas sp\u00e9cifi\u00e9 la plage de dates. Il ne faut pas compter sur le fait que les analystes la pr\u00e9cisent manuellement. Un cas typique est \u00e9crit sous la forme o\u00f9 la date de l'\u00e9v\u00e9nement est comprise entre une semaine. Et puis, il suffit d'avoir mal plac\u00e9 une parenth\u00e8se, et au lieu de et, cela devient ou \u2014 ou correspondance d'URL. S'il n'y a pas de restriction, il ira scanner la colonne URL et va simplement consommer une tonne de ressources.<\/p>\n<p><\/p>\n<p>De plus, dans ClickHouse, il y a deux param\u00e8tres de priorit\u00e9. Malheureusement, ils sont tr\u00e8s primitifs. L'un s'appelle simplement <strong>priority<\/strong>. Si priority \u2260 0, et que des requ\u00eates avec une certaine priorit\u00e9 sont ex\u00e9cut\u00e9es, mais qu'une requ\u00eate avec une priorit\u00e9 ayant une valeur inf\u00e9rieure, ce qui signifie une priorit\u00e9 plus \u00e9lev\u00e9e, est ex\u00e9cut\u00e9e, alors la requ\u00eate avec une valeur de priorit\u00e9 plus \u00e9lev\u00e9e, ce qui signifie une priorit\u00e9 plus faible, est tout simplement suspendue et ne fonctionnera pas du tout pendant ce temps.<\/p>\n<p><\/p>\n<p>C'est un r\u00e9glage tr\u00e8s grossier, et il ne convient pas aux cas o\u00f9 il y a une charge constante sur le cluster. Mais si vous avez des requ\u00eates courtes et ponctuelles qui sont importantes, et que le cluster est principalement inactif, ce r\u00e9glage conviendra.<\/p>\n<p><\/p>\n<p>Le r\u00e9glage des priorit\u00e9s suivant s'appelle <strong>priorit\u00e9 des threads OS<\/strong>. Il d\u00e9finit simplement pour tous les fils d'ex\u00e9cution de la requ\u00eate la valeur nice pour le planificateur Linux. \u00c7a fonctionne \u00e0 peu pr\u00e8s, mais \u00e7a fonctionne quand m\u00eame. Si vous d\u00e9finissez la plus petite valeur nice \u2014 c'est la plus grande en valeur, ce qui signifie la priorit\u00e9 la plus basse \u2014 et que vous d\u00e9finissez -19 pour les requ\u00eates \u00e0 haute priorit\u00e9, alors le CPU consommera des requ\u00eates \u00e0 faible priorit\u00e9 environ quatre fois moins que les requ\u00eates \u00e0 haute priorit\u00e9. <\/p>\n<p><\/p>\n<p>Il faut aussi d\u00e9finir le temps maximum d'ex\u00e9cution d'une requ\u00eate \u2014 disons cinq minutes. La vitesse minimale d'ex\u00e9cution d'une requ\u00eate \u2014 c'est ce qu'il y a de mieux. Ce r\u00e9glage existe depuis longtemps, et il est n\u00e9cessaire non seulement pour affirmer que ClickHouse ne ralentit pas, mais pour y veiller.<\/p>\n<p><\/p>\n<p>Imaginez que vous configurez : si une requ\u00eate traite moins d'un million de lignes par seconde \u2014 cela ne doit pas se faire. Cela nuit \u00e0 notre bon nom, \u00e0 notre bonne base de donn\u00e9es. Interdisons simplement cela. Il y a en r\u00e9alit\u00e9 deux r\u00e9glages. L'un s'appelle <strong>vitesse d'ex\u00e9cution minimale<\/strong> \u2014 en&nbsp;lignes par&nbsp;seconde, et le second s'appelle le timeout avant de v\u00e9rifier la vitesse d'ex\u00e9cution minimale&nbsp;\u2014 par d\u00e9faut quinze secondes. Cela signifie que vous avez quinze secondes, et ensuite, si cela est lent, vous pouvez simplement lancer une exception \u2014 interrompre la requ\u00eate.<\/p>\n<p><\/p>\n<p>Il faut \u00e9galement configurer les quotas. ClickHouse dispose d'une fonctionnalit\u00e9 de quotas int\u00e9gr\u00e9e, qui calcule la consommation des ressources. Mais, malheureusement, cela ne concerne pas les ressources mat\u00e9rielles comme le CPU ou les disques, mais celles logiques&nbsp;\u2014 le nombre de requ\u00eates trait\u00e9es, de lignes et d'octets lus. Par exemple, vous pouvez d\u00e9finir un maximum de cent requ\u00eates en cinq minutes et mille requ\u00eates par heure.<\/p>\n<p><\/p>\n<p>Pourquoi est-ce important ? Parce qu'une partie des requ\u00eates analytiques sera ex\u00e9cut\u00e9e manuellement directement depuis le client ClickHouse. Tout fonctionnera bien. Mais si vous avez des analystes avanc\u00e9s dans votre entreprise, ils \u00e9criront un script, et il peut y avoir une erreur dans le script. Cette erreur peut entra\u00eener l'ex\u00e9cution de la requ\u00eate dans une boucle infinie. Il faut donc se prot\u00e9ger contre cela.<\/p>\n<p><\/p>\n<h2 id=\"anchorsmorgasbordanchormozhno-li-otdat-rezultaty-odnogo-zaprosa-desyati-klientam\"><noindex><a rel=\"nofollow\" name=\"smorgasbord\"><\/a><\/noindex>Peut-on envoyer les r\u00e9sultats d'une requ\u00eate \u00e0 dix clients ?<\/h2>\n<p><\/p>\n<blockquote><p>Nous avons plusieurs utilisateurs qui aiment venir avec des requ\u00eates tr\u00e8s grandes en m\u00eame temps. La requ\u00eate est grande et s'ex\u00e9cute en principe rapidement, mais \u00e0 cause du grand nombre de ces requ\u00eates simultan\u00e9ment, cela devient tr\u00e8s douloureux. Peut-on ex\u00e9cuter une m\u00eame requ\u00eate qui arrive dix fois de suite une seule fois et donner le r\u00e9sultat aux dix clients ?<\/p><\/blockquote>\n<p>Le probl\u00e8me est que nous n'avons pas de r\u00e9sultats de cache ou de cache de donn\u00e9es interm\u00e9diaires. Il y a le cache de page de l'op\u00e9ration du syst\u00e8me d'exploitation, qui permettra de ne pas lire les donn\u00e9es du disque \u00e0 nouveau, mais, malheureusement, les donn\u00e9es seront quand m\u00eame d\u00e9compress\u00e9es, d\u00e9s\u00e9rialis\u00e9es et retravaill\u00e9es. <\/p>\n<p><\/p>\n<p>Nous aimerions \u00e9viter cela d'une mani\u00e8re ou d'une autre, soit en mettant en cache les donn\u00e9es interm\u00e9diaires, soit en organisant des requ\u00eates similaires dans une sorte de file d'attente et en ajoutant le cache des r\u00e9sultats. Nous avons actuellement un pull request en d\u00e9veloppement qui ajoute un cache pour les requ\u00eates, mais seulement pour les sous-requ\u00eates dans les sections in et join \u2014 donc la solution n'est pas compl\u00e8te.<\/p>\n<p><\/p>\n<p>N\u00e9anmoins, nous rencontrons \u00e9galement une telle situation. Un exemple canonique est celui des requ\u00eates avec pagination. Il y a un rapport avec plusieurs pages, et une requ\u00eate est limit\u00e9e \u00e0 10. Puis la m\u00eame chose, mais avec une limite de 10,10. Ensuite, la page suivante. On se demande donc pourquoi nous recalculons cela \u00e0 chaque fois ? Mais pour l'instant, il n'y a pas de solution, et on ne peut pas \u00e9viter cela.<\/p>\n<p><\/p>\n<p>Il existe une solution alternative qui s'installe en sidecar \u00e0 c\u00f4t\u00e9 de ClickHouse \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Vertamedia\/chproxy\">ClickHouse Proxy<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov :<\/strong> Dans ClickHouse Proxy, il y a un limiteur de taux int\u00e9gr\u00e9 et un cache des r\u00e9sultats. De nombreux param\u00e8tres ont \u00e9t\u00e9 configur\u00e9s l\u00e0-bas, car un probl\u00e8me similaire devait \u00eatre r\u00e9solu. Le Proxy permet de limiter les requ\u00eates en les mettant en file d'attente, et de configurer combien de temps vit le cache des requ\u00eates. Si les requ\u00eates sont r\u00e9ellement identiques, le Proxy les renverra plusieurs fois, tandis qu'il interrogera ClickHouse une seule fois.<\/p>\n<p><\/p>\n<p>Nginx a \u00e9galement un cache dans la version gratuite, et cela fonctionnera aussi. Nginx a m\u00eame des r\u00e9glages pour que, si les requ\u00eates arrivent simultan\u00e9ment, il ralentisse les autres jusqu'\u00e0 ce qu'une soit ex\u00e9cut\u00e9e. Mais dans ClickHouse Proxy, le r\u00e9glage est beaucoup mieux fait. Il a \u00e9t\u00e9 con\u00e7u sp\u00e9cifiquement pour ClickHouse, pour ces types de requ\u00eates, donc il est plus adapt\u00e9. Et il s'installe facilement. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>Comment g\u00e9rer les op\u00e9rations asynchrones et les vues mat\u00e9rialis\u00e9es ?<\/h2>\n<p><\/p>\n<blockquote><p>Il y a un probl\u00e8me que les op\u00e9rations avec le moteur de remplacement sont asynchrones \u2014 d'abord, les donn\u00e9es sont enregistr\u00e9es, puis elles sont compress\u00e9es. Si une table mat\u00e9rialis\u00e9e avec des agr\u00e9gats vit sous la table, des doublons y seront \u00e9crits. Et s'il n'y a pas de logique complexe, les donn\u00e9es seront dupliqu\u00e9es. Que peut-on faire \u00e0 ce sujet ?<\/p>\n<p>Il existe une solution \u00e9vidente \u2014 impl\u00e9menter un trigger pour une certaine classe de vues mat\u00e9rialis\u00e9es lors d'une op\u00e9ration asynchrone de compression. Y a-t-il des \u00ab balles d'argent \u00bb possibles ou des plans pour la mise en \u0153uvre de telles fonctionnalit\u00e9s ?<\/p><\/blockquote>\n<p>Il vaut la peine de comprendre comment fonctionne la d\u00e9-duplication. Ce dont je vais parler maintenant ne concerne pas la question, mais il est bon de s'en rappeler au cas o\u00f9.<\/p>\n<p><\/p>\n<p>Lors de l'insertion dans une table r\u00e9pliqu\u00e9e, il y a une d\u00e9duplication des blocs ins\u00e9r\u00e9s dans leur int\u00e9gralit\u00e9. Si vous ins\u00e9rez \u00e0 nouveau le m\u00eame bloc, contenant le m\u00eame nombre de lignes dans le m\u00eame ordre, les donn\u00e9es seront d\u00e9dupliqu\u00e9es. Vous recevrez un \u00ab Ok \u00bb en r\u00e9ponse \u00e0 l'insertion, mais en r\u00e9alit\u00e9, une seule s\u00e9rie de donn\u00e9es sera \u00e9crite, sans duplication.<\/p>\n<p><\/p>\n<p>C'est n\u00e9cessaire pour la certitude. Si lors de l'insertion vous avez re\u00e7u un \u00ab Ok \u00bb, cela signifie que vos donn\u00e9es ont \u00e9t\u00e9 ins\u00e9r\u00e9es. Si vous avez re\u00e7u une erreur de ClickHouse, alors elles n'ont pas \u00e9t\u00e9 ins\u00e9r\u00e9es, et l'insertion doit \u00eatre r\u00e9p\u00e9t\u00e9e. Mais si la connexion a \u00e9t\u00e9 interrompue pendant l'insertion, vous ne savez pas si les donn\u00e9es ont \u00e9t\u00e9 ins\u00e9r\u00e9es ou non. La seule option est donc de r\u00e9p\u00e9ter l'insertion. Si les donn\u00e9es ont r\u00e9ellement \u00e9t\u00e9 ins\u00e9r\u00e9es, et que vous les ins\u00e9rez \u00e0 nouveau, une d\u00e9duplication des blocs aura lieu. Elle est n\u00e9cessaire pour \u00e9viter les duplicatas. <\/p>\n<p><\/p>\n<p>Il est \u00e9galement important de comprendre comment cela fonctionne pour les vues mat\u00e9rialis\u00e9es. Si les donn\u00e9es ont \u00e9t\u00e9 d\u00e9dupliqu\u00e9es lors de l'insertion dans la table principale, elles ne passeront pas non plus dans la vue mat\u00e9rialis\u00e9e.<\/p>\n<p><\/p>\n<p>Concernant votre question. Vous avez une situation plus complexe, car vous enregistrez des duplicatas de lignes individuelles. C'est-\u00e0-dire qu'un bloc entier n'est pas dupliqu\u00e9, mais des lignes sp\u00e9cifiques le sont, et elles se r\u00e9duisent en arri\u00e8re-plan. En effet, les donn\u00e9es seront r\u00e9duites dans la table principale, tandis que les non-r\u00e9duites iront dans la vue mat\u00e9rialis\u00e9e, et lors des fusions, rien ne se produira avec les vues mat\u00e9rialis\u00e9es. Parce qu'une vue mat\u00e9rialis\u00e9e n'est rien d'autre qu'un d\u00e9clencheur sur l'insertion. Dans d'autres op\u00e9rations, rien d'autre ne se passe avec elle.<\/p>\n<p><\/p>\n<p>Et je ne peux vraiment pas vous satisfaire ici. Il ne reste qu'\u00e0 chercher une solution sp\u00e9cifique \u00e0 ce cas. Par exemple, est-il possible de faire un remplacement dans la vue mat\u00e9rialis\u00e9e, et peut-\u00eatre que le moyen de d\u00e9duplication fonctionnera de la m\u00eame mani\u00e8re. Mais malheureusement, ce n'est pas toujours le cas. Si elle est agr\u00e9gative, alors cela ne fonctionnera pas. <\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov :<\/strong> Chez nous, la construction de b\u00e9quilles \u00e9tait \u00e9galement probl\u00e9matique \u00e0 l'\u00e9poque. Nous avions le probl\u00e8me des impressions publicitaires, et certaines donn\u00e9es que nous pouvions afficher en temps r\u00e9el \u2014 ce ne sont que des affichages. Ils ne se dupliquent que tr\u00e8s rarement, mais si cela se produit, nous les r\u00e9duisons quand m\u00eame par la suite. Et il y avait des choses qui ne pouvaient pas \u00eatre dupliqu\u00e9es \u2014 les clics et toute cette histoire. Mais il \u00e9tait \u00e9galement souhaitable de les afficher presque imm\u00e9diatement.<\/p>\n<p><\/p>\n<p>Comment les vues mat\u00e9rialis\u00e9es ont-elles \u00e9t\u00e9 cr\u00e9\u00e9es ? Il y avait des vues o\u00f9 l'on \u00e9crivait directement \u2014 les donn\u00e9es brutes sont enregistr\u00e9es et \u00e9crites dans les vues. \u00c0 un moment, les donn\u00e9es ne sont pas tr\u00e8s pr\u00e9cises, elles sont dupliqu\u00e9es, etc. Et il y a une deuxi\u00e8me partie du tableau o\u00f9 elles apparaissent absolument de la m\u00eame mani\u00e8re que les vues mat\u00e9rialis\u00e9es, c'est-\u00e0-dire qu'en termes de structure, elles sont identiques. De temps en temps, nous recalculons les donn\u00e9es, comptons les donn\u00e9es sans doublons et les \u00e9crivons dans ces tableaux. <\/p>\n<p><\/p>\n<p>Nous sommes pass\u00e9s par l'API \u2014 cela ne fonctionnera pas manuellement dans ClickHouse. L'API v\u00e9rifie : quand j'ai la date de la derni\u00e8re entr\u00e9e dans le tableau, o\u00f9 les donn\u00e9es sont d\u00e9j\u00e0 garanties comme correctes, et il effectue une requ\u00eate \u00e0 un tableau et \u00e0 un autre. De l'un, il s\u00e9lectionne jusqu'\u00e0 un certain moment, et de l'autre, il compl\u00e8te ce qui n'a pas encore \u00e9t\u00e9 compt\u00e9. Et cela fonctionne, mais pas uniquement avec ClickHouse.<\/p>\n<p><\/p>\n<p>Si vous avez une API \u2014 pour les analystes, pour les utilisateurs \u2014 c'est en principe une option. Vous recalculerez toujours. Cela peut \u00eatre fait une fois par jour ou \u00e0 un autre moment. Vous choisissez vous-m\u00eame l'intervalle qui vous est inutile et non critique.<\/p>\n<p><\/p>\n<h2 id=\"anchordashboardanchorv-clickhouse-mnogo-logov-kak-ya-mogu-videt-vsyo-chto-proishodit-s-serverom-vnbspmomente\"><noindex><a rel=\"nofollow\" name=\"dashboard\"><\/a><\/noindex>ClickHouse g\u00e9n\u00e8re beaucoup de journaux. Comment puis-je voir tout ce qui se passe sur le serveur en temps r\u00e9el ?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse a un grand nombre de journaux diff\u00e9rents, et ce nombre augmente. Dans les nouvelles versions, certains d'entre eux sont m\u00eame activ\u00e9s par d\u00e9faut, dans les anciennes versions, ils doivent \u00eatre activ\u00e9s lors de la mise \u00e0 jour. N\u00e9anmoins, ils deviennent de plus en plus nombreux. J'aimerais voir, au final, ce qui se passe actuellement sur mon serveur, peut-\u00eatre sur un tableau de bord de synth\u00e8se. <\/p>\n<p>N'avez-vous pas dans votre \u00e9quipe ClickHouse, ou dans les \u00e9quipes de vos amis, qui soutiennent une certaine fonctionnalit\u00e9 de tableaux de bord pr\u00eats \u00e0 l'emploi, qui affichent ces journaux sous forme de produit pr\u00eat ? Au final, regarder juste les journaux dans ClickHouse, c'est super. Mais ce serait vraiment g\u00e9nial si cela \u00e9tait d\u00e9j\u00e0 pr\u00eat sous forme de tableau de bord. J'en serais ravi. <\/p><\/blockquote>\n<p>Il existe des tableaux de bord, mais ils ne sont pas standardis\u00e9s. Dans notre entreprise, environ 60 \u00e9quipes utilisent ClickHouse, et il est \u00e9trange de constater que beaucoup d'entre eux ont des tableaux de bord qu'ils ont cr\u00e9\u00e9s eux-m\u00eames, et l\u00e9g\u00e8rement diff\u00e9rents. Certaines \u00e9quipes utilisent une installation interne de Yandex.Cloud. Il y a certains rapports pr\u00eats, bien que pas tous les n\u00e9cessaires. D'autres ont leur propre. <\/p>\n<p><\/p>\n<p>Mes coll\u00e8gues de la 'Mesure' ont leur propre tableau de bord dans Grafana, et j'ai le mien bas\u00e9 sur leur cluster. J'y regarde des choses comme le cache hit pour le cache des points. Et c'est encore plus compliqu\u00e9 car nous utilisons diff\u00e9rents outils. J'ai cr\u00e9\u00e9 mon tableau de bord avec un tr\u00e8s vieux outil appel\u00e9 Graphite-web. Il est absolument peu attrayant. Et je continue de l'utiliser, bien que Grafana serait probablement plus pratique et plus joli. <\/p>\n<p><\/p>\n<p>La base des tableaux de bord est la m\u00eame. Ce sont des m\u00e9triques syst\u00e8me par cluster : CPU, m\u00e9moire, disque, r\u00e9seau. D'autres incluent le nombre de requ\u00eates simultan\u00e9es, le nombre de fusions simultan\u00e9es, le nombre de requ\u00eates par seconde, le nombre maximum de morceaux pour les partitions de tables MergeTree, le retard de r\u00e9plication, la taille de la file d'attente de r\u00e9plication, le nombre de lignes ins\u00e9r\u00e9es par seconde, le nombre de blocs ins\u00e9r\u00e9s par seconde. Tout cela provient des m\u00e9triques, pas des journaux.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Alexey, je voudrais apporter une petite correction. Il y a Grafana. Grafana a une source de donn\u00e9es qui est ClickHouse. Donc, je peux faire des requ\u00eates directement dans ClickHouse depuis Grafana. Dans ClickHouse, il y a une table avec des journaux, elle est identique pour tous. Je veux finalement dans Grafana interroger cette table de logs et voir les requ\u00eates que mon serveur envoie. Ce serait super d'avoir un tel tableau de bord.<\/p>\n<p><\/p>\n<p>Je l'ai bricol\u00e9 moi-m\u00eame. Mais j'ai une question \u2014 si tout est standardis\u00e9 et que Grafana est utilis\u00e9e par tout le monde, pourquoi n'y a-t-il pas de tableau de bord officiel dans 'Yandex' ?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov :<\/strong> En r\u00e9alit\u00e9, c'est Altinity qui prend en charge la datasource pour ClickHouse. Je veux juste donner une direction sur o\u00f9 chercher et qui pousser. On peut leur poser des questions, car Yandex d\u00e9veloppe ClickHouse et non l'\u00e9cosyst\u00e8me qui l'entoure. Altinity est la principale entreprise qui promeut actuellement ClickHouse. Ils ne l'abandonneront pas, mais continueront \u00e0 le soutenir. En effet, pour charger un tableau de bord sur le site de Grafana, il suffit de s'inscrire et de le t\u00e9l\u00e9charger \u2014 il n'y a pas de probl\u00e8mes particuliers. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Au cours de l'ann\u00e9e \u00e9coul\u00e9e, ClickHouse a ajout\u00e9 de nombreuses fonctionnalit\u00e9s pour le profilage des requ\u00eates. Il existe des m\u00e9triques pour chaque requ\u00eate concernant l'utilisation des ressources. Tr\u00e8s r\u00e9cemment, un profileur de requ\u00eates de niveau encore plus bas a \u00e9t\u00e9 ajout\u00e9, permettant de voir o\u00f9 chaque milliseconde est utilis\u00e9e par la requ\u00eate. Mais pour profiter de cette fonctionnalit\u00e9, je dois ouvrir le client en console et entrer une requ\u00eate que j'oublie constamment. Je l'ai enregistr\u00e9e quelque part et j'oublie toujours o\u00f9. <\/p>\n<p><\/p>\n<p>J'aimerais qu'il existe un outil qui pr\u00e9sente simplement \u2014 voici vos requ\u00eates lourdes, regroup\u00e9es par cat\u00e9gories. En cliquant dessus, j'aimerais savoir pourquoi elle est lourde. Actuellement, il n'existe pas de telle solution. Et c'est vraiment assez \u00e9trange, quand les gens me demandent : \u00ab Dites-moi, existe-t-il des tableaux de bord pr\u00eats pour Grafana ? \u00bb, je r\u00e9ponds : \u00ab Allez sur le site de Grafana, il y a la communaut\u00e9 \u201cTableaux de bord\u201d, et vous y trouverez un tableau de bord de Dimka, un tableau de bord de Kostyan. Je ne sais pas ce que c'est, je ne l'ai pas utilis\u00e9 moi-m\u00eame. \u00bb<\/p>\n<p><\/p>\n<h2 id=\"anchorzenanchorkak-vozdeystvovat-na-merdzhi-chtoby-server-ne-padal-vnbspoom\"><noindex><a rel=\"nofollow\" name=\"zen\"><\/a><\/noindex>Comment influencer les fusions pour \u00e9viter que le serveur ne tombe en OOM ?<\/h2>\n<p><\/p>\n<blockquote><p>J'ai une table qui a une seule partition, c'est une ReplacingMergeTree. J'y \u00e9cris des donn\u00e9es depuis quatre ans. J'avais besoin d'y faire un alter et de supprimer certaines donn\u00e9es.<\/p>\n<p>Je l'ai fait, et lors du traitement de cette requ\u00eate, toute la m\u00e9moire des serveurs du cluster a \u00e9t\u00e9 consomm\u00e9e, et tous les serveurs du cluster sont tomb\u00e9s ensemble en OOM. Ensuite, ils se sont tous r\u00e9tablis, ont commenc\u00e9 \u00e0 effectuer la fusion de cette m\u00eame op\u00e9ration, de ce bloc de donn\u00e9es, et sont \u00e0 nouveau tomb\u00e9s en OOM. Puis ils se sont \u00e0 nouveau r\u00e9tablis et sont \u00e0 nouveau tomb\u00e9s. Et ce cycle ne s'est pas arr\u00eat\u00e9.<\/p>\n<p>Il s'est av\u00e9r\u00e9 que c'\u00e9tait en fait un bug que les gars ont corrig\u00e9. C'est super, merci beaucoup. Mais il reste un ressenti. Et maintenant, quand je pense \u00e0 faire un certain merge dans la table, je me pose la question : pourquoi ne puis-je pas influencer ces merges d'une certaine mani\u00e8re ? Par exemple, limiter leur quantit\u00e9 en termes de m\u00e9moire vive requise, ou en principe par le nombre qu'ils traiteront sp\u00e9cifiquement pour cette table.<\/p>\n<p>J'ai une table qui s'appelle \u00ab M\u00e9triques \u00bb, traite-moi s'il te pla\u00eet dans deux flux. Ne cr\u00e9e pas dix ou cinq merges en parall\u00e8le, fais \u00e7a en deux. Je pense qu'en deux, j'aurai assez de m\u00e9moire, mais pour en traiter dix, \u00e7a pourrait ne pas suffire. Pourquoi cette peur persiste-t-elle ? Parce que la table grandit, et un jour je vais me retrouver dans une situation o\u00f9, en principe, non pas \u00e0 cause d'un bug, mais parce que les donn\u00e9es vont changer en si grand nombre que je vais tout simplement manquer de m\u00e9moire sur le serveur. Et l\u00e0, le serveur va tomber en OOM lors du merge. D'ailleurs, je peux annuler une mutation, mais pas les merges.<\/p><\/blockquote>\n<p>Vous savez, lors des merges, le serveur ne va pas tomber en OOM, car lors du merge, seule une petite plage de donn\u00e9es utilise de la m\u00e9moire vive. Donc tout ira bien, peu importe le volume des donn\u00e9es.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> D'accord. Il y a un d\u00e9tail \u00e0 noter, c'est qu'apr\u00e8s avoir corrig\u00e9 le bug, j'ai t\u00e9l\u00e9charg\u00e9 la nouvelle version et sur une autre table, plus petite, o\u00f9 il y a beaucoup de partitions, j'ai fait une op\u00e9ration similaire. Et pendant le merge sur le serveur, environ 100 Go de m\u00e9moire vive ont \u00e9t\u00e9 utilis\u00e9s. J'avais 150 Go engag\u00e9s, 100 Go consum\u00e9s, et il me restait une fen\u00eatre de 50 Go, donc je n'ai pas chut\u00e9 en OOM.<\/p>\n<p><\/p>\n<p>Qu'est-ce qui me prot\u00e8ge actuellement de tomber en OOM, s'il consomme vraiment 100 Go de m\u00e9moire vive ? Que faire si jamais la m\u00e9moire vive vient \u00e0 manquer lors des merges ?<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Il y a un probl\u00e8me o\u00f9 la consommation de m\u00e9moire vive sur les merges n\u2019est pas limit\u00e9e. Et le deuxi\u00e8me probl\u00e8me est que, si un merge a \u00e9t\u00e9 planifi\u00e9, il doit \u00eatre ex\u00e9cut\u00e9 car il est enregistr\u00e9 dans le journal de r\u00e9plication. Le journal de r\u00e9plication contient les actions n\u00e9cessaires pour amener la r\u00e9plique dans un \u00e9tat coh\u00e9rent. Si aucune manipulation manuelle n\u2019est effectu\u00e9e pour annuler ce journal de r\u00e9plication, le merge devra \u00eatre ex\u00e9cut\u00e9, d'une mani\u00e8re ou d'une autre.<\/p>\n<p><\/p>\n<p>Bien s\u00fbr, il serait utile d'avoir une limite sur la m\u00e9moire vive qui prot\u00e8ge 'juste au cas o\u00f9' contre les OOM. Cela ne permettra pas au merge de s'ex\u00e9cuter, il recommencera, atteindra un certain seuil, lancera une exception, puis recommencera - rien de bon n'en sortira. Mais en principe, il serait utile d'introduire cette limitation.<\/p>\n<p><\/p>\n<h2 id=\"anchorgoanchorkak-budet-proishodit-razrabotka-golang-drayvera-dlya-clickhouse\"><noindex><a rel=\"nofollow\" name=\"go\"><\/a><\/noindex>Comment va se d\u00e9rouler le d\u00e9veloppement du pilote Golang pour ClickHouse ?<\/h2>\n<p><\/p>\n<blockquote><p>Le pilote Golang, \u00e9crit par Kirill Shvakov, est maintenant officiellement soutenu par l'\u00e9quipe ClickHouse. Il <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">dans le d\u00e9p\u00f4t ClickHouse<\/a><\/noindex>, il est maintenant grand et authentique.<\/p>\n<p>Une petite remarque. Il existe un entrep\u00f4t de formes infinies, merveilleux et tr\u00e8s appr\u00e9ci\u00e9 de tous, qui est Vertica. Ils ont aussi leur propre pilote Python, soutenu par les d\u00e9veloppeurs de Vertica. Il y a eu plusieurs fois o\u00f9 les versions de l'entrep\u00f4t et du pilote \u00e9taient tr\u00e8s diff\u00e9rentes, et \u00e0 un moment donn\u00e9, le pilote cessait de fonctionner. Un deuxi\u00e8me point \u00e0 mentionner. Il me semble que le support de ce pilote officiel est g\u00e9r\u00e9 via un syst\u00e8me de type \u00ab nippel \u00bb \u2014 vous leur \u00e9crivez un probl\u00e8me et il reste suspendu ind\u00e9finiment.<\/p>\n<p>J'ai deux questions. Actuellement, le pilote Golang de Kirill est presque la m\u00e9thode par d\u00e9faut pour communiquer avec ClickHouse depuis Golang. \u00c0 part quelques personnes qui utilisent encore l\u2019interface HTTP, parce qu\u2019elle leur pla\u00eet. Comment le d\u00e9veloppement de ce pilote se d\u00e9roulera-t-il ? Sera-t-il synchronis\u00e9 avec des modifications majeures dans l'entrep\u00f4t lui-m\u00eame ? Et quelle est la proc\u00e9dure de traitement des probl\u00e8mes ? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov :<\/strong> D'abord, concernant le fonctionnement bureaucratique. Ce point n'a pas \u00e9t\u00e9 discut\u00e9, donc je n'ai rien \u00e0 r\u00e9pondre.<\/p>\n<p><\/p>\n<p>Pour r\u00e9pondre \u00e0 la question concernant le probl\u00e8me, il est n\u00e9cessaire d'avoir un petit historique du driver. Je travaillais dans une entreprise o\u00f9 il y avait beaucoup de donn\u00e9es. C'\u00e9tait une plateforme publicitaire avec un \u00e9norme nombre d'\u00e9v\u00e9nements \u00e0 stocker. \u00c0 un moment donn\u00e9, ClickHouse est apparu. Nous avons charg\u00e9 des donn\u00e9es, et au d\u00e9but tout allait bien, puis ClickHouse est tomb\u00e9 en panne. \u00c0 ce moment-l\u00e0, nous avons d\u00e9cid\u00e9 que nous n'en avions pas besoin. <\/p>\n<p><\/p>\n<p>Un an plus tard, nous sommes revenus \u00e0 l'id\u00e9e d'utiliser ClickHouse, et nous devions trouver un moyen d'y \u00e9crire des donn\u00e9es. L'entr\u00e9e \u00e9tait la suivante : le mat\u00e9riel \u00e9tait tr\u00e8s faible, les ressources \u00e9taient limit\u00e9es. Mais nous avions toujours fonctionn\u00e9 ainsi, donc nous avons regard\u00e9 du c\u00f4t\u00e9 du protocole natif.<\/p>\n<p><\/p>\n<p>Comme nous travaillions sur Go, il \u00e9tait \u00e9vident qu'un driver Go \u00e9tait n\u00e9cessaire. Je l'ai d\u00e9velopp\u00e9 presque \u00e0 plein temps - c'\u00e9tait ma t\u00e2che de travail. Jusqu'\u00e0 un certain point, nous avons r\u00e9ussi \u00e0 le peaufiner, et en principe, personne ne pensait que quelqu'un d'autre l'utiliserait. Puis CloudFlare est arriv\u00e9 avec exactement le m\u00eame probl\u00e8me, et pendant un certain temps, nous avons travaill\u00e9 tr\u00e8s en \u00e9troite collaboration avec eux, car ils avaient les m\u00eames t\u00e2ches. D'ailleurs, nous l'avons fait \u00e0 la fois dans ClickHouse m\u00eame et dans le driver. <\/p>\n<p><\/p>\n<p>\u00c0 un moment donn\u00e9, j'ai simplement cess\u00e9 de m'en occuper, car mon activit\u00e9 sur ClickHouse et mon travail ont un peu chang\u00e9. C'est pourquoi les probl\u00e8mes demeurent non r\u00e9solus. Par intermittence, des gens commettent dans le d\u00e9p\u00f4t, car ils ont besoin de quelque chose. Alors je regarde les pull requests et parfois je corrige m\u00eame quelque chose moi-m\u00eame, mais cela arrive rarement.<\/p>\n<p><\/p>\n<p>Je souhaite revenir au driver. Il y a quelques ann\u00e9es, lorsque tout cela a commenc\u00e9, ClickHouse \u00e9tait \u00e9galement diff\u00e9rent et offrait d'autres possibilit\u00e9s. Maintenant, nous avons une id\u00e9e de la mani\u00e8re de r\u00e9\u00e9crire le driver pour que ce soit bien. Si cela se produit, la version 2 sera de toute fa\u00e7on incompatible \u00e0 cause des hacks accumul\u00e9s. <\/p>\n<p><\/p>\n<p>Je ne sais pas comment organiser cela. Je n'ai pas beaucoup de temps moi-m\u00eame. Si certaines personnes commencent \u00e0 am\u00e9liorer le driver, je pourrai les aider et leur dire quoi faire. Mais la participation active de Yandex au d\u00e9veloppement du projet n'a pas encore \u00e9t\u00e9 discut\u00e9e. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> En r\u00e9alit\u00e9, il n'y a pas encore de bureaucratie concernant ces drivers. La seule chose est qu'ils ont \u00e9t\u00e9 transf\u00e9r\u00e9s dans une organisation officielle, c'est-\u00e0-dire que ce driver est reconnu comme la solution officielle par d\u00e9faut pour Go. Il existe d'autres drivers, mais ils sont s\u00e9par\u00e9s. <\/p>\n<p><\/p>\n<p>Nous n'avons pas de d\u00e9veloppement interne pour ces drivers. La question est de savoir si nous pouvons embaucher une personne distincte, pas sp\u00e9cifiquement pour ce driver, mais pour le d\u00e9veloppement de tous les drivers communautaires, ou si nous pouvons trouver quelqu'un \u00e0 l'ext\u00e9rieur. <\/p>\n<p><\/p>\n<h2 id=\"anchorlazy-loadanchorvneshniy-slovar-ne-podnimaetsya-posle-perezagruzki-snbspvklyuchennoy-nastroykoy-lazy_load-chto-delat\"><noindex><a rel=\"nofollow\" name=\"lazy-load\"><\/a><\/noindex>Le dictionnaire externe ne se l\u00e8ve pas apr\u00e8s le red\u00e9marrage avec la configuration lazy_load activ\u00e9e. Que faire ?<\/h2>\n<p><\/p>\n<blockquote><p>Nous avons la configuration lazy_load activ\u00e9e, et apr\u00e8s le red\u00e9marrage du serveur, le dictionnaire ne se l\u00e8ve pas tout seul. Il ne se l\u00e8ve qu'apr\u00e8s que l'utilisateur a acc\u00e9d\u00e9 \u00e0 ce dictionnaire. Et lors du premier acc\u00e8s, une erreur est renvoy\u00e9e. Est-il possible de charger automatiquement les dictionnaires avec ClickHouse, ou devons-nous toujours contr\u00f4ler leur disponibilit\u00e9 pour que les utilisateurs ne re\u00e7oivent pas d'erreurs ?<\/p>\n<p>Peut-\u00eatre que nous avons une ancienne version de ClickHouse, c'est pourquoi le dictionnaire ne s'est pas charg\u00e9 automatiquement. Est-ce possible ?<\/p><\/blockquote>\n<p>D'abord, les dictionnaires peuvent \u00eatre forc\u00e9s de se charger avec une requ\u00eate. <strong>system reload dictionaries<\/strong>. Deuxi\u00e8mement, concernant l'erreur \u2014 si le dictionnaire est d\u00e9j\u00e0 charg\u00e9, les requ\u00eates fonctionneront avec les donn\u00e9es qui ont \u00e9t\u00e9 charg\u00e9es. S'il n'a pas encore \u00e9t\u00e9 charg\u00e9, il sera charg\u00e9 au moment de la requ\u00eate.<\/p>\n<p><\/p>\n<p>Pour les dictionnaires lourds, ce n'est pas tr\u00e8s pratique. Par exemple, il faut r\u00e9cup\u00e9rer un million de lignes \u00e0 partir de MySQL. Quelqu'un fait une simple s\u00e9lection, mais cette s\u00e9lection devra attendre toutes ces lignes. Il y a deux solutions. La premi\u00e8re \u2014 d\u00e9sactiver lazy_load. La deuxi\u00e8me \u2014 lorsque le serveur d\u00e9marre, avant de le charger, effectuer <strong>system reload dictionary<\/strong> ou simplement ex\u00e9cuter une requ\u00eate qui utilise le dictionnaire. Ainsi, le dictionnaire sera charg\u00e9. Il faut contr\u00f4ler soi-m\u00eame la disponibilit\u00e9 des dictionnaires avec l'option lazy_load activ\u00e9e, car ClickHouse ne les charge pas automatiquement.<\/p>\n<p><\/p>\n<p>Pour la derni\u00e8re question, la r\u00e9ponse est \u2014 soit la version est ancienne, soit il faut d\u00e9boguer. <\/p>\n<p><\/p>\n<h2 id=\"anchorreload-dictionariesanchorkak-byt-snbsptem-chto-system-reload-dictionaries-ne-podgruzhaet-ni-odin-iznbspmnozhestva-slovarey-esli-hotya-by-odin-iznbspnih-padaet-snbsposhibkoy\"><noindex><a rel=\"nofollow\" name=\"reload-dictionaries\"><\/a><\/noindex>Que faire si system reload dictionaries ne charge aucun des nombreux dictionnaires, si au moins un d'entre eux \u00e9choue avec une erreur ?<\/h2>\n<p><\/p>\n<blockquote><p>Il y a aussi une question concernant system reload dictionaries. Nous avons deux dictionnaires \u2014 l'un ne se charge pas, l'autre se charge. Dans ce cas, system reload dictionaries ne charge aucun dictionnaire, et il faut le charger manuellement en utilisant system reload dictionary en pr\u00e9cisant son nom. Est-ce \u00e9galement li\u00e9 \u00e0 la version de ClickHouse ?<\/p><\/blockquote>\n<p>Je suis heureux de l'annoncer. Ce comportement a chang\u00e9. Cela signifie que si vous mettez \u00e0 jour ClickHouse, cela changera aussi. Si le comportement actuel ne vous satisfait pas <strong>system reload dictionaries<\/strong>, mettez \u00e0 jour, et esp\u00e9rons que cela s'am\u00e9liorera.<\/p>\n<p><\/p>\n<h2 id=\"anchorconnectionanchorest-li-sposob-konfigurirovat-rekvizity-vnbspkonfige-clickhouse-no-ne-svetit-ih-prinbsposhibkah\"><noindex><a rel=\"nofollow\" name=\"connection\"><\/a><\/noindex>Y a-t-il un moyen de configurer les informations dans la config de ClickHouse sans les exposer lors des erreurs ?<\/h2>\n<p><\/p>\n<blockquote><p>La prochaine question concerne les erreurs li\u00e9es au dictionnaire, \u00e0 savoir les informations d'identification. Nous avons sp\u00e9cifi\u00e9 les informations de connexion dans la configuration de ClickHouse pour le dictionnaire, et en cas d'erreur, nous recevons ces informations et le mot de passe en r\u00e9ponse. <\/p>\n<p>Nous avons r\u00e9solu cette erreur en d\u00e9pla\u00e7ant les informations d'identification dans la configuration du driver ODBC. Y a-t-il un moyen de configurer les informations dans la configuration de ClickHouse sans exposer ces informations lors des erreurs ?<\/p><\/blockquote>\n<p>La solution ici est effectivement de sp\u00e9cifier ces credentials dans odbc.ini, et dans ClickHouse, de n'indiquer que le nom de la source de donn\u00e9es ODBC. Pour d'autres sources de dictionnaires, cela ne sera pas le cas \u2014 ni pour le dictionnaire avec MySQL, ni pour les autres, vous ne devez pas voir le mot de passe dans le message d'erreur. Pour ODBC, je vais aussi v\u00e9rifier \u2014 si cela existe, il suffit de l'enlever.<\/p>\n<p><\/p>\n<h2 id=\"anchorzoom-backgroundsanchorbonus-fony-dlya-zuma-snbspposidelok\"><noindex><a rel=\"nofollow\" name=\"zoom-backgrounds\"><\/a><\/noindex>Bonus : fonds pour Zoom lors de r\u00e9unions<\/h2>\n<p><\/p>\n<p>En cliquant sur&nbsp;l'image, les lecteurs les plus assidus pourront d\u00e9couvrir des fonds bonus de nos sessions. \u00c9teignons le feu ensemble avec les mascottes des technologies Avito, discutons avec nos coll\u00e8gues de la salle des administrateurs syst\u00e8mes ou d'un vieux club d'informatique et tenons nos r\u00e9unions quotidiennes sous le pont sur fond de graffiti.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse pour les utilisateurs avanc\u00e9s dans les questions et r\u00e9ponses\" src=\"\/wp-content\/uploads\/2020\/05\/38b2ea076283285d934913c395863eb1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/500678\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430&nbsp;\u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437&nbsp;\u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros. \u041e\u0431\u0441\u0443\u0436\u0434\u0430\u043b\u0438, \u043a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0438 \u043a\u0430\u043a\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0443&nbsp;\u043d\u0430\u0441 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442. \u041f\u043e&nbsp;\u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0432\u0441\u0442\u0440\u0435\u0447\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u0441&nbsp;\u043e\u0442\u0432\u0435\u0442\u0430\u043c\u0438 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432 \u043d\u0430&nbsp;\u043d\u0430\u0448\u0438 \u0438 \u0437\u0440\u0438\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u043f\u0440\u043e&nbsp;\u0431\u044d\u043a\u0430\u043f\u044b, \u0440\u0435\u0448\u0430\u0440\u0434\u0438\u043d\u0433 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0441\u043b\u043e\u0432\u0430\u0440\u0438, Golang-\u0434\u0440\u0430\u0439\u0432\u0435\u0440 \u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u0435\u0440\u0441\u0438\u0439 ClickHouse. \u041e\u043d\u0430 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80776,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80775","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47ClickHouse pour les utilisateurs avanc\u00e9s : questions et r\u00e9ponses | ProHoster","description":"En avril, les ing\u00e9nieurs d'Avito pr\u00e9voyaient des rencontres en ligne avec le d\u00e9veloppeur principal de ClickHouse, Alexei Milovidov, et Kirill Shvakov, d\u00e9veloppeur Golang de la soci\u00e9t\u00e9 Integros.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster","og:description":"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-08T11:42:47+00:00","article:modified_time":"2020-05-08T11:42:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80775","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:11:22","updated":"2022-09-28 05:48:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/80775","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=80775"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/80775\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/80776"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=80775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=80775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=80775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}