ClickHouse pour les utilisateurs avancés dans les questions et réponses

En avril, les ingénieurs d'Avito se sont réunis lors de sessions en ligne avec le principal développeur de ClickHouse, Alexey Milovidov, et Kirill Shvakov, un développeur Golang de la société Integros. Ils ont discuté de la manière dont nous utilisons le système de gestion de bases de données et des difficultés que nous rencontrons.

Suite à cette rencontre, nous avons rassemblé un article avec les réponses des experts à nos questions et à celles des spectateurs concernant les sauvegardes, le resharding des données, les dictionnaires externes, le pilote Golang et la mise à jour des versions de ClickHouse. Cela pourrait être utile pour les développeurs qui travaillent déjà activement avec le SGBD de Yandex et s'intéressent à son présent et à son avenir. Par défaut, les réponses proviennent d'Alexey Milovidov, sauf indication contraire.

Attention, il y a beaucoup de texte sous cette section. Nous espérons que le contenu des questions vous aidera à vous orienter.

Contenu

• ClickHouse se met constamment à jour, mais nos données ne le font pas. Que faire ?
• Quelles sont les meilleures pratiques actuelles pour la sauvegarde des données de ClickHouse ?
• Peut-on organiser un retard contrôlé des réplicas dans les flux ?
• Que faire si la structure de la table a changé ?
• Quelles sont les meilleures pratiques actuelles en matière de reshaping des données ?
• ClickHouse dispose d'un utilitaire appelé clickhouse-copier. Pouvez-vous en parler ?
• Vous aviez un projet pilote appelé reshaping. Qu'en est-il ?
• Peut-on fusionner toutes les parties des données avant de les déplacer sur des disques lents ?
• Comment passer à de nouvelles versions de ClickHouse si je n'ai pas la possibilité de vérifier la compatibilité à l'avance ?
• Kill query devrait tuer les requêtes, mais ce n'est pas le cas. Pourquoi ?
• Comment calculer le temps de réponse sous une charge de lecture ?
• Que dois-je ajuster dans ClickHouse pour que davantage de données soient mises en cache ?
• Comment configurer storage_configuration pour un stockage en mémoire ?
• Jusqu'à quel nombre de valeurs uniques Low Cardinality est-il efficace ?
• Quelles sont les meilleures pratiques pour la recherche en texte intégral sur une table de cinq milliards de lignes ?
• Comment organiser l'accès à ClickHouse pour un grand nombre d'utilisateurs ?
• Peut-on envoyer les résultats d'une requête à dix clients ?
• Comment gérer les opérations asynchrones et les vues matérialisées ?
• ClickHouse génère beaucoup de logs. Comment puis-je voir tout ce qui se passe sur le serveur en temps réel ?
• Comment influencer les merges pour que le serveur ne tombe pas en OOM ?
• Comment se déroulera le développement du pilote Golang pour ClickHouse ?
• Le dictionnaire externe ne se lance pas après le redémarrage avec la configuration lazy_load activée. Que faire ?
• Comment gérer le fait que system reload dictionaries ne charge aucun des nombreux dictionnaires si au moins l'un d'eux échoue avec une erreur ?
• Y a-t-il un moyen de configurer les identifiants dans la configuration de ClickHouse, mais sans les exposer en cas d'erreurs ?
• Bonus : fonds pour Zoom à partir de soirées

Si vous ne souhaitez pas lire le texte, vous pouvez regarder l'enregistrement des soirées sur notre chaîne YouTube. Les timestamps sont dans le premier commentaire sous la vidéo.

ClickHouse se met à jour constamment, mais nos données ne le sont pas. Que faire ?

ClickHouse se met à jour constamment, et nos données, qui ont été optimisées avec final, ne sont pas mises à jour et se trouvent dans une sauvegarde.

Supposons qu'un problème survienne et que les données soient perdues. Nous avons décidé de nous restaurer, mais il s'est avéré que les anciennes partitions, qui sont stockées sur les serveurs de sauvegarde, divergent fortement de la version actuelle de ClickHouse. Que faire dans cette situation, et est-ce possible ?

Une situation où vous restaurez des données à partir d'une sauvegarde dans un ancien format, tandis que la nouvelle version ne les connecte pas, est impossible. Nous veillons à ce que le format des données dans ClickHouse soit toujours rétro-compatible. C'est beaucoup plus important que la rétro-compatibilité fonctionnelle, si le comportement d'une fonction rarement utilisée a changé. Les données stockées sur le disque doivent toujours pouvoir être lues par la nouvelle version de ClickHouse. C'est une règle.

Quelles sont les meilleures pratiques actuelles pour la sauvegarde des données de ClickHouse ?

Comment effectuer des sauvegardes en tenant compte que nous avons des opérations d'optimisation finale, une énorme base de données en téraoctets, et des données qui sont mises à jour, supposons, au cours des trois derniers jours, et qu'ensuite aucune procédure n'est effectuée ?

Nous pouvons développer notre propre solution et écrire dans un shell : rassemblez ces sauvegardes de cette manière. Peut-être qu'il n'est pas nécessaire de bricoler quoi que ce soit, et que le vélo a déjà été inventé ?

Pour commencer en ce qui concerne les meilleures pratiques. Mes collègues conseillent toujours, en réponse aux questions sur les sauvegardes, de rappeler le service « Yandex.Cloud », où cette tâche a déjà été résolue. Alors, utilisez-le si vous en avez la possibilité.

Il n'existe pas de solution complète, entièrement intégrée à ClickHouse, pour les sauvegardes. Il y a certaines préparations que l'on peut utiliser. Pour obtenir une solution complète, il faudra soit passer un peu de temps manuellement, soit créer des wrappers sous forme de scripts.

Je commencerai par les solutions les plus simples et terminerai par les plus sophistiquées, selon le volume de données et la taille du cluster. Plus le cluster est grand, plus la solution devient complexe.

Si la table de données ne fait que quelques gigaoctets, la sauvegarde peut se faire ainsi :

1. Enregistrer la définition des tables, c'est-à-dire les métadonnées — show create table.
2. Faire un dump à l'aide du client ClickHouse — select * from table dans un fichier. Par défaut, vous obtiendrez un fichier au format TabSeparated. Si vous souhaitez quelque chose de plus efficace, vous pouvez utiliser le format Native.

Si le volume de données est plus important, la sauvegarde nécessitera plus de temps et d'espace. Cela s'appelle une sauvegarde logique, elle n'est pas liée au format de données de ClickHouse. Si elle existe, vous pourrez dans ce cas charger la sauvegarde dans MySQL pour restauration.

Pour des cas plus avancés, ClickHouse intègre la possibilité de créer des snapshots de partitions dans le système de fichiers local. Cette fonctionnalité est accessible sous forme de requête alter table freeze partition. Ou simplement alter table freeze — ceci est un snapshot de toute la table.

Le snapshot sera créé de manière cohérente pour une seule table sur un shard, c'est-à-dire qu'il est impossible de créer un snapshot cohérent de l'ensemble du cluster de cette manière. Cependant, pour la plupart des tâches, cela n'est pas nécessaire, et il suffit d'exécuter la requête sur chaque shard pour obtenir un snapshot cohérent. Celui-ci est créé sous forme de hardlinks et ne prend donc pas d'espace supplémentaire. Ensuite, ce snapshot est copié sur un serveur de sauvegarde ou dans le stockage utilisé pour les sauvegardes.

Restaurer cette sauvegarde est assez simple. D'abord, vous créez les tables selon les définitions de table existantes. Ensuite, vous copiez les snapshots de partition sauvegardés dans Directory-Detached pour ces tables et exécutez la requête attach partition. Cette solution convient parfaitement pour les volumes de données les plus sérieux.

Parfois, il faut quelque chose d'encore plus puissant — dans les cas où vous avez des dizaines, voire des centaines de téraoctets sur chaque serveur et des centaines de serveurs. Il existe une solution que j'ai vue chez mes collègues de « Yandex.Metrics ». Je ne le conseillerais pas à tout le monde — lisez et décidez vous-même si cela vous convient ou non.

Tout d'abord, vous devez créer plusieurs serveurs avec de grands racks de stockage. Ensuite, sur ces serveurs, déployez plusieurs serveurs ClickHouse et configurez-les pour qu'ils fonctionnent comme une autre réplique pour les mêmes shards. Ensuite, utilisez un système de fichiers sur ces serveurs ou un outil qui permet de créer des instantanés. Il y a deux options. La première option est les instantanés LVM, la deuxième option est ZFS sur Linux.

Après cela, vous devez créer un instantané chaque jour, il occupera de l'espace. Naturellement, si les données changent, au fil du temps, l'espace occupé augmentera. Cet instantané peut être récupéré à tout moment pour restaurer les données, c'est une solution étrange. De plus, il faut limiter ces répliques dans la configuration pour qu'elles n'essaient pas de devenir des leaders.

Peut-on organiser un retard contrôlé des réplicas dans les flux ?

Cette année, vous prévoyez de créer des partitions dans ClickHouse. Sera-t-il possible d'organiser un retard contrôlé des répliques dans celles-ci ? Nous aimerions utiliser cela pour nous protéger contre des scénarios négatifs liés aux altérations et autres modifications.

Est-il possible de faire des rollbacks pour les altérations ? Par exemple, dans une partition existante, il serait possible de dire que jusqu'à ce moment-là, appliquez les modifications, et à partir de ce moment-là, ne les appliquez plus ?

Si une équipe arrive dans notre cluster et le casse, nous avons une réplique conditionnelle avec un retard d'une heure, où nous pouvons dire que nous allons l'utiliser pour le moment, mais nous ne prendrons pas en compte les dix dernières minutes de changements ?

Pour commencer, parlons du retard contrôlé des répliques. Une telle demande a été faite par des utilisateurs, et nous avons créé un problème sur GitHub avec la demande : « Si cela intéresse quelqu'un, laissez un like, mettez un cœur ». Personne n'a réagi, et le problème a été fermé. Néanmoins, il est déjà possible d'obtenir cette fonctionnalité en configurant ClickHouse. Cependant, cela ne sera possible qu'à partir de la version 20.3.

ClickHouse effectue en permanence des fusions de données en arrière-plan - le merge. Lorsque le merge est effectué, un certain ensemble de fragments de données est remplacé par un fragment plus grand. Pendant ce temps, les fragments de données précédents continuent d'exister sur le disque pendant un certain temps.

Tout d'abord, ils continuent d'être stockés tant qu'il y a des requêtes SELECT qui les utilisent, afin d'assurer un traitement non-bloquant. Les requêtes SELECT peuvent tranquillement lire à partir des anciens fragments.

Deuxièmement, il y a aussi un seuil de temps - les anciens fragments de données restent sur le disque pendant huit minutes. Ce délai peut être ajusté et transformé en un jour entier. Cela coûtera de l'espace sur le disque : selon le flux de données, les données de la dernière journée pourraient non seulement doubler, elles pourraient devenir cinq fois plus nombreuses. Mais vous pourrez, en cas de problème sérieux, arrêter le serveur ClickHouse et tout régler.

Maintenant, la question se pose de savoir comment cela protège contre les ALTERs. Il convient d'examiner de plus près, car dans les anciennes versions de ClickHouse, l'ALTER fonctionnait de telle manière qu'il modifiait directement les fragments. Il y a un fragment de données avec certains fichiers, et nous réalisons, par exemple, alter drop column. Dans ce cas, cette colonne est physiquement supprimée de tous les fragments.

Mais à partir de la version 20.3, le mécanisme des ALTERs a été entièrement modifié, et maintenant les fragments de données sont toujours immutables. Ils ne changent pas du tout - les ALTERs fonctionnent désormais à peu près de la même manière que les merges. Au lieu de modifier un fragment sur place, nous en créons un nouveau. Dans le nouveau fragment, les fichiers qui n'ont pas changé deviennent des hard links, et si nous avons supprimé une colonne, elle sera simplement absente dans le nouveau fragment. L'ancien fragment sera supprimé par défaut après huit minutes, et il est possible d'ajuster les paramètres mentionnés ci-dessus.

Il en va de même pour les ALTERs de type mutations. Lorsque vous effectuez alter delete ou alter update, il ne modifie pas le fragment, mais en crée un nouveau. Puis, il supprime l'ancien.

Que faire si la structure de la table a changé ?

Comment restaurer une sauvegarde qui a été réalisée avec un ancien schéma ? Et la deuxième question concerne le cas des snapshots et des systèmes de fichiers. Btrfs convient-il ici à la place de ZFS sur Linux LVM ?

Si vous réalisez attach partition Si les partitions ont une autre structure, ClickHouse vous dira que ce n'est pas possible. La solution est la suivante. D'abord, créez une table temporaire de type MergeTree avec l'ancienne structure, attachez-y les données à l'aide de attach, puis effectuez une requête alter. Ensuite, vous pouvez soit copier ou transférer ces données et faire un nouvel attache, soit utiliser la requête alter table move partition.

Maintenant, la deuxième question est : peut-on utiliser Btrfs ? Pour commencer, si vous avez LVM, il suffit des snapshots LVM, et le système de fichiers peut être ext4, cela n'a pas d'importance. Avec Btrfs, tout dépend de votre expérience avec. C'est un système de fichiers mature, mais il subsiste des doutes quant à son fonctionnement dans un scénario spécifique. Je ne conseillerais pas de l'utiliser si vous n'avez pas Btrfs en production.

Quelles sont les meilleures pratiques actuelles en matière de reshaping des données ?

La question du re-sharding est complexe et multidimensionnelle. Ici, on peut répondre de plusieurs manières. D'un côté, on peut dire que ClickHouse n'a pas de capacité intégrée de re-sharding. Mais j'ai peur que cette réponse ne convienne à personne. Donc, on peut également dire que ClickHouse offre plusieurs façons de re-sharder les données.

Si l'espace sur le cluster vient à manquer ou qu'il ne gère pas la charge, vous ajoutez de nouveaux serveurs. Mais ces serveurs sont vides par défaut, ils n'ont pas de données et aucune charge ne leur est assignée. Vous devez déplacer des données pour qu'elles soient uniformément réparties sur le nouveau cluster élargi.

La première méthode pour y parvenir est de copier certaines partitions sur de nouveaux serveurs à l'aide de la requête alter table fetch partition. Par exemple, si vous aviez des partitions par mois, vous prenez le premier mois de l'année 2017 et vous le copiez sur un nouveau serveur, puis vous copiez le troisième mois sur un autre nouveau serveur. Et ainsi de suite jusqu'à ce que cela devienne assez uniforme.

Le transfert ne peut être effectué que pour les partitions qui ne changent pas lors de l'écriture. Pour les nouvelles partitions, l'écriture devra être désactivée, car leur transfert n'est pas atomique. Sinon, vous obtiendrez des doublons ou des omissions dans les données. Cela dit, cette méthode est pratique et fonctionne plutôt efficacement. Les partitions compressées prêtes sont transférées sur le réseau, c'est-à-dire que les données ne sont pas recompressées ni re-encodées.

Cette méthode a un inconvénient, qui dépend de la stratégie de sharding. Vous avez prévu cette méthode de sharding, et quel a été votre clé de sharding. Dans votre exemple pour le cas des métriques, la clé de sharding est le hachage du chemin. Lorsque vous faites un select dans la table distribuée, cela va directement vers tous les shards du cluster et récupère les données là-dedans.

Cela signifie que, pour vous, il n'a en fait pas d'importance quelles données se trouvent dans quel shard. L'essentiel est que les données d'un même chemin se trouvent dans un seul shard, et peu importe lequel. Dans ce cas, le transfert de partitions prêtes est parfait car lors des requêtes select, avant et après le resharding, la structure des valeurs n'a pas vraiment d'importance - vous obtiendrez des données complètes.

Mais il arrive aussi des cas plus complexes. Si, au niveau de la logique de l'application, vous vous basez sur une méthode spéciale de sharding, par exemple, si ce client est positionné sur un certain shard, et que la requête peut être envoyée directement là-bas, plutôt qu'à la table distribuée. Ou si vous utilisez une version relativement récente de ClickHouse et que vous avez activé le paramètre optimize skip unused shards. Dans ce cas, lors de la requête select, l'expression dans la section where sera analysée et il sera calculé sur quels shards il est nécessaire d'aller selon la méthode de sharding. Cela fonctionne à condition que les données soient correctement réparties selon ce schéma de sharding. Si vous les avez remaniées manuellement, cette correspondance peut changer.

Donc, c'est la première méthode. J'attends votre retour pour savoir si cela vous convient ou si nous allons plus loin.

Vladimir Kolobaev, administrateur système principal chez Avito: Alexey, la méthode que vous avez mentionnée ne se prête pas très bien à la répartition de la charge, y compris celle de la lecture. Nous pouvons prendre une partition mensuelle et déplacer le mois précédent vers un autre nœud, mais lorsque la requête pour ces données arrivera, nous ne chargerons que celui-ci. Ce que nous aimerions, c'est répartir la charge sur tout le cluster, car sinon, pendant un certain temps, toute la charge de lecture sera traitée par deux shards.

Alexey Milovidov: La réponse est étrange ici - oui, c'est mauvais, mais cela pourrait fonctionner. Je vais expliquer comment. Il faut examiner le scénario de charge qui accompagne vos données. Si ce sont des données de surveillance, on peut presque dire avec certitude que la grande majorité des requêtes porte sur des données récentes.

Vous avez installé de nouveaux serveurs, déplacé d'anciennes partitions, mais vous avez également modifié la façon dont les données récentes sont enregistrées. Et ces données récentes seront dispersées sur tout le cluster. Ainsi, déjà après cinq minutes, les requêtes pour les cinq dernières minutes vont efficacement charger le cluster, et après un jour, les requêtes pour les dernières 24 heures vont également le faire. En revanche, les requêtes pour le mois précédent, malheureusement, ne seront traitées que par une partie des serveurs du cluster.

Mais souvent, vous n'aurez pas de requêtes spécifiquement pour février 2019. Très probablement, si les requêtes portent sur l'année 2019, elles couvriront l'ensemble de l'année, pour une longue période, et non pour une petite plage. Et de telles requêtes pourront également charger le cluster de manière uniforme. Mais dans l'ensemble, votre remarque est tout à fait juste, car c'est une solution ad hoc qui ne répartit pas les données de manière totalement uniforme.

J'ai encore quelques points à aborder pour répondre à la question. L'un d'eux concerne la manière de concevoir au départ le schéma de sharding pour rendre le résharding moins douloureux. Cela n'est pas toujours possible.

Par exemple, vous avez des données de surveillance. Les données de surveillance augmentent pour trois raisons. La première est l'accumulation de données historiques. La deuxième est l'augmentation du trafic. Et la troisième est l'accroissement du nombre d'éléments qui sont soumis à la surveillance. De nouveaux microservices et métriques apparaissent, qui doivent être conservés.

Il est possible que la plus forte croissance soit liée à la troisième raison - l'augmentation de l'utilisation de la surveillance. Dans ce cas, il convient d'examiner la nature de la charge, quelles sont les principales requêtes pour le select. Les principales requêtes pour le select vont probablement concerner un sous-ensemble de métriques.

Par exemple, l'utilisation du CPU sur certains serveurs par un service quelconque. Il en résulte qu'il existe un certain sous-ensemble de clés à partir duquel vous extrayez ces données. Et la requête pour ces données est très probablement assez simple et s'exécute en quelques dizaines de millisecondes. Elle est utilisée pour les services de surveillance, pour les tableaux de bord. J'espère que je comprends cela correctement.

Vladimir Kolobaev: Le fait est que nous faisons souvent appel à des données historiques, car nous comparons en temps réel la situation actuelle à l'historique. Et il est important pour nous d'avoir un accès rapide à un grand volume de données, et ClickHouse gère cela très bien.

Vous avez tout à fait raison, la plupart des requêtes de lecture que nous rencontrons sont celles de la dernière journée, comme dans tout système de surveillance. Cependant, la charge sur les données historiques est également assez élevée. Elle provient principalement du système d'alerte, qui toutes les trente secondes interroge ClickHouse : « Donne-moi les données des six dernières semaines. Et maintenant, construis-moi une certaine moyenne mobile à partir de ces données, et comparons la valeur actuelle à l'historique. »

Je voudrais dire qu'il existe pour ces requêtes très récentes une petite table supplémentaire dans laquelle nous stockons seulement deux jours de données, et les requêtes principales vont vers celle-ci. Dans la grande table sharded, nous envoyons uniquement les grosses requêtes historiques.

Alexey Milovidov: Malheureusement, pour votre scénario, cela semble inadapté, mais je vais vous décrire deux schémas de sharding mauvais et complexes qu'il ne faut pas utiliser, mais qui sont utilisés par le service de mes amis.

Il y a un cluster principal avec des événements de « Yandex.Metrica ». Les événements sont des vues de pages, des clics et des transitions. La plupart des requêtes concernent un site web spécifique. Vous ouvrez le service « Yandex.Metrica », vous avez un site — avito.ru, vous allez dans le rapport et la requête se fait pour votre site.

Mais il existe aussi d'autres requêtes - analytiques et globales, réalisées par des analystes internes. À toutes fins utiles, je précise que les analystes internes effectuent des requêtes uniquement sur les services de « Yandex ». Cependant, même les services de « Yandex » représentent une part substantielle de toutes les données. Ce sont des requêtes non pas sur des compteurs spécifiques, mais sur une filtration plus large.

Comment organiser les données de manière à ce qu'elles fonctionnent efficacement à la fois pour un seul compteur et pour les requêtes globales ? La complexité réside également dans le fait que le nombre de requêtes dans ClickHouse sur le cluster « Métriques » est de plusieurs milliers par seconde. Avec des requêtes non triviales, par exemple, plusieurs milliers par seconde, un seul serveur ClickHouse ne peut pas le gérer.

La taille du cluster est d'un peu plus de six cents serveurs. Si l'on se contente d'étendre une table Distributed sur ce cluster et d'envoyer plusieurs milliers de requêtes, cela ne fera qu'empirer la situation par rapport à l'envoi sur un seul serveur. D'un autre côté, l'option où les données sont uniformément réparties et où nous interrogeons tous les serveurs est immédiatement écartée.

Il existe une option diamétralement opposée. Imaginez que nous shardons les données par sites, et qu'une requête pour un seul site aille sur un seul shard. Le cluster pourrait alors gérer dix mille requêtes par seconde, mais sur un shard, une seule requête fonctionnerait beaucoup trop lentement. Elle ne pourra pas évoluer en termes de bande passante, surtout s'il s'agit du site avito.ru. Je ne vais pas révéler de secret en disant qu'Avito est l'un des sites les plus visités du Runet. Et traiter cela sur un seul shard serait insensé.

C'est pourquoi le schéma de sharding est conçu de manière plus astucieuse. L'ensemble du cluster est divisé en un certain nombre de petits clusters que nous appelons des couches. À l'intérieur de chaque petit cluster, il y a de dix à plusieurs dizaines de shards. Au total, il y a trente-neuf de ces petits clusters.

Comment cela se développe-t-il ? Le nombre de petits clusters ne change pas : il y a toujours eu trente-neuf il y a quelques années et il en reste ainsi. Mais à l'intérieur de chacun d'eux, nous augmentons progressivement le nombre de shards à mesure que les données s'accumulent. Le schéma de sharding est donc le suivant : la division en ces petits clusters se fait par sites web, et pour comprendre quel site est sur quel petit cluster, nous utilisons une base de données distincte dans MySQL. Un site — un petit cluster. Et à l'intérieur, le sharding se fait par identifiants de visiteurs.

Lors de l'enregistrement, nous les divisons en fonction du reste de la division de l'identifiant du visiteur. Mais lors de l'ajout d'une nouvelle shard, le schéma de sharding change, nous continuons à diviser, mais cette fois selon un autre nombre. Cela signifie qu'un même visiteur peut effectivement se trouver sur plusieurs serveurs, et en compter dessus n'est pas une option. Cela a été fait uniquement pour améliorer la compression des données. Lors des requêtes, nous accédons à la table Distributed, qui consulte le cluster et interroge des dizaines de serveurs. Voilà un schéma quelque peu absurde.

Mais mon récit serait incomplet si je ne mentionnais pas que nous avons abandonné ce schéma. Dans le nouveau schéma, tout a été modifié et toutes les données ont été copiées à l'aide de clickhouse-copier.

Dans le nouveau schéma, tous les sites sont divisés en deux catégories : grands et petits. Je ne sais pas comment le seuil a été choisi, mais en fin de compte, il s'est avéré que les grands sites sont enregistrés sur un cluster avec 120 shards et trois répliques chacun - c'est-à-dire 360 serveurs. Et le schéma de sharding est tel que chaque requête va immédiatement vers tous les shards. Si vous ouvrez maintenant n'importe quelle page de rapport pour avito.ru dans « Yandex.Metrika », la requête sera envoyée à 120 serveurs. Il y a peu de grands sites dans le RuNet. Et le nombre de requêtes n'atteint pas mille par seconde, mais est même inférieur à une centaine. Tout cela est géré sans souci par la table Distributed, qui est traitée par 120 serveurs.

Le deuxième cluster est destiné aux petits sites. Ici, le schéma de sharding se fait selon l'identifiant du site, et chaque requête va précisément vers un shard.

ClickHouse dispose d'un utilitaire appelé clickhouse-copier. Pouvez-vous en parler ?

Je dois dire tout de suite que cette solution est plus encombrante et un peu moins performante. L'avantage est qu'elle répartit complètement les données selon le schéma que vous spécifiez. Mais l'inconvénient de l'utilitaire est qu'il ne réalise pas de re-sharding. Il copie les données d'un schéma de cluster à un autre schéma de cluster.

Cela signifie que pour son fonctionnement, vous devez disposer de deux clusters. Ils peuvent être situés sur les mêmes serveurs, mais pourtant, les données ne seront pas déplacées de manière incrémentale, mais seront copiées.

Par exemple, il y avait quatre serveurs, maintenant il y en a huit. Vous créez une nouvelle table distribuée sur tous les serveurs, de nouvelles tables locales et vous lancez clickhouse-copier. Dans celui-ci, vous spécifiez le schéma de travail, qu'il doit lire de l'endroit, accepter le nouveau schéma de sharding et transférer les données là-bas. Et vous aurez besoin d'un espace sur les anciens serveurs une fois et demie plus que ce que vous avez actuellement, car les anciennes données doivent y rester, et en plus, une partie de ces anciennes données viendra s'y ajouter. Si vous avez pensé à l'avance que les données devaient être resharded et que vous avez de la place, alors cette méthode fonctionnera.

Comment clickhouse-copier est-il organisé en interne ? Il divise tout le travail en un ensemble de tâches de traitement d'une partition d'une table sur un shard. Toutes ces tâches peuvent être exécutées en parallèle, et clickhouse-copier peut être lancé sur différentes machines en plusieurs instances, mais ce qu'il fait pour une partition, c'est rien d'autre qu'un insert select. Les données sont lues, décompressées, repartitionnées, puis à nouveau compressées, enregistrées quelque part, réorganisées. C'est une solution plus lourde.

Vous aviez un projet pilote appelé reshaping. Qu'en est-il ?

Vous aviez encore en 2017 un projet pilote appelé resharding. Il y a même une option dans ClickHouse. Je comprends que cela n’a pas décollé. Pouvez-vous expliquer pourquoi cela s'est produit ? Il semble que ce soit très pertinent.

Tout le problème est que lors de la nécessité de resharder des données sur place, une synchronisation très complexe est requise pour le faire de manière atomique. Lorsque nous avons commencé à examiner comment cette synchronisation était organisée, il est devenu clair qu'il y avait des problèmes fondamentaux. Et ces problèmes fondamentaux ne sont pas uniquement théoriques, mais se sont immédiatement manifestés dans la pratique par le fait que l'on peut expliquer très simplement - rien ne fonctionne.

Peut-on fusionner toutes les parties des données avant de les déplacer sur des disques lents ?

Une question sur le TTL avec l’option déplacer vers un disque lent dans le contexte des fusions. Y a-t-il un moyen, autre que par cron, de fusionner toutes les partitions en une seule avant de les déplacer vers les disques lents ?

La réponse à la question de savoir s'il est possible de fusionner automatiquement tous les morceaux en un avant leur transfert est non. Il me semble qu'il n'est pas nécessaire de le faire. Il est possible de ne pas fusionner toutes les parties en une seule, mais simplement de compter sur le fait qu'elles seront transférées sur les disques lents automatiquement.

Nous avons deux critères pour le transfert. Le premier est basé sur le taux d'occupation. Si le niveau actuel de stockage a moins d'un certain pourcentage d'espace libre, nous choisissons un morceau et le transférons sur un stockage plus lent. En fait, ce n'est pas juste plus lent, mais le suivant - comme vous le configurez.

Le deuxième critère est la taille. Il concerne le transfert de gros morceaux. Vous pouvez ajuster le seuil d'espace libre sur le disque rapide, et les données seront transférées automatiquement.

Comment passer à de nouvelles versions de ClickHouse si je n'ai pas la possibilité de vérifier la compatibilité à l'avance ?

Ce sujet est régulièrement discuté dans le chat Telegram ClickHouse , en tenant compte des différentes versions, et pourtant. À quel point est-il sûr de mettre à jour de la version 19.11 à 19.16 et, par exemple, de 19.16 à 20.3 ? Comment mieux passer aux nouvelles versions sans avoir la possibilité de vérifier la compatibilité dans un bac à sable à l'avance ?

Il y a plusieurs règles « d'or ». La première est lisez le changelog. Il est long, mais il contient des points spécifiques sur les changements incompatibles. Ne considérez pas ces points comme des drapeaux rouges. En général, ce sont de petites incompatibilités liées à certaines fonctionnalités marginales qui, très probablement, ne vous concernent pas.

Deuxième règle - si vous n'avez pas la possibilité de vérifier la compatibilité dans un bac à sable, et que vous souhaitez mettre à jour directement en production, la recommandation est de ne pas le faire. Créez d'abord un bac à sable et vérifiez. S'il n'y a pas d'environnement de test, alors vous n'êtes probablement pas une très grande entreprise, donc vous pouvez copier une partie des données sur votre ordinateur portable et vérifier que tout fonctionne correctement. Vous pouvez même lancer plusieurs répliques localement sur votre machine. Ou vous pouvez mettre en place une nouvelle version à proximité et y importer une partie des données - en d'autres termes, créer un environnement de test improvisé.

Une autre règle est de ne pas mettre à jour pendant une semaine après la sortie de la version en raison de la chasse aux bugs en production et des corrections rapides qui s'ensuivent. Comprenons la numérotation des versions ClickHouse pour ne pas nous perdre.

Il existe une version 20.3.4. Le chiffre 20 désigne l'année de sortie — 2020. D'un point de vue technique, cela n'a aucune importance, donc nous n'y prêterons pas attention. Ensuite, 20.3. Le deuxième chiffre — dans ce cas 3 — augmente chaque fois que nous publions une version avec de nouvelles fonctionnalités. Si nous souhaitons ajouter une fonctionnalité à ClickHouse, nous sommes obligés d'augmenter ce chiffre. Ainsi, dans la version 20.4, ClickHouse fonctionnera encore mieux. Le troisième chiffre — 20.3.4. Ici, 4 indique le nombre de versions de correction où nous n'avons pas ajouté de nouvelles fonctionnalités, mais avons corrigé certains bogues. Et 4 signifie que nous avons fait cela quatre fois.

Il ne faut pas penser que c'est quelque chose de terrible. En général, un utilisateur peut installer la version la plus récente et elle fonctionnera sans problème avec un temps de fonctionnement d'un an. Mais imaginez que dans une fonction de traitement de bitmaps, ajoutée par nos camarades chinois, un serveur plante à cause d'arguments incorrects. Nous devons corriger cela. Nous publierons une nouvelle version de correction, et ClickHouse deviendra plus stable.

Si vous avez ClickHouse en production, et qu'une nouvelle version de ClickHouse avec des fonctionnalités supplémentaires sort — par exemple, 20.4.1 — n'ayez pas hâte de l'installer en production le premier jour. À quoi cela sert-il vraiment ? Si vous n'utilisez pas encore ClickHouse, vous pouvez l'installer, et tout ira probablement bien. Mais si ClickHouse fonctionne déjà de manière stable, suivez les mises à jour et les corrections — quels problèmes nous avons résolus.

Kirill Shvakov : Je souhaite ajouter quelques éléments concernant les environnements de test. Beaucoup craignent les environnements de test et pensent que si vous avez un très grand cluster ClickHouse, l'environnement de test doit être au moins aussi grand ou dix fois plus petit. C'est tout à fait faux.

Je peux partager mon expérience. J'ai un projet qui utilise ClickHouse. Notre environnement de test pour cela est une petite machine virtuelle chez Hetzner pour vingt euros, où tout est déployé. Pour cela, nous avons une automatisation complète avec Ansible, donc il n'y a pratiquement aucune différence entre déployer sur des serveurs physiques ou simplement dans des machines virtuelles.

Que peut-on faire ? Ce serait bien d'ajouter un exemple dans la documentation de ClickHouse sur la manière de déployer un petit cluster chez soi — en Docker, en LXC, ou éventuellement de créer un playbook Ansible, car chaque personne a des déploiements différents. Cela simplifierait beaucoup de choses. Quand tu peux déployer un cluster en cinq minutes, c'est bien plus facile de comprendre certains aspects. C'est beaucoup plus pratique, car aller en production avec une version que tu n'as pas testée — c'est un chemin sans retour. Parfois ça fonctionne, parfois non. Donc compter sur le succès — c'est risqué.

Maxim Kotyakov, ingénieur backend senior chez Avito : Je vais ajouter quelques éléments sur les environnements de test liés aux problèmes des grandes entreprises. Nous avons un cluster ClickHouse de validation complet, qui est une copie exacte des schémas de données et des configurations de notre production. Ce cluster est déployé dans des conteneurs assez modestes avec un minimum de ressources. Nous y écrivons un certain pourcentage de données de production, car nous avons la possibilité de répliquer le flux dans Kafka. Tout est synchronisé et scalé — tant en termes de puissance que de flux, et, en théorie, dans des conditions similaires, il devrait se comporter comme la production selon les métriques. Tout ce qui est potentiellement explosif passe d'abord sur cette plateforme et y reste quelques jours pour maturation. Mais évidemment, cette solution est coûteuse, lourde et avec des coûts non négligeables de maintenance.

Alexey Milovidov: Je vais parler de l'environnement de test de nos amis de Yandex.Metrica. Un cluster avait plus de 600 serveurs, un autre en avait 360, et il y a aussi un troisième cluster et plusieurs autres. L'environnement de test pour l'un d'eux consiste en deux shards avec deux répliques chacun. Pourquoi deux shards ? Pour avoir plus d'un shard. Et les répliques également pour assurer la redondance. Juste un minimum que l'on peut se permettre.

Cet environnement de test permet de vérifier le bon fonctionnement des requêtes et de s'assurer que rien de majeur n'est défaillant. Mais il arrive souvent que des problèmes d'un autre type surviennent, quand tout fonctionne, mais qu'il y a des petites variations avec la charge.

Voici un exemple. Nous avons décidé d'installer une nouvelle version de ClickHouse. Elle a été mise sur l'environnement de test, les tests automatisés de Yandex.Metrica ont été effectués, comparant les données de l'ancienne version à celles de la nouvelle, en passant par tout le pipeline. Et bien sûr, les tests de notre CI étaient tous verts. Sinon, nous n'aurions même pas proposé cette version.

Tout se passe bien. Nous commençons à déployer en production. Je reçois un message indiquant que la charge sur les graphiques a augmenté plusieurs fois. Nous revenons à la version précédente. Je regarde le graphique et je vois : la charge a effectivement augmenté plusieurs fois pendant le déploiement, puis elle a diminué lorsque nous avons effectué le retour arrière. Ensuite, nous avons commencé à revenir à la version précédente. Et la charge a également augmenté de la même manière et a de nouveau chuté. Donc, la conclusion est que la charge a augmenté en lien avec le déploiement, rien d'étonnant.

Par la suite, il a été difficile de convaincre mes collègues de finalement installer la nouvelle version. Je dis : « Tout va bien, déployez-la. Croisez les doigts, tout va fonctionner. Actuellement, la charge a augmenté sur les graphiques, mais tout va bien. Tenez bon ». En gros, nous avons fait ça, et voilà — la version est mise en production. Mais presque à chaque déploiement, des problèmes similaires surgissent.

Kill query devrait tuer les requêtes, mais ce n'est pas le cas. Pourquoi ?

Un utilisateur est venu me voir, un analyste, et a créé une requête qui a mis mon cluster ClickHouse à l'arrêt. Une nœud ou le cluster entier — selon la réplique ou le shard où la requête est tombée. Je vois que toutes les ressources CPU de ce serveur sont à leur maximum, tout est rouge. Cependant, ClickHouse répond aux requêtes. Et j'écris : « Montre-moi, s'il te plaît, la liste des processus, quelle requête a engendré cette folie ».

Je trouve cette requête et je lui envoie un kill. Et je vois que rien ne se passe. Mon serveur est à son maximum, ClickHouse me renvoie encore quelques commandes, montre que le serveur est vivant, et tout va bien. Mais j'ai une dégradation dans toutes les requêtes utilisateurs, la dégradation commence aussi pour l'écriture dans ClickHouse, et ma commande de kill ne fonctionne pas. Pourquoi ? Je pensais que le kill devait arrêter les requêtes, mais ce n'est pas le cas.

La réponse va être plutôt étrange. Le fait est que le kill ne tue pas les requêtes.

Le kill établit un petit drapeau intitulé « je veux que cette requête soit tuée ». Et la requête, lorsqu'elle traite chaque bloc, vérifie ce drapeau. Si il est activé, la requête s'arrête. Donc, personne ne tue la requête, elle doit vérifier et s'arrêter toute seule. Et cela doit fonctionner dans tous les cas où la requête est en train de traiter des blocs de données. Elle traitera le prochain bloc de données, vérifiera le drapeau et s'arrêtera.

Cela ne fonctionne pas dans les cas où la requête est bloquée pour une certaine opération. Cependant, il est peu probable que ce soit votre cas, car, d'après vos dires, cela utilise beaucoup de ressources serveur. Il est possible que cela ne fonctionne pas pour un tri externe et encore d'autres détails. Mais en général, cela ne devrait pas se produire, c'est un bug. La seule chose que je peux conseiller, c'est de mettre à jour ClickHouse.

Comment calculer le temps de réponse sous charge de lecture ?

Il y a une table qui stocke des agrégats par item – divers compteurs. Le nombre de lignes est d'environ cent millions. Peut-on s'attendre à un temps de réponse prévisible si l'on injecte 1K RPS avec 1K items ?

D'après le contexte, il s'agit d'une charge de lecture, car il n'y a aucun problème d'écriture – on peut insérer autant de milliers, voire des centaines de milliers, et parfois plusieurs millions de lignes.

Les requêtes de lecture sont très variées. Dans un select 1, ClickHouse peut exécuter environ des dizaines de milliers de requêtes par seconde, donc même des requêtes pour une seule clé nécessiteront certaines ressources. Et ces requêtes ponctuelles seront plus complexes que dans des bases de données de type key-value, car pour chaque lecture, il faut lire un bloc de données par index. L'index ne pointe pas vers chaque enregistrement, mais vers chaque plage. Cela signifie qu'il faudra lire toute la plage - cela représente 8192 lignes par défaut. Et il faudra décompresser un bloc de données compressé de 64 Ko à 1 Mo. En général, de telles requêtes ponctuelles prennent quelques millisecondes. Mais c'est la version la plus simple.

Essayons de faire une simple arithmétique. Si l'on multiplie quelques millisecondes par mille, cela donne quelques secondes. Comme si maintenir mille requêtes par seconde n'était pas possible, mais en réalité c'est faisable, car nous avons plusieurs cœurs de processeur. Donc en principe, 1000 RPS, ClickHouse peut parfois le maintenir, mais pour des requêtes courtes, en effet ponctuelles.

Si vous devez faire évoluer le cluster ClickHouse en nombre de requêtes simples, je recommande la solution la plus simple - augmenter le nombre de répliques et envoyer des requêtes à une réplique aléatoire. Si une réplique peut supporter cinq cents requêtes par seconde, ce qui est tout à fait réaliste, alors trois répliques supporteront mille cinq cents.

Parfois, bien sûr, il est possible de configurer ClickHouse pour un maximum de lectures ponctuelles. Que faut-il pour cela ? Premièrement, réduire la granularité de l'index. Toutefois, il convient de la diminuer non pas à une unité, mais en fonction du nombre d'enregistrements dans l'index, qui sera de plusieurs millions ou dizaines de millions sur le serveur. Si la table contient cent millions de lignes, vous pouvez définir la granularité à 64.

Il est possible de réduire la taille du bloc compressé. Pour cela, il y a des paramètres. min compress block size, max compress block size. Ils peuvent être réduits, les données réajustées, et alors les requêtes ponctuelles seront plus rapides. Mais tout de même, ClickHouse n'est pas une base de données clé-valeur. Un grand nombre de petites requêtes est un antipattern de charge.

Kirill Shvakov : Je vais donner un conseil au cas où il y aurait des compteurs ordinaires. C'est une situation assez standard lorsque ClickHouse stocke un certain compteur. J'ai un utilisateur, il vient d'un tel pays, avec un troisième champ, et il faut incrémenter quelque chose. Vous prenez MySQL, vous créez une clé unique - dans MySQL, c'est une clé dupliquée, et dans PostgreSQL, c'est un conflit - et vous ajoutez avec un plus. Cela fonctionnera beaucoup mieux.

Lorsque vous avez peu de données, il n'y a pas vraiment de sens à utiliser ClickHouse. Il existe des bases de données ordinaires qui s'en sortent très bien.

Que peut-on ajuster dans ClickHouse pour avoir plus de données en cache ?

Imaginons une situation : sur les serveurs, il y a 256 Go de RAM, dans la routine quotidienne, ClickHouse utilise environ 60 à 80 Go, avec un pic allant jusqu'à 130. Que peut-on activer et ajuster pour avoir plus de données en cache et, par conséquent, moins d'accès au disque ?

En règle générale, le cache des pages du système d'exploitation s'acquitte bien de cette tâche. Si vous ouvrez simplement le top, que vous regardez là-bas cached ou free - il est aussi mentionné combien est mis en cache - vous pouvez constater que toute la mémoire libre est utilisée pour le cache. Et ces données seront lues non pas à partir du disque, mais de la RAM. À cet égard, je peux dire que le cache est utilisé efficacement, car ce sont les données compressées qui sont mises en cache.

Cependant, si vous souhaitez accélérer encore davantage certaines requêtes simples, il existe la possibilité d'activer à l'intérieur de ClickHouse le cache des données non compressées. Cela s'appelle uncompressed cacheDans le fichier de configuration config.xml, vous devez définir la taille du cache non compressé à la valeur souhaitée - je recommande de ne pas dépasser la moitié de la RAM libre, car le reste sera utilisé pour le cache de page.

De plus, il existe deux paramètres au niveau de la requête. Le premier paramètre est utiliser le cache non compressé - qui active son utilisation. Il est recommandé de l'activer pour toutes les requêtes, sauf pour celles lourdes qui peuvent lire toutes les données et ainsi vider ce cache. Et le second paramètre est quelque chose comme le nombre maximum de lignes à utiliser pour le cache. Il limite automatiquement les grandes requêtes afin qu'elles contournent le cache.

Comment configurer storage_configuration pour un stockage en mémoire ?

Dans la nouvelle documentation de ClickHouse, j'ai trouvé une section relative au stockage des données. Dans la description, il y a un exemple avec un SSD rapide.

Il est intéressant de savoir comment configurer la même chose avec de la mémoire à chaud. Et une autre question. Comment fonctionne le select avec cette organisation de données, lira-t-il l'ensemble des données ou seulement celles qui sont sur le disque, et ces données sont-elles compressées en mémoire ? Et comment fonctionne la section prewhere avec cette organisation de données ?

Ce paramètre influence le stockage des morceaux de données, et leur format ne change en rien.
Examinons cela plus en détail.

Il est possible de configurer le stockage des données en mémoire. Tout ce qui est configuré pour le disque, c'est son chemin. Vous créez une partition tmpfs, qui est montée à un certain chemin dans le système de fichiers. Vous indiquez ce chemin comme celui de stockage des données pour la partition la plus chaude, y compris les morceaux de données qui commencent à être envoyés et écrits, tout va bien.

Mais je ne recommande pas de le faire en raison de la faible fiabilité, bien que si vous avez au moins trois répliques dans différents centres de données, cela peut être fait. Au cas où, les données seront récupérées. Imaginons qu'un serveur s'arrête subitement puis redémarre. La partition est remontée à nouveau, mais elle est vide. Le serveur ClickHouse, au démarrage, voit que ces morceaux sont manquants, alors que selon les métadonnées de ZooKeeper, ils devraient être présents. Il vérifie sur quelles répliques ils existent, les demande et les télécharge. Ainsi, les données seront récupérées.

En ce sens, le stockage des données en RAM ne diffère fondamentalement pas de leur stockage sur disque, car lorsqu'on écrit des données sur disque, elles passent aussi d'abord par le cache de pages et sont physiquement enregistrées de manière différée. Cela dépend du mode de montage du système de fichiers. Mais pour être sûr, je dirai que ClickHouse ne fait pas de fsync lors de l'insertion.

Les données en mémoire sont stockées exactement dans le même format que sur disque. La requête select sélectionne tout aussi précisément les morceaux à lire, choisissant les plages de données nécessaires, et les lit. Le pré-filtrage fonctionne exactement de la même manière, que les données soient en RAM ou sur disque.

Jusqu'à quel nombre de valeurs uniques Low Cardinality est-il efficace ?

Low Cardinality est astucieusement conçu. Il crée des dictionnaires de données, mais ceux-ci sont locaux. Tout d'abord, chaque morceau a ses propres dictionnaires, et ensuite, même à l'intérieur d'un même morceau, ils peuvent être différents pour chaque plage. Lorsque le nombre de valeurs uniques atteint un seuil - je crois que c'est un million - le dictionnaire est simplement mis de côté et un nouveau est créé.

La réponse en gros : pour chaque plage locale - disons, pour chaque jour - jusqu'à environ un million de valeurs uniques, Low Cardinality est efficace. Au-delà, il y aura simplement un fallback, où de nombreux dictionnaires différents seront utilisés au lieu d'un seul. Cela fonctionnera à peu près comme une colonne de type string, peut-être un peu moins efficacement, mais il n'y aura pas de dégradations de performance significatives.

Quelles sont les meilleures pratiques pour la recherche en texte intégral sur une table de cinq milliards de lignes ?

Il existe différentes options de réponse. La première est de dire que ClickHouse n'est pas un système pour la recherche en texte intégral. Pour cela, il existe des systèmes spéciaux, par exemple, Elasticsearch et Sphinx. Néanmoins, je rencontre de plus en plus de gens qui disent qu'ils passent d'Elasticsearch à ClickHouse.

Pourquoi cela se produit-il ? Ils expliquent que Elasticsearch ne parvient plus à gérer la charge à certains volumes, notamment en ce qui concerne la construction des index. Les index deviennent trop encombrants, et si l'on transfère simplement les données dans ClickHouse, elles seront stockées de manière plusieurs fois plus efficace en termes de volume. De plus, les requêtes de recherche étaient souvent telles qu'il ne fallait pas trouver dans l'ensemble des données une phrase en tenant compte de la morphologie, mais des choses complètement différentes. Par exemple, trouver dans les logs des dernières heures une sous-séquence de bytes.

Dans ce cas, vous créez un index dans ClickHouse, dont le premier champ sera la date avec l'heure. Et la principale restriction des données sera précisément sur la plage de dates. À l'intérieur de la plage de dates choisie, il est généralement possible d'effectuer une recherche en texte intégral même par méthode brute-force à l'aide de like. L'opérateur like dans ClickHouse est le plus efficace que vous puissiez trouver. Si vous en trouvez un meilleur, faites-le moi savoir.

Mais quand même, like est un scan complet. Et le scan complet peut être lent non seulement en termes de CPU, mais aussi sur le disque. Si vous avez un teraoctet de données par jour, et que vous cherchez un mot en une journée, vous devrez scanner un teraoctet. Et il est sûrement sur des disques durs ordinaires, et au final, ils seront chargés au point que vous ne pourrez pas accéder à ce serveur par SSH.

Dans ce cas, je suis prêt à proposer une autre petite astuce. C'est du genre expérimental - ça peut fonctionner, ou peut-être pas. ClickHouse dispose d'index en texte intégral sous forme de filtres de Bloom trigrammes. Nos collègues de la société Arenadata ont déjà testé ces index, et il s'avère souvent qu'ils fonctionnent exactement comme prévu.

Pour les utiliser correctement, il faut bien comprendre comment ils fonctionnent : ce qu'est un filtre de Bloom trigramme et comment choisir sa taille. Je peux dire qu'ils aideront pour les requêtes sur des phrases rares, des sous-chaînes qui apparaissent rarement dans les données. Dans ce cas, des sous-intervalles seront sélectionnés par les index, et moins de données seront lues.

Récemment, ClickHouse a introduit des fonctions encore plus avancées pour la recherche en texte intégral. Tout d'abord, la recherche de plusieurs sous-chaînes en une seule passe, y compris les variantes tenantes compte de la casse, sans tenir compte de la casse, avec le support de l'UTF-8 ou uniquement pour l'ASCII. Choisissez le plus efficace selon vos besoins.

Il est également possible de rechercher plusieurs expressions régulières en une seule passe. Vous n'avez pas besoin d'écrire X like une sous-chaîne ou X like une autre sous-chaîne. Écrivez tout d'un coup, et tout s'exécute de manière maximale et efficace.

Troisièmement, il y a désormais une recherche approximative des regex et une recherche approximate de sous-chaînes. Si quelqu'un a écrit un mot avec une faute de frappe, il sera recherché selon la correspondance maximale.

Comment organiser l'accès à ClickHouse pour un grand nombre d'utilisateurs ?

Expliquez comment organiser au mieux l'accès pour un grand nombre de consommateurs et d'analystes. Comment former une file d'attente, prioriser les requêtes max concurrent queries, et avec quels outils ?

Si le cluster est suffisamment grand, une bonne solution serait de déployer deux autres serveurs, qui serviront de points d'entrée pour les analystes. C'est-à-dire ne pas donner accès aux analystes à des shards spécifiques du cluster, mais simplement créer deux serveurs vides, sans données, et configurer les droits d'accès dessus. En même temps, les réglages des utilisateurs pour des requêtes distribuées sont transférés sur les serveurs distants. Vous configurez tout sur ces deux serveurs, et les réglages ont un effet sur tout le cluster.

En principe, ces serveurs sont sans données, mais la quantité de mémoire vive sur eux est très importante pour l'exécution des requêtes. Le disque peut également être utilisé pour des données temporaires, si l'agrégation externe ou le tri externe est activé.

Il est important de vérifier les configurations liées à toutes les limites possibles. Si je vais maintenant sur le cluster « Yandex.Metrics » en tant qu'analyste et que je pose une requête select count from hits, je recevrai immédiatement une exception indiquant que je ne peux pas exécuter la requête. Le nombre maximal de lignes que je suis autorisé à scanner est de cent milliards, alors qu'il y a au total cinquante trillions dans une seule table du cluster. C'est la première limitation.

Supposons que je retire la limite sur le nombre de lignes et que j'exécute la requête à nouveau. Dans ce cas, je verrai la prochaine exception - la configuration force index by date. Je ne peux pas exécuter la requête si je n'ai pas spécifié la plage de dates. Il ne faut pas compter sur le fait que les analystes vont la spécifier manuellement. Un cas typique est que la plage de dates est écrite where event date between semaine. Et puis, simplement, une parenthèse a été mal placée, et au lieu de and, cela a donné or - or URL match. Si aucune limite n'est définie, elle va scanner la colonne URL et dépenser une tonne de ressources.

De plus, ClickHouse a deux réglages de priorité. Malheureusement, ils sont très primitifs. L'un s'appelle simplement prioritySi priority ≠ 0 et que des requêtes sont exécutées avec un certain prioritaire, mais qu'une requête avec un prioritaire ayant une valeur inférieure, ce qui signifie un prioritaire plus élevé, est en cours d'exécution, alors la requête avec une valeur de prioritaire plus élevée, ce qui implique un prioritaire plus bas, est simplement suspendue et ne fonctionnera pas du tout pendant ce temps.

C'est un réglage très grossier et il n'est pas adapté aux cas où il y a une charge constante sur le cluster. Mais si vous avez de courtes requêtes impulsives qui sont importantes et que le cluster est principalement inactif, ce réglage peut convenir.

Le réglage des priorités suivant s'appelle priorité des threads OS. Il fixe simplement pour tous les threads d'exécution de requête la valeur nice pour le planificateur Linux. Cela fonctionne moyennement, mais ça fonctionne quand même. Si vous fixez la valeur nice la plus basse - elle est la plus élevée en valeur, ce qui signifie le prioritaire le plus bas - et pour les requêtes à haute priorité, vous fixez -19, le CPU consommera des requêtes à faible priorité environ quatre fois moins que celles à haute priorité.

Il faut également régler le temps d'exécution maximum des requêtes - disons, cinq minutes. La vitesse d'exécution minimale des requêtes - c'est le plus cool. Ce réglage existe depuis longtemps et est nécessaire pour ne pas seulement affirmer que ClickHouse ne ralentit pas, mais pour y parvenir.

Imaginez que vous configurez : si une requête traite moins d'un million de lignes par seconde - cela ne peut pas être fait. Cela ternit notre bon nom, notre bonne base de données. Interdisons cela tout simplement. Il y a en fait deux réglages. L'un s'appelle vitesse d'exécution minimale — en lignes par seconde, et le second s'appelle le délai avant vérification de la vitesse d'exécution minimale - par défaut quinze secondes. Donc quinze secondes c'est acceptable, et ensuite, si c'est lent, il suffit de lancer une exception - d'interrompre la requête.

Il faut également régler les quotas. ClickHouse a une fonctionnalité de quotas intégrée qui calcule la consommation des ressources. Mais malheureusement, cela ne concerne pas les ressources matérielles comme le CPU, les disques, mais les ressources logiques - le nombre de requêtes traitées, de lignes et d'octets lus. Et vous pouvez définir, par exemple, un maximum de cent requêtes en cinq minutes et mille requêtes par heure.

Pourquoi est-ce important ? Parce qu'une partie des requêtes analytiques sera exécutée manuellement directement depuis le client ClickHouse. Et tout ira bien. Mais si vous avez des analystes avancés dans votre entreprise, ils écriront un script, et il peut y avoir une erreur dans le script. Et cette erreur conduira à ce que la requête s'exécute dans une boucle infinie. C'est ce dont il faut se protéger.

Peut-on envoyer les résultats d'une requête à dix clients ?

Nous avons plusieurs utilisateurs qui aiment soumettre des requêtes très lourdes en même temps. La requête est grande, elle s'exécute généralement rapidement, mais à cause du grand nombre de requêtes simultanées, cela devient très pénible. Est-il possible d'exécuter une même requête qui a été envoyée dix fois de suite une fois et de donner le résultat à dix clients ?

Le problème est que nous n'avons pas de résultats en cache ou de cache de données intermédiaires. Il y a le cache de page du système d'exploitation, qui permet de ne pas lire les données depuis le disque à nouveau, mais malheureusement, les données devront tout de même être décompressées, désérialisées et retravaillées.

Nous aimerions éviter cela d'une manière ou d'une autre, soit en mettant en cache les données intermédiaires, soit en organisant des requêtes similaires dans une sorte de queue et en ajoutant un cache des résultats. Nous avons actuellement un pull request en développement qui ajoute un cache des requêtes, mais seulement pour les sous-requêtes dans les sections in et join — c'est-à-dire que la solution n'est pas complète.

Néanmoins, nous rencontrons également cette situation. Un exemple canonique en est les requêtes avec pagination. Il existe un rapport qui comporte plusieurs pages, et il y a une requête limit 10. Puis la même chose, mais limit 10,10. Ensuite, voici encore la page suivante. Et on se demande pourquoi nous calculons cela à chaque fois ? Mais pour l'instant, il n'y a pas de solution, et il est impossible d'y échapper.

Il existe une solution alternative qui s'installe en sidecar à côté de ClickHouse — ClickHouse Proxy.

Kirill Shvakov : ClickHouse Proxy a un limiteur de taux intégré et un cache des résultats. Il possède de nombreuses configurations car un problème similaire a été résolu. Le Proxy permet de limiter les requêtes en les organisant dans une file d'attente, et de configurer la durée de vie du cache des requêtes. Si les requêtes étaient effectivement identiques, le Proxy les renverra plusieurs fois, tout en interrogeant ClickHouse une seule fois.

Nginx dispose également d'un cache dans sa version gratuite, et cela fonctionnera aussi. Nginx a même des paramètres pour gérer les requêtes simultanées, en ralentissant les autres tant qu'une n'est pas exécutée. Cependant, dans ClickHouse Proxy, la configuration est bien meilleure. Elle a été conçue spécifiquement pour ClickHouse et pour ces types de requêtes, donc elle est plus adaptée. De plus, son installation est simple.

Comment gérer les opérations asynchrones et les vues matérialisées ?

Il y a un problème, c'est que les opérations avec le moteur de remplacement sont asynchrones : d'abord, les données sont écrites, puis le compactage a lieu. Si une table matérialisée avec des agrégats se trouve sous la table, alors des doublons y seront écrits. Et s'il n'y a pas de logique complexe, les données seront doublonnées. Que peut-on faire à ce sujet ?

Une solution évidente serait de mettre en place un déclencheur pour une certaine classe de vues matérialisées lors de l'opération asynchrone de compactage. Existe-t-il des "solutions miracles" ou des plans pour implémenter de telles fonctionnalités ?

Il convient de comprendre comment fonctionne la dé-duplication. Ce dont je vais parler maintenant n'est pas vraiment lié à la question, mais il est toujours bon de s'en souvenir.

Lors de l'insertion dans une table répliquée, il y a une dé-duplication de l'ensemble des blocs insérés. Si vous insérez à nouveau le même bloc, contenant le même nombre de lignes dans le même ordre, les données seront dédupliquées. Vous recevrez “Ok” en réponse à l'insertion, mais en réalité, une seule série de données sera enregistrée et elle ne sera pas doublée.

Cela est nécessaire pour la certitude. Si lors de l'insertion vous recevez “Ok”, cela signifie que vos données ont été insérées. Si vous recevez une erreur de ClickHouse, cela signifie qu'elles n'ont pas été insérées et que vous devez répéter l'insertion. Mais si la connexion a été interrompue pendant l'insertion, vous ne savez pas si les données ont été insérées ou non. La seule option est de répéter l'insertion. Si les données ont réellement été insérées et que vous les réinsérez, une dé-duplication des blocs se produira. Cela est nécessaire pour éviter les doublons.

Il est également important de comprendre comment cela fonctionne pour les vues matérialisées. Si les données ont été dédupliquées lors de l'insertion dans la table principale, alors elles ne seront également pas envoyées vers la vue matérialisée.

Maintenant, concernant la question. Vous avez une situation plus complexe, car vous enregistrez des duplicats de lignes individuelles. C'est-à-dire que ce n'est pas un ensemble complet qui est dupliqué, mais bien des lignes spécifiques, et elles sont agrégées en arrière-plan. En effet, les données seront agrégées dans la table principale, tandis que les vues matérialisées recevront les données non agrégées, et lors des fusions, rien ne se passera avec les vues matérialisées. Parce qu'une vue matérialisée n'est rien d'autre qu'un déclencheur sur insert. Dans d'autres opérations, rien de supplémentaire ne se produit avec elle.

Et je ne peux pas vraiment vous réjouir ici. Il faut seulement chercher une solution spécifique pour ce cas. Par exemple, peut-on également effectuer un remplacement dans la vue matérialisée, et peut-être que le moyen de dé-duplication fonctionnera ainsi. Mais malheureusement, ce n'est pas toujours le cas. Si elle est agrégative, cela ne fonctionnera pas.

Kirill Shvakov : Nous aussi, nous avions notre part de bricolage autrefois. Il y avait un problème avec l'affichage des publicités, et il y a certaines données que nous pouvons afficher en temps réel — ce ne sont que des affichages. Ils ne se dupliquent que rarement, mais si cela se produit, nous les agrégerons tout de même ensuite. Et il y avait des éléments qui ne doivent pas être dupliqués — les clics et toute cette histoire. Mais nous voulions tout de même les afficher presque immédiatement.

Comment les vues matérialisées ont-elles été faites ? Il y avait des vues où l'on écrit directement — les données brutes sont enregistrées, et les résultats sont écrits dans les vues. À un certain moment, les données ne sont pas très correctes, elles se dupliquent, etc. Et il y a une deuxième partie de la table, où elles apparaissent exactement comme les vues matérialisées, c'est-à-dire qu'elles sont absolument identiques en structure. De temps en temps, nous recalculons les données, comptons les données sans duplications, et les écrivons dans ces tables.

Nous sommes passés par l'API — cela ne fonctionnera pas manuellement dans ClickHouse. Et l'API vérifie : quand j'ai la date du dernier ajout dans la table, où les données sont déjà garanties comme correctes, et elle effectue une requête sur une table et sur une autre. D'une table, elle sélectionne jusqu'à un certain moment, et de l'autre, elle ajoute ce qui n'a pas encore été compté. Et cela fonctionne, mais pas avec les seules méthodes de ClickHouse.

Si vous avez une API — pour les analystes, pour les utilisateurs — c'est en principe une option. Vous effectuez toujours des calculs, vous recalculez toujours. Cela peut se faire une fois par jour ou à un autre moment. Vous choisissez vous-même la plage qui ne vous est pas nécessaire et qui n'est pas critique.

Il y a beaucoup de logs dans ClickHouse. Comment puis-je voir tout ce qui se passe avec le serveur, en temps réel ?

ClickHouse possède un très grand nombre de logs différents, et ce nombre augmente. Dans les nouvelles versions, certains d'entre eux sont même activés par défaut, tandis que dans les anciennes versions, il faut les activer lors de la mise à jour. Néanmoins, ils sont de plus en plus nombreux. J'aimerais voir, en fin de compte, ce qui m'arrive actuellement avec le serveur, peut-être sur un tableau de bord consolidé.

N'avez-vous pas dans votre équipe ClickHouse, ou dans les équipes de vos amis, des gens qui maintiennent une certaine fonctionnalité de tableaux de bord prêts à l'emploi, qui afficheraient ces logs sous forme de produit déjà prêt ? En fin de compte, regarder les logs dans ClickHouse est formidable. Mais ce serait vraiment génial si cela était déjà préparé sous forme de tableau de bord. J'en profiterais beaucoup.

Des tableaux de bord existent, mais ils ne sont pas standardisés. Dans notre entreprise, environ 60 équipes utilisent ClickHouse, et le plus étrange, c'est que beaucoup d'entre elles ont des tableaux de bord qu'elles ont créés elles-mêmes, qui sont légèrement différents. Certaines équipes utilisent une installation interne de « Yandex.Cloud ». Il y a quelques rapports prêts à l'emploi, bien qu'ils ne soient pas tous nécessaires. D'autres en ont de leur côté.

Mes collègues de « Metrics » ont leur propre tableau de bord dans Grafana, et j'ai le mien sur leur cluster. J'y regarde des trucs comme le cache hit pour le cache des enregistrements. Et c'est encore plus compliqué car nous utilisons différents outils. Mon tableau de bord a été créé avec un outil très ancien appelé Graphite-web. Il est totalement inesthétique. Et je l'utilise toujours, même si Grafana serait probablement plus pratique et plus jolie.

Les éléments de base des tableaux de bord sont identiques. Ce sont les métriques système du cluster : CPU, mémoire, disque, réseau. Les autres sont le nombre de requêtes simultanées, le nombre de fusions simultanées, le nombre de requêtes par seconde, le nombre maximum de morceaux pour les partitions des tables MergeTree, le retard de réplication, la taille de la file d'attente de réplication, le nombre de lignes insérées par seconde, le nombre de blocs insérés par seconde. C'est tout ce qui ne provient pas des logs, mais des métriques.

Vladimir Kolobaev: Alexeï, je voudrais faire quelques ajustements. Il y a Grafana. Grafana a une source de données qui est ClickHouse. Donc, je peux faire des requêtes directement dans ClickHouse depuis Grafana. Dans ClickHouse, il y a une table de logs, elle est identique pour tout le monde. Je veux, en fin de compte, interroger cette table de logs dans Grafana et voir les requêtes que mon serveur effectue. Ce serait super d'avoir un tel tableau de bord.

Je l'ai bricolé moi-même. Mais j'ai une question : si tout cela est standardisé, et que Grafana est utilisé par tout le monde, pourquoi n'y a-t-il pas de tableau de bord officiel chez « Yandex » ?

Kirill Shvakov : En réalité, la source de données qui se connecte à ClickHouse est actuellement soutenue par Altinity. Je veux juste pointer dans une direction sur laquelle se pencher et vers qui pousser. On peut leur demander, car « Yandex » développe quand même ClickHouse, et non pas l'histoire qui l'entoure. Altinity est la principale entreprise qui promeut actuellement ClickHouse. Ils ne vont pas l'abandonner, ils vont le soutenir. Parce que, en principe, pour télécharger un tableau de bord sur le site de Grafana, il suffit de s'inscrire et de le télécharger, il n'y a pas de problème particulier.

Alexey Milovidov: Au cours de l'année dernière, ClickHouse a ajouté de nombreuses fonctionnalités pour le profilage des requêtes. Il y a des métriques pour chaque requête concernant l'utilisation des ressources. Et récemment, un profileur de requêtes encore plus bas niveau a été ajouté, pour voir où chaque requête passe chaque milliseconde. Mais pour profiter de cette fonctionnalité, je dois ouvrir le client en ligne de commande et taper la requête que j'oublie constamment. Je l'ai sauvegardée quelque part et j'oublie toujours où exactement.

J'aimerais qu'il y ait un outil qui affiche simplement - voici vos requêtes lourdes, groupées par catégories de requêtes. Je clique sur l'une d'elles et on me dit pourquoi elle est lourde. Actuellement, il n'existe pas de telle solution. Et c'est vraiment assez étrange que, lorsque les gens me demandent : « Dites, existe-t-il des tableaux de bord prêts à l'emploi pour Grafana ? », je réponds : « Allez sur le site de Grafana, il y a la communauté 'Tableaux de bord', et il y a 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é moi-même. »

Comment agir sur les fusions pour que le serveur ne tombe pas en OOM ?

J'ai un tableau avec une seule partition, c'est un ReplacingMergeTree. J'y écris des données depuis quatre ans. J'avais besoin de faire un alter et de supprimer certaines données.

Je l'ai fait, et pendant le traitement de cette requête, toute la mémoire sur tous les serveurs du cluster a été consommée, et tous les serveurs du cluster sont tombés ensemble en OOM. Ensuite, ils se sont tous relevés, ont commencé à effectuer la fusion de cette même opération, de ce bloc de données, et sont à nouveau tombés en OOM. Puis ils se sont relevés à nouveau et sont retombés. Et cette situation ne s'est pas arrêtée.

Il s'est avéré que c'était en fait un bug que les gars ont corrigé. C'est super, merci beaucoup. Mais il reste un goût amer. Et maintenant, quand je pense à faire une fusion dans le tableau, je me demande – pourquoi ne puis-je pas influencer d'une certaine manière ces fusions ? Par exemple, limiter leur consommation de mémoire nécessaire, ou même leur nombre, qui va traiter spécifiquement ce tableau.

J'ai un tableau qui s'appelle 'Métriques', traite-le s'il te plaît avec deux threads. Pas besoin de créer dix ou cinq fusions en parallèle, fais-le en deux. Je pense qu'avec deux j'aurai assez de mémoire, mais pour en traiter dix, je pourrais ne pas en avoir suffisamment. Pourquoi cette peur persiste-t-elle ? Parce que le tableau grandit, et un jour je vais me retrouver dans une situation où, non pas à cause d'un bug, mais parce que les données vont changer en si grand nombre que je n'aurai tout simplement pas assez de mémoire sur le serveur. Et alors le serveur tombera en OOM lors de la fusion. De plus, je peux annuler la mutation, mais les fusions, elles, ne peuvent pas être annulées.

Vous savez, lors des fusions, le serveur ne tombera pas en OOM, car lors de la fusion, il n'utilise la mémoire qu'à partir d'une petite plage de données. Donc tout ira bien, peu importe la quantité de données.

Vladimir Kolobaev: D'accord. Il y a un point ici, après avoir corrigé le bug, j'ai téléchargé la nouvelle version, et sur une autre table, plus petite, où il y a beaucoup de partitions, j'ai effectué une opération similaire. Et pendant la fusion, environ 100 Go de mémoire vive ont été utilisés. J'avais 150 Go de mémoire occupée, 100 Go ont été consommés, et il me reste une marge de 50 Go, donc je ne suis pas tombé en OOM.

Qu'est-ce qui me protège en ce moment d'un OOM, si cela nécessite vraiment 100 Go de mémoire vive ? Que faire si, par hasard, la mémoire vive vient à manquer lors des fusions ?

Alexey Milovidov: Il y a un problème, c'est que la consommation de mémoire vive lors des fusions n'est pas limitée. Et le deuxième problème est que si une fusion est programmée, elle doit être exécutée, car elle est enregistrée dans le journal de réplication. Le journal de réplication contient les actions nécessaires pour amener la réplique dans un état cohérent. Si nous ne faisons pas les manipulations manuelles qui annuleront ce journal de réplication, la fusion devra être exécutée, que cela nous plaise ou non.

Bien sûr, ce ne serait pas superflu d'avoir une limite de mémoire vive qui protège, 'au cas où', contre l'OOM. Cela n'aidera pas la fusion à s'exécuter, elle recommencera, atteindra un certain seuil, lancera une exception, et recommencera – rien de bon ne sortira de tout cela. Mais en principe, il serait utile d'introduire cette limitation.

Comment va se dérouler le développement du pilote Golang pour ClickHouse ?

Le pilote Golang, écrit par Kirill Shvakov, est maintenant officiellement soutenu par l'équipe ClickHouse. Il dans le dépôt ClickHouse, il est maintenant grand et authentique.

Une petite remarque. Il existe un entrepôt de formes infinies, merveilleux et très apprécié de tous, qui est Vertica. Ils ont aussi leur propre pilote Python, soutenu par les développeurs de Vertica. Il y a eu plusieurs fois où les versions de l'entrepôt et du pilote étaient très différentes, et à un moment donné, le pilote cessait de fonctionner. Un deuxième point à mentionner. Il me semble que le support de ce pilote officiel est géré via un système de type « nippel » — vous leur écrivez un problème et il reste suspendu indéfiniment.

J'ai deux questions. Actuellement, le pilote Golang de Kirill est presque la méthode par défaut pour communiquer avec ClickHouse depuis Golang. À part quelques personnes qui utilisent encore l’interface HTTP, parce qu’elle leur plaît. Comment le développement de ce pilote se déroulera-t-il ? Sera-t-il synchronisé avec des modifications majeures dans l'entrepôt lui-même ? Et quelle est la procédure de traitement des problèmes ?

Kirill Shvakov : Premièrement, comment tout cela est organisé sur le plan bureaucratique. Cet aspect n’a pas été discuté, donc je n’ai rien à répondre.

Pour répondre à la question concernant les problèmes, il est nécessaire de raconter l'histoire du pilote. J'ai travaillé dans une entreprise où il y avait beaucoup de données. C'était un moteur publicitaire avec un énorme nombre d'événements à stocker quelque part. À un moment donné, ClickHouse est apparu. Nous y avons versé des données, et au début, tout allait bien, mais ensuite ClickHouse est tombé. À ce moment-là, nous avons décidé que cela ne nous convenait pas.

Un an plus tard, nous sommes revenus à l'idée d'utiliser ClickHouse, et nous devions trouver un moyen d’écrire des données. L'introduction était la suivante : le matériel était très faible, les ressources étaient limitées. Mais nous avons toujours travaillé de cette manière, donc nous avons cherché du côté du protocole natif.

Puisque nous travaillions avec Go, il était clair qu'un pilote pour Go était nécessaire. J'y ai travaillé presque à plein temps - c'était ma tâche professionnelle. Jusqu'à un certain point, nous l'avons développé, et en principe, personne ne s'attendait à ce que quelqu'un d'autre l’utilise. Ensuite, CloudFlare est venu avec exactement le même problème, et pendant un certain temps, nous avons travaillé très étroitement avec eux, car ils avaient les mêmes exigences. Nous avons fait cela à la fois dans ClickHouse lui-même et dans le pilote.

À un moment donné, j'ai simplement cessé de m'en occuper, car mon activité concernant ClickHouse et mon travail ont un peu changé. C'est pourquoi les incidents ne sont pas résolus. Périodiquement, des gens comittent dans le dépôt quand ils ont besoin de quelque chose. À ce moment-là, je regarde les pull requests et parfois je corrige même quelque chose moi-même, mais cela arrive rarement.

J'aimerais revenir au driver. Il y a plusieurs années, quand tout cela a commencé, ClickHouse était différent et avait d'autres fonctionnalités. Maintenant, nous savons comment revoir le driver pour que ce soit bien. Si cela se réalise, la version 2 sera de toute façon incompatible à cause des divers hacks accumulés.

Je ne sais pas comment organiser cela. Je n'ai pas beaucoup de temps moi-même. Si certaines personnes veulent peaufiner le driver, je pourrai les aider et leur expliquer quoi faire. Mais la participation active de Yandex dans le développement du projet n'a pas encore été discutée.

Alexey Milovidov: En réalité, il n'y a pas encore de bureaucratie concernant ces drivers. La seule chose est qu'ils ont été intégrés dans une organisation officielle, c'est-à-dire que ce driver est reconnu comme une solution officielle par défaut pour Go. Il existe d'autres drivers, mais ils sont séparés.

Nous n'avons pas de développement interne pour ces drivers. La question est de savoir si nous pourrons embaucher une personne, pas spécifiquement pour ce driver, mais pour le développement de tous les drivers communautaires, ou si nous pourrons trouver quelqu'un à l'extérieur.

Le dictionnaire externe ne se charge pas après le redémarrage avec l'option lazy_load activée. Que faire?

Nous avons l'option lazy_load activée, et après le redémarrage du serveur, le dictionnaire ne se charge pas automatiquement. Il ne se charge qu'après qu'un utilisateur y ait accédé. Et à la première sollicitation, il renvoie une erreur. Y a-t-il un moyen d'automatiser le chargement des dictionnaires avec ClickHouse, ou devons-nous toujours contrôler leur disponibilité pour éviter que les utilisateurs ne rencontrent des erreurs?

Il se peut que nous ayons une ancienne version de ClickHouse, c'est pourquoi le dictionnaire ne s'est pas chargé automatiquement. Est-ce possible?

Tout d'abord, les dictionnaires peuvent être chargés de force à l'aide de la requête system reload dictionaries. Deuxièmement, concernant l'erreur — si le dictionnaire est déjà chargé, les requêtes fonctionneront sur les données qui ont été chargées. S'il n'a pas encore été chargé, il se chargera pendant la requête.

Pour les dictionnaires lourds, ce n'est pas très pratique. Par exemple, il faut récupérer un million de lignes depuis MySQL. Certains font une simple sélection, mais cette sélection attend justement ce million de lignes. Il y a deux solutions. La première est de désactiver lazy_load. La seconde est que lorsque le serveur se lève, avant de lui appliquer la charge, faites system reload dictionary ou simplement exécutez une requête qui utilise le dictionnaire. Dans ce cas, le dictionnaire sera chargé. Vous devez contrôler vous-même la disponibilité des dictionnaires avec le paramètre lazy_load activé, car ClickHouse ne les recharge pas automatiquement.

Pour la dernière question, la réponse est soit que la version est ancienne, soit qu'il faut déboguer.

Comment gérer le fait que system reload dictionaries ne charge aucun des nombreux dictionnaires si au moins l'un d'eux échoue avec une erreur ?

Il y a aussi une question concernant system reload dictionaries. Nous avons deux dictionnaires : l'un ne se charge pas, l'autre se charge. Dans ce cas, system reload dictionaries ne recharge aucun dictionnaire, et il faut le recharger spécifiquement par son nom à l'aide de system reload dictionary. Est-ce également lié à la version de ClickHouse ?

Je suis heureux de l'annoncer. Ce comportement a changé. Cela signifie que si vous mettez à jour ClickHouse, cela changera aussi. Si le comportement actuel ne vous satisfait pas system reload dictionaries, mettez à jour, et espérons que cela s'améliorera.

Y a-t-il un moyen de configurer les identifiants dans la configuration de ClickHouse, mais sans les exposer en cas d'erreurs ?

La question suivante concerne les erreurs liées au dictionnaire, à savoir les identifiants de connexion. Nous avons inscrit les identifiants de connexion dans la configuration de ClickHouse pour le dictionnaire, et en cas d'erreur, nous recevons ces identifiants ainsi que le mot de passe en retour.

Nous avons résolu cette erreur en extrayant les identifiants dans la configuration du pilote ODBC. Existe-t-il un moyen de configurer les identifiants dans la configuration de ClickHouse sans les exposer lors des erreurs ?

La solution ici est effectivement d'indiquer ces credentials dans le fichier odbc.ini, et dans ClickHouse, d'indiquer uniquement le nom de la source de données ODBC. Pour les autres sources de dictionnaires, cela ne sera pas le cas — ni pour le dictionnaire avec MySQL, ni pour les autres vous ne devriez pas voir le mot de passe lors d'un message d'erreur. Pour l'ODBC, je vais aussi vérifier — s'il y a un tel cas, il suffit de l'enlever.

Bonus : fonds pour Zoom à partir de soirées

En cliquant sur l'image, pour les lecteurs les plus persistants, des fonds bonus à thème de réunions s'ouvriront. Éteignons le feu avec les mascottes des technologies Avito, tenons des réunions avec des collègues dans la salle des administrateurs système ou un vieux club d'informatique, et faisons des réunions sous le pont sur fond de graffiti.

Source : habr.com