En avril, les ingénieurs d'Avito se sont réunis pour des réunions en ligne avec le développeur principal de ClickHouse, Alexey Milovidov, et Kirill Shvakov, un développeur Golang d'Integros. Nous avons discuté de la manière dont nous utilisons un système de gestion de base de données et des difficultés que nous rencontrons.
Sur la base de la réunion, nous avons compilé un article avec les réponses d'experts à nos questions et à celles du public sur les sauvegardes, le repartage des données, les dictionnaires externes, le pilote Golang et la mise à jour des versions de ClickHouse. Cela peut être utile aux développeurs qui travaillent déjà activement avec le SGBD Yandex et qui s'intéressent à son présent et à son avenir. Par défaut, les réponses sont d'Alexeï Milovidov, sauf indication contraire.
Attention, il y a beaucoup de texte sous la coupe. Nous espérons que le contenu avec les questions vous aidera à naviguer.
Teneur
Si vous ne souhaitez pas lire le texte, vous pouvez regarder l'enregistrement des rassemblements . Les timecodes sont dans le premier commentaire sous la vidéo.
ClickHouse est constamment mis à jour, mais pas nos données. Que faire à ce sujet ?
ClickHouse est constamment mis à jour et nos données, qui ont été optimisées lors du traitement final, ne sont pas mises à jour et se trouvent dans une copie de sauvegarde.
Disons que nous avons eu un problème et que les données ont été perdues. Nous avons décidé de restaurer et il s'est avéré que les anciennes partitions stockées sur les serveurs de sauvegarde sont très différentes de la version actuellement utilisée de ClickHouse. Que faire dans une telle situation, et est-ce possible ?
Une situation dans laquelle vous avez restauré des données à partir d'une sauvegarde dans un ancien format, mais qui ne se connectent pas à la nouvelle version, est impossible. Nous veillons à ce que le format des données dans ClickHouse reste toujours rétrocompatible. Ceci est beaucoup plus important que la rétrocompatibilité des fonctionnalités si le comportement d'une fonction rarement utilisée a changé. La nouvelle version de ClickHouse devrait toujours être capable de lire les données stockées sur le disque. C'est la loi.
Quelles sont les meilleures pratiques actuelles pour sauvegarder les données de ClickHouse ?
Comment faire des sauvegardes, en tenant compte du fait que nous avons optimisé les opérations finales, une énorme base de données de téraoctets et des données qui sont mises à jour, disons, au cours des trois derniers jours, et qu'ensuite aucune procédure ne se produit ?
Nous pouvons créer notre propre solution et écrire sur bash : collecter ces copies de sauvegarde de telle ou telle manière. Peut-être qu'il n'est pas nécessaire d'avoir quoi que ce soit avec des béquilles et que le vélo a été inventé il y a longtemps ?
Commençons par les meilleures pratiques. Mes collègues conseillent toujours, en réponse aux questions sur les sauvegardes, de leur rappeler le service Yandex.Cloud, où ce problème a déjà été résolu. Alors utilisez-le si possible.
Il n'existe pas de solution complète pour les sauvegardes, intégrée à cent pour cent à ClickHouse. Certains blancs peuvent être utilisés. Pour obtenir une solution complète, vous devrez soit bricoler un peu 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, en fonction du volume de données et de la taille du cluster. Plus le cluster est grand, plus la solution devient complexe.
Si la table contenant les données n'occupe que quelques gigaoctets, la sauvegarde peut être effectuée comme ceci :
- Enregistrer la définition de la table, c'est-à-dire les métadonnées - afficher créer un tableau.
- Faire un dump à l'aide du client ClickHouse - Sélectionner * de la table déposer. Par défaut, vous recevrez un fichier au format TabSeparated. Si vous souhaitez être plus efficace, vous pouvez le faire au format Natif.
Si la quantité de données est plus importante, la sauvegarde prendra plus de temps et beaucoup d'espace. C'est ce qu'on appelle une sauvegarde logique ; elle n'est pas liée au format de données ClickHouse. Si tel est le cas, en dernier recours, vous pouvez effectuer une sauvegarde et la télécharger sur MySQL pour la récupération.
Pour les cas plus avancés, ClickHouse dispose d'une capacité intégrée pour créer un instantané des partitions dans le système de fichiers local. Cette fonctionnalité est disponible sur demande modifier la partition de gel de la table. Ou simplement modifier le gel de la table - ceci est un instantané de la table entière.
L'instantané sera créé de manière cohérente pour une table sur une seule partition, c'est-à-dire qu'il est impossible de créer un instantané cohérent de l'ensemble du cluster de cette manière. Mais pour la plupart des tâches, ce besoin n'est pas nécessaire, et il suffit d'exécuter une requête sur chaque fragment et d'obtenir un instantané cohérent. Il est créé sous forme de liens physiques et ne prend donc pas de place supplémentaire. Ensuite, vous copiez cet instantané sur le serveur de sauvegarde ou sur le stockage que vous utilisez pour les sauvegardes.
Restaurer une telle sauvegarde est assez simple. Commencez par créer des tables à l’aide des définitions de table existantes. Ensuite, copiez les instantanés enregistrés des partitions dans Directory-Detached pour ces tables et exécutez la requête attacher une partition. Cette solution est tout à fait adaptée aux volumes de données les plus importants.
Parfois, vous avez besoin de quelque chose d'encore plus cool - dans les cas où vous avez des dizaines, voire des centaines de téraoctets sur chaque serveur et des centaines de serveurs. Il existe ici une solution que j'ai récupérée auprès de mes collègues de Yandex.Metrica. Je ne le recommanderais pas à tout le monde - lisez-le et décidez vous-même s'il convient ou non.
Vous devez d’abord créer plusieurs serveurs avec de grandes étagères de disques. Ensuite, sur ces serveurs, créez plusieurs serveurs ClickHouse et configurez-les pour qu'ils fonctionnent comme une autre réplique pour les mêmes fragments. Et puis utilisez un système de fichiers ou un outil sur ces serveurs qui vous permet de créer des instantanés. Il y a deux options ici. La première option concerne les instantanés LVM, la deuxième option est ZFS sous Linux.
Après cela, chaque jour, vous devez créer un instantané, il mentira et prendra de la place. Naturellement, si les données changent, la quantité d’espace augmentera avec le temps. Cet instantané peut être supprimé à tout moment et les données restaurées, une solution tellement étrange. De plus, nous devons également limiter ces répliques dans la configuration afin qu'elles n'essaient pas de devenir des leaders.
Sera-t-il possible d'organiser un décalage contrôlé des répliques dans les puits ?
Cette année, vous envisagez de fabriquer des puits dans ClickHouse. Sera-t-il possible d'y organiser un décalage contrôlé des répliques ? Nous aimerions l'utiliser pour nous protéger des scénarios négatifs avec des altérations et autres changements.
Est-il possible d'effectuer une sorte de restauration des modifications ? Par exemple, dans un puits existant, prenez et dites que jusqu'à ce moment vous appliquez les modifications, et à partir de ce moment vous arrêtez d'appliquer les modifications ?
Si une commande arrive sur notre cluster et le casse, alors nous avons une réplique conditionnelle avec un décalage d'une heure, où nous pouvons dire que nous l'utilisons pour le moment, mais nous n'y appliquerons pas de modifications au cours des dix dernières minutes ?
Tout d’abord, à propos du décalage contrôlé des répliques. Il y a eu une telle demande de la part des utilisateurs, et nous avons créé un problème sur Github avec la demande : « Si quelqu'un a besoin de ça, aimez-le, mettez un cœur. » Personne n'a livré et le problème a été clos. Cependant, vous pouvez déjà bénéficier de cette opportunité en créant ClickHouse. C'est vrai, seulement à partir de la version 20.3.
ClickHouse effectue constamment une fusion de données en arrière-plan. Lorsqu'une fusion est terminée, un certain ensemble de données est remplacé par un élément plus volumineux. Dans le même temps, les éléments de données qui existaient auparavant continuent de rester sur le disque pendant un certain temps.
Premièrement, ils continuent à être stockés tant que des requêtes de sélection les utilisent, afin de fournir un fonctionnement non bloquant. Les requêtes sélectionnées sont facilement lues à partir d’anciens morceaux.
Deuxièmement, il existe également un seuil de temps : les anciennes données restent sur le disque pendant huit minutes. Ces huit minutes peuvent être personnalisées et même transformées en une seule journée. Cela coûtera de l'espace disque : en fonction du flux de données, il s'avère qu'au cours du dernier jour, les données non seulement doubleront, mais pourraient devenir cinq fois plus importantes. Mais s'il y a un problème grave, vous pouvez arrêter le serveur ClickHouse et tout régler.
La question se pose maintenant de savoir comment cela protège contre les altérations. Cela vaut la peine d'examiner de plus près ici, car dans les anciennes versions de ClickHouse, la modification fonctionnait de telle manière qu'elle modifiait simplement les pièces directement. Il existe une donnée avec certains fichiers, et nous faisons, par exemple, modifier la colonne de dépôt. Ensuite, cette colonne est physiquement supprimée de tous les morceaux.
Mais à partir de la version 20.3, le mécanisme de modification a été complètement modifié et désormais les éléments de données sont toujours immuables. Ils ne changent pas du tout – les modifications fonctionnent désormais de la même manière que les fusions. Au lieu de remplacer une pièce sur place, on en crée une nouvelle. Dans le nouveau morceau, les fichiers qui n'ont pas changé deviennent des liens physiques, et si nous supprimons une colonne, elle manquera simplement dans le nouveau morceau. L'ancienne pièce sera supprimée par défaut après huit minutes, et vous pourrez ici modifier les paramètres mentionnés ci-dessus.
La même chose s'applique aux modifications telles que les mutations. Quand tu fais modifier supprimer ou modifier la mise à jour, cela ne change pas la pièce, mais en crée une nouvelle. Et puis supprime l'ancien.
Et si la structure du tableau avait changé ?
Comment restaurer une sauvegarde effectuée avec l'ancien schéma ? Et la deuxième question concerne le cas des instantanés et des outils de système de fichiers. Btrfs est-il bon ici au lieu de ZFS sur Linux LVM ?
Si tu fais attacher une partition partitions avec une structure différente, alors ClickHouse vous dira que ce n'est pas possible. C'est la solution. La première consiste à créer une table temporaire de type MergeTree avec l'ancienne structure, à y attacher des données à l'aide de attach et à effectuer une requête de modification. Ensuite, vous pouvez soit copier ou transférer ces données et les joindre à nouveau, soit utiliser une demande modifier la table déplacer la partition.
Maintenant, la deuxième question est de savoir si les Btrfs peuvent être utilisés. Pour commencer, si vous disposez de LVM, les instantanés LVM suffisent et le système de fichiers peut être ext4, cela n'a pas d'importance. Avec Btrts, tout dépend de votre expérience d'utilisation. Il s'agit d'un système de fichiers mature, mais des soupçons subsistent quant à la manière dont tout se déroulera dans la pratique dans un scénario particulier. Je ne recommanderais pas de l'utiliser à moins que vous n'ayez Btrfs en production.
Quelles sont les meilleures pratiques actuelles en matière de repartitionnement des données ?
La question du reharding est complexe et multiforme. Il y a plusieurs réponses possibles ici. Vous pouvez passer d'un côté et dire ceci : ClickHouse n'a pas de fonctionnalité de repartitionnement intégrée. Mais je crains que cette réponse ne convienne à personne. Par conséquent, vous pouvez passer de l’autre côté et dire que ClickHouse propose de nombreuses façons de repartir les données.
Si le cluster manque d'espace ou s'il ne peut pas gérer la charge, vous ajoutez de nouveaux serveurs. Mais ces serveurs sont vides par défaut, il n'y a aucune donnée dessus, il n'y a pas de charge. Vous devez réorganiser les données afin qu'elles soient réparties uniformément sur le nouveau cluster plus grand.
La première façon de procéder consiste à copier une partie des partitions sur de nouveaux serveurs à l'aide d'une requête. modifier la partition de récupération de table. Par exemple, vous aviez des partitions par mois, et vous prenez le premier mois de 2017 et le copiez sur un nouveau serveur, puis copiez le troisième mois sur un autre nouveau serveur. Et vous faites cela jusqu'à ce que cela devienne plus ou moins uniforme.
Le transfert ne peut être effectué que pour les partitions qui ne changent pas pendant l'enregistrement. Pour les nouvelles partitions, l'enregistrement devra être désactivé, car leur transfert n'est pas atomique. Sinon, vous vous retrouverez avec des doublons ou des lacunes dans les données. Cependant, cette méthode est pratique et fonctionne assez efficacement. Les partitions compressées prêtes à l'emploi sont transmises sur le réseau, c'est-à-dire que les données ne sont ni compressées ni réencodées.
Cette méthode présente un inconvénient, et cela dépend du schéma de partitionnement, si vous vous êtes engagé à suivre ce schéma de partitionnement, quelle clé de partitionnement vous aviez. Dans votre exemple pour le cas des métriques, la clé de partitionnement est le hachage du chemin. Lorsque vous sélectionnez une table distribuée, elle accède à toutes les partitions du cluster en même temps et en extrait les données.
Cela signifie que peu importe quelles données ont abouti sur quel fragment. L'essentiel est que les données empruntant un chemin se retrouvent sur un seul fragment, mais lequel n'a pas d'importance. Dans ce cas, le transfert de partitions prêtes à l'emploi est parfait, car avec les requêtes sélectionnées, vous recevrez également des données complètes - que ce soit avant ou après le repartitionnement, le schéma n'a pas vraiment d'importance.
Mais il existe des cas plus complexes. Si au niveau de la logique applicative vous comptez sur un schéma de partitionnement particulier, que ce client se trouve sur tel ou tel fragment, et que la requête peut y être envoyée directement, et non à la table Distribuée. Soit vous utilisez une version assez récente de ClickHouse et avez activé le paramètre optimiser ignorer les fragments inutilisés. Dans ce cas, lors de la requête de sélection, l'expression dans la section Where sera analysée et il sera calculé quelles partitions doivent être utilisées selon le schéma de partitionnement. Cela fonctionne à condition que les données soient partitionnées exactement selon ce schéma de partitionnement. Si vous les avez réorganisés manuellement, la correspondance peut changer.
C'est donc la méthode numéro un. Et j'attends votre réponse, si la méthode est adaptée, ou passons à autre chose.
Vladimir Kolobaev, administrateur système principal chez Avito: Alexey, la méthode que vous avez mentionnée ne fonctionne pas très bien lorsqu'il faut répartir la charge, y compris la lecture. Nous pouvons prendre une partition mensuelle et transférer le mois précédent vers un autre nœud, mais lorsqu'une demande arrive pour ces données, nous la chargerons uniquement. Mais nous aimerions charger l'intégralité du cluster, car sinon, pendant un certain temps, la totalité de la charge de lecture sera traitée par deux fragments.
Alexeï Milovidov : La réponse ici est étrange : oui, c’est mauvais, mais cela pourrait fonctionner. Je vais vous expliquer exactement comment. Cela vaut la peine d'examiner le scénario de charge qui se cache derrière vos données. S’il s’agit de données de surveillance, nous pouvons presque certainement affirmer que la grande majorité des demandes concernent des données récentes.
Vous avez installé de nouveaux serveurs, migré d'anciennes partitions, mais également modifié la façon dont les nouvelles données sont enregistrées. Et de nouvelles données seront réparties dans tout le cluster. Ainsi, après seulement cinq minutes, les requêtes des cinq dernières minutes chargeront le cluster de manière uniforme ; après une journée, les requêtes de XNUMX heures chargeront le cluster de manière uniforme. Et les demandes du mois précédent ne iront malheureusement qu'à une partie des serveurs du cluster.
Mais souvent vous n’aurez pas de demandes spécifiquement pour février 2019. Très probablement, si les demandes portent sur 2019, elles concerneront toute l'année 2019 - sur une longue période de temps, et non sur une petite plage. Et de telles requêtes pourront également charger le cluster de manière uniforme. Mais en général, votre remarque est tout à fait correcte : il s'agit d'une solution ad hoc qui ne répartit pas les données de manière totalement uniforme.
J'ai encore quelques points pour répondre à la question. L’un d’eux concerne la manière de concevoir initialement un schéma de partitionnement afin que le re-partitionnement soit moins pénible. Ce n'est pas toujours possible.
Par exemple, vous disposez de données de surveillance. Les données de surveillance augmentent pour trois raisons. Le premier est l’accumulation de données historiques. Le deuxième est la croissance du trafic. Et le troisième est l’augmentation du nombre de choses soumises à surveillance. De nouveaux microservices et métriques doivent être sauvegardés.
Il est possible que parmi ceux-ci, la plus forte augmentation soit associée à la troisième raison : l’augmentation du recours à la surveillance. Et dans ce cas, cela vaut la peine d'examiner la nature de la charge, quelles sont les principales requêtes de sélection. Les requêtes de sélection de base seront très probablement basées sur un sous-ensemble de métriques.
Par exemple, l'utilisation du processeur sur certains serveurs par un service. Il s'avère qu'il existe un certain sous-ensemble de clés grâce auxquelles vous obtenez ces données. Et la demande elle-même de ces données est probablement assez simple et s'effectue en quelques dizaines de millisecondes. Utilisé pour surveiller les services et les tableaux de bord. J'espère avoir bien compris.
Vladimir Kolobaev : Le fait est que nous faisons très souvent appel à des données historiques, puisque nous comparons en temps réel la situation actuelle avec la situation historique. Et il est important pour nous d’avoir un accès rapide à une grande quantité de données, et ClickHouse fait un excellent travail dans ce domaine.
Vous avez tout à fait raison, nous recevons la plupart des demandes de lecture au cours du dernier jour, comme tout système de surveillance. Mais en même temps, la charge sur les données historiques est également assez importante. Il s'agit essentiellement d'un système d'alerte qui circule toutes les trente secondes et dit à ClickHouse : « Donnez-moi les données des six dernières semaines. Maintenant, construisez-moi une sorte de moyenne mobile à partir d’eux, et comparons la valeur actuelle avec la valeur historique.
Je voudrais dire que pour des requêtes aussi récentes, nous avons une autre petite table dans laquelle nous stockons seulement deux jours de données, et les requêtes principales y atterrissent. Nous envoyons uniquement les requêtes historiques volumineuses à la grande table partitionnée.
Alexeï Milovidov : Malheureusement, cela s'avère peu applicable à votre scénario, mais je vais vous décrire deux schémas de partitionnement mauvais et complexes qui n'ont pas besoin d'être utilisés, mais qui sont utilisés dans le service de mes amis.
Il existe un cluster principal avec les événements Yandex.Metrica. Les événements sont des pages vues, des clics et des conversions. La plupart des demandes sont dirigées vers un site Web spécifique. Vous ouvrez le service Yandex.Metrica, vous avez un site Web - avito.ru, accédez au rapport et une demande est faite pour votre site Web.
Mais il existe d’autres demandes – analytiques et globales – qui émanent des analystes internes. Juste au cas où, je note que les analystes internes font des demandes uniquement pour les services Yandex. Néanmoins, même les services Yandex occupent une part importante de toutes les données. Il ne s’agit pas de demandes de compteurs spécifiques, mais d’un filtrage plus large.
Comment organiser les données de manière à ce que tout fonctionne efficacement pour un seul compteur, ainsi que pour les requêtes globales ? Une autre difficulté est que le nombre de requêtes dans ClickHouse pour le cluster Metrics est de plusieurs milliers par seconde. Dans le même temps, un serveur ClickHouse ne peut pas gérer des requêtes non triviales, par exemple plusieurs milliers par seconde.
La taille du cluster est de six cents serveurs. Si vous extrayez simplement une table distribuée sur ce cluster et y envoyez plusieurs milliers de requêtes, cela deviendra encore pire que de les envoyer à un seul serveur. En revanche, l'option selon laquelle les données seraient réparties uniformément et que nous allions demander à tous les serveurs est immédiatement écartée.
Il existe une option diamétralement opposée. Imaginez si nous partageons les données sur plusieurs sites et qu'une demande pour un site est dirigée vers une seule partition. Désormais, le cluster sera capable de gérer dix mille requêtes par seconde, mais sur un seul fragment, toute requête fonctionnera trop lentement. Il ne sera plus évolutif en termes de débit. Surtout s'il s'agit du site avito.ru. Je ne révélerai pas le secret si je dis qu'Avito est l'un des sites les plus visités de RuNet. Et le traiter sur un seul fragment serait une folie.
Par conséquent, le schéma de partitionnement est conçu de manière plus astucieuse. L'ensemble du cluster est divisé en un certain nombre de clusters, que nous appelons couches. Chaque cluster contient d'une douzaine à plusieurs dizaines de fragments. Il existe au total trente-neuf clusters de ce type.
Comment tout cela évolue-t-il ? Le nombre de clusters ne change pas : comme il était de trente-neuf il y a quelques années, il le reste. Mais au sein de chacun d’eux, nous augmentons progressivement le nombre de fragments à mesure que nous accumulons des données. Et le schéma de partitionnement dans son ensemble est le suivant : ces clusters sont divisés en sites Web, et afin de comprendre quel site Web se trouve sur quel cluster, une métabase distincte dans MySQL est utilisée. Un site - sur un cluster. Et à l’intérieur, le partitionnement se produit en fonction des identifiants des visiteurs.
Lors de l'enregistrement, nous les divisons par le reste de la division de l'identifiant du visiteur. Mais lors de l'ajout d'un nouveau fragment, le schéma de partitionnement change : nous continuons à diviser, mais avec un reste de division par un autre nombre. Cela signifie qu'un visiteur se trouve déjà sur plusieurs serveurs et vous ne pouvez pas vous y fier. Ceci est fait uniquement pour garantir que les données sont mieux compressées. Et lors des requêtes, nous accédons à la table Distribuée, qui examine le cluster et accède à des dizaines de serveurs. C'est un plan tellement stupide.
Mais mon histoire serait incomplète si je ne disais pas que nous avons abandonné ce projet. Dans le nouveau schéma, nous avons tout changé et copié toutes les donné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 le résultat est que les grands sites sont enregistrés sur un seul cluster, où se trouvent 120 fragments avec trois répliques chacun, soit 360 serveurs. Et le schéma de partitionnement est tel que toute demande est adressée à toutes les partitions à la fois. Si vous ouvrez maintenant une page de rapport pour avito.ru dans Yandex.Metrica, la demande sera envoyée à 120 serveurs. Il existe peu de grands sites sur RuNet. Et les requêtes ne sont pas de mille par seconde, mais même de moins d'une centaine. Tout cela est tranquillement mâché par la table Distribuée, que chacun d'eux traite avec 120 serveurs.
Et le deuxième cluster concerne les petits sites. Voici un schéma de partitionnement basé sur l'ID du site, et chaque demande est adressée à exactement une partition.
ClickHouse dispose d'un utilitaire de copie Clickhouse. Pouvez-vous nous parler d'elle ?
Je dirai tout de suite que cette solution est plus lourde et un peu moins productive. L'avantage est qu'il étale complètement les données selon le modèle que vous spécifiez. Mais l'inconvénient de l'utilitaire est qu'il ne redémarre pas du tout. Il copie les données d'un schéma de cluster vers un autre schéma de cluster.
Cela signifie que pour que cela fonctionne, vous devez disposer de deux clusters. Ils peuvent être situés sur les mêmes serveurs, mais néanmoins les données ne seront pas déplacées progressivement, 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 lancez Clickhouse-copier, en y indiquant le schéma de travail qu'il doit lire à partir de là, acceptez le nouveau schéma de partitionnement et transférez-y les données. Et sur les anciens serveurs, vous aurez besoin d'une fois et demie plus d'espace qu'aujourd'hui, car les anciennes données doivent y rester, et la moitié des mêmes anciennes données arriveront par-dessus. Si vous pensiez à l'avance que les données devaient être reparties et qu'il y avait de l'espace, cette méthode convient.
Comment fonctionne le copieur Clickhouse à l'intérieur ? Il divise tout le travail en un ensemble de tâches pour traiter une partition d'une table sur un fragment. Toutes ces tâches peuvent être exécutées en parallèle et clickhouse-copier peut être exécuté sur différentes machines dans plusieurs instances, mais ce qu'il fait pour une partition n'est rien de plus qu'une sélection d'insertion. Les données sont lues, décompressées, repartitionnées, puis à nouveau compressées, écrites quelque part et triées à nouveau. C'est une décision plus difficile.
Vous aviez un projet pilote appelé reharding. Et avec elle ?
En 2017, vous aviez un projet pilote appelé reharding. Il existe même une option dans ClickHouse. Si je comprends bien, cela n'a pas décollé. Pouvez-vous me dire pourquoi cela s'est produit ? Cela semble très pertinent.
Tout le problème est que s’il est nécessaire de repartir les données sur place, une synchronisation très complexe est nécessaire pour le faire de manière atomique. Lorsque nous avons commencé à examiner le fonctionnement de cette synchronisation, il est devenu évident qu’il existait des problèmes fondamentaux. Et ces problèmes fondamentaux ne sont pas seulement théoriques, mais ont immédiatement commencé à se manifester dans la pratique sous la forme de quelque chose qui peut être expliqué très simplement : rien ne fonctionne.
Est-il possible de fusionner toutes les données avant de les déplacer vers des disques lents ?
Question sur le TTL avec l'option de passage au disque lent dans le cadre de fusions. Existe-t-il un moyen, autre que via cron, de fusionner toutes les parties en une seule avant de les déplacer vers des disques lents ?
La réponse à la question est-il possible de coller automatiquement toutes les pièces en une seule avant de les transférer - non. Je ne pense pas que ce soit nécessaire. Vous n'êtes pas obligé de fusionner toutes les pièces en une seule, mais comptez simplement sur le fait qu'elles seront automatiquement transférées sur des disques lents.
Nous avons deux critères pour les règles de transfert. Le premier est tel qu'il est rempli. Si le niveau de stockage actuel dispose de moins d'un certain pourcentage d'espace libre, nous sélectionnons un morceau et le déplaçons vers un stockage plus lent. Ou plutôt, pas plus lentement, mais le suivant - comme vous le configurez.
Le deuxième critère est la taille. Il s'agit de déplacer de gros morceaux. Vous pouvez ajuster le seuil en fonction de l'espace libre sur le disque rapide, et les données seront transférées automatiquement.
Comment migrer vers de nouvelles versions de ClickHouse s'il n'y a aucun moyen de vérifier la compatibilité à l'avance ?
Ce sujet est abordé régulièrement en tenant compte des différentes versions, et toujours. Dans quelle mesure est-il sûr de passer de la version 19.11 à la version 19.16 et, par exemple, de la version 19.16 à la version 20.3 ? Quelle est la meilleure façon de migrer vers de nouvelles versions sans pouvoir vérifier au préalable la compatibilité dans le sandbox ?
Il existe ici plusieurs règles « d’or ». D'abord - . Il est volumineux, mais il contient des paragraphes séparés sur les modifications rétrocompatibles. Ne traitez pas ces points comme un signal d’alarme. Il s’agit généralement d’incompatibilités mineures impliquant certaines fonctionnalités de pointe que vous n’utilisez probablement pas.
Deuxièmement, s’il n’existe aucun moyen de vérifier la compatibilité dans le bac à sable et que vous souhaitez effectuer la mise à jour immédiatement en production, il est recommandé de ne pas le faire. Créez d’abord un bac à sable et testez. S'il n'y a pas d'environnement de test, vous n'avez probablement pas une très grande entreprise, ce qui signifie que vous pouvez copier certaines données sur votre ordinateur portable et vous assurer que tout fonctionne correctement dessus. Vous pouvez même créer plusieurs répliques localement sur votre machine. Ou vous pouvez récupérer une nouvelle version quelque part à proximité et y télécharger certaines données, c'est-à-dire 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 bugs détectés en production et de correctifs rapides ultérieurs. Voyons la numérotation des versions de ClickHouse afin de ne pas nous tromper.
Il existe la version 20.3.4. Le chiffre 20 indique l'année de fabrication - 2020. Du point de vue de ce qu'il y a à l'intérieur, cela n'a pas d'importance, nous n'y prêterons donc pas attention. Suivant - 20.3. Nous augmentons le deuxième chiffre - dans ce cas 3 - chaque fois que nous publions une version avec de nouvelles fonctionnalités. Si nous voulons ajouter des fonctionnalités à ClickHouse, nous devons augmenter ce nombre. Autrement dit, dans la version 20.4, ClickHouse fonctionnera encore mieux. Le troisième chiffre est 20.3.4. Ici 4 est le nombre de versions de correctifs dans lesquelles nous n'avons pas ajouté de nouvelles fonctionnalités, mais corrigé quelques bugs. Et 4 signifie que nous l’avons fait quatre fois.
Ne pensez pas que c'est quelque chose de terrible. Habituellement, l'utilisateur peut installer la dernière version et celle-ci fonctionnera sans aucun problème de disponibilité par an. Mais imaginez que dans certaines fonctions de traitement des bitmaps, ajoutées par nos camarades chinois, le serveur plante lors du passage d'arguments incorrects. Nous avons la responsabilité de résoudre ce problème. Nous publierons une nouvelle version du correctif et ClickHouse deviendra plus stable.
Si ClickHouse est en production et qu'une nouvelle version de ClickHouse sort avec des fonctionnalités supplémentaires - par exemple, 20.4.1 est la toute première, ne vous précipitez pas pour la mettre en production dès le premier jour. Pourquoi est-ce même nécessaire ? Si vous n'utilisez pas déjà ClickHouse, vous pouvez l'installer et tout ira probablement bien. Mais si ClickHouse fonctionne déjà de manière stable, gardez un œil sur les correctifs et les mises à jour pour voir quels problèmes nous résolvons.
Kirill Chvakov : Je voudrais ajouter un peu sur les environnements de test. Tout le monde a très peur des environnements de test et, pour une raison quelconque, pense que si vous disposez d'un très grand cluster ClickHouse, l'environnement de test ne devrait pas être moins ou au moins dix fois plus petit. Ce n'est pas du tout comme ça.
Je peux vous le dire à partir de mon propre exemple. J'ai un projet et il y a ClickHouse. Notre environnement de test est rien que pour lui - il s'agit d'une petite machine virtuelle chez Hetzner pour vingt euros, où absolument tout est déployé. Pour ce faire, nous disposons d'une automatisation complète dans Ansible et, par conséquent, en principe, peu importe où aller - sur des serveurs matériels ou simplement déployer sur des machines virtuelles.
Ce qui peut être fait? Ce serait bien de fournir un exemple dans la documentation ClickHouse sur la façon de déployer un petit cluster dans votre propre maison - dans Docker, dans LXC, créez peut-être un playbook Ansible, car différentes personnes ont des déploiements différents. Cela simplifiera beaucoup. Lorsque vous prenez et déployez un cluster en cinq minutes, il est beaucoup plus facile d’essayer de comprendre quelque chose. C’est beaucoup plus pratique, car passer à une version de production que vous n’avez pas testée ne mène nulle part. Parfois ça marche et parfois non. Et donc espérer réussir est une mauvaise chose.
Maxim Kotyakov, ingénieur backend senior Avito : J'ajouterai un peu sur les environnements de test à partir d'une série de problèmes rencontrés par les grandes entreprises. Nous disposons d'un cluster d'acceptation ClickHouse à part entière ; en termes de schémas de données et de paramètres, il s'agit d'une copie exacte de ce qui est en production. Ce cluster est déployé dans des conteneurs assez dégradés avec un minimum de ressources. Nous y écrivons un certain pourcentage des données de production, heureusement il est possible de répliquer le flux dans Kafka. Tout y est synchronisé et évolutif - tant en termes de capacité que de flux, et, en théorie, toutes choses égales par ailleurs, cela devrait se comporter comme une production en termes de métriques. Tout ce qui est potentiellement explosif est d'abord roulé sur ce stand et y est laissé pendant plusieurs jours jusqu'à ce qu'il soit prêt. Mais bien entendu, cette solution est coûteuse, difficile et entraîne des coûts de support non nuls.
Alexeï Milovidov : Je vais vous dire à quoi ressemble l'environnement de test de nos amis de Yandex.Metrica. Un cluster comptait environ 600 serveurs, un autre 360, et il existe un troisième et plusieurs clusters. L’environnement de test pour l’un d’eux est simplement constitué de deux fragments contenant chacun deux répliques. Pourquoi deux fragments ? Pour que vous ne soyez pas seul. Et il devrait aussi y avoir des répliques. Juste un certain montant minimum que vous pouvez vous permettre.
Cet environnement de test vous permet de vérifier si vos requêtes fonctionnent et si quelque chose de majeur est cassé. Mais souvent, des problèmes surviennent d'une nature complètement différente, lorsque tout fonctionne, mais qu'il y a quelques petits changements dans la charge.
Laisse moi te donner un exemple. Nous avons décidé d'installer une nouvelle version de ClickHouse. Il a été publié sur un environnement de test, des tests automatisés ont été effectués dans Yandex.Metrica lui-même, qui comparent les données de l'ancienne version et de la nouvelle, exécutant l'ensemble du pipeline. Et bien sûr, des tests verts de notre CI. Sinon nous n'aurions même pas proposé cette version.
Tout va bien. Nous commençons à passer à la production. Je reçois un message indiquant que la charge sur les graphiques a augmenté plusieurs fois. Nous annulons la version. Je regarde le graphique et vois : la charge a en fait augmenté plusieurs fois pendant le déploiement, et a diminué lors du déploiement. Ensuite, nous avons commencé à restaurer la version. Et la charge a augmenté de la même manière et est retombée de la même manière. La conclusion est donc la suivante : la charge a augmenté à cause de l'aménagement, rien d'étonnant.
Il a ensuite été difficile de convaincre les collègues d’installer la nouvelle version. Je dis : « C’est bon, lancez-vous. Croisons les doigts, tout fonctionnera. Maintenant, la charge sur les graphiques a augmenté, mais tout va bien. Accrochez-vous. » En général, nous avons fait cela, et c'est tout - la version est sortie pour la production. Mais presque avec chaque mise en page, des problèmes similaires surviennent.
La requête Kill est censée tuer les requêtes, mais ce n'est pas le cas. Pourquoi?
Un utilisateur, une sorte d'analyste, est venu vers moi et a créé une requête qui a mis mon cluster ClickHouse. Un nœud ou un cluster entier, en fonction de la réplique ou de la partition à laquelle la requête a été adressée. Je vois que toutes les ressources CPU de ce serveur sont dans une étagère, tout est rouge. Dans le même temps, ClickHouse répond lui-même aux demandes. Et j’écris : « S’il vous plaît, montrez-moi, liste des processus, quelle demande a généré cette folie. »
Je trouve cette requête et j'y écris kill. Et je vois qu'il ne se passe rien. Mon serveur est dans une étagère, ClickHouse me donne alors quelques commandes, montre que le serveur est vivant, et tout va bien. Mais j'ai une dégradation dans toutes les demandes des utilisateurs, la dégradation commence par les enregistrements dans ClickHouse et ma requête kill ne fonctionne pas. Pourquoi? Je pensais que kill query était censé tuer les requêtes, mais ce n'est pas le cas.
Il y aura maintenant une réponse plutôt étrange. Le fait est que la requête kill ne tue pas les requêtes.
Kill query coche une petite case intitulée "Je veux que cette requête soit tuée". Et la requête elle-même examine cet indicateur lors du traitement de chaque bloc. S'il est défini, la requête cesse de fonctionner. Il s'avère que personne ne tue la demande, il doit lui-même tout vérifier et s'arrêter. Et cela devrait fonctionner dans tous les cas où la requête est en train de traiter des blocs de données. Il traitera le bloc de données suivant, vérifiera le drapeau et s'arrêtera.
Cela ne fonctionne pas dans les cas où la demande est bloquée sur une opération. Certes, ce n'est probablement pas votre cas, car, selon vous, cela utilise une tonne de ressources du serveur. Il est possible que cela ne fonctionne pas dans le cas d'un tri externe et dans certains autres détails. Mais en général, cela ne devrait pas arriver, c’est un bug. Et la seule chose que je peux recommander est de mettre à jour ClickHouse.
Comment calculer le temps de réponse sous charge de lecture ?
Il existe un tableau qui stocke les agrégats d'articles - divers compteurs. Le nombre de lignes est d'environ cent millions. Est-il possible de compter sur un temps de réponse prévisible si vous versez 1 1 RPS pour XNUMX XNUMX éléments ?
À en juger par le contexte, nous parlons de charge de lecture, car il n'y a aucun problème d'écriture - même mille, voire cent mille, et parfois plusieurs millions de lignes peuvent être insérées.
Les demandes de lecture sont très différentes. Dans Select 1, ClickHouse peut effectuer environ des dizaines de milliers de requêtes par seconde, de sorte que même les requêtes pour une clé nécessiteront déjà des ressources. Et de telles requêtes ponctuelles seront plus difficiles que dans certaines bases de données clé-valeur, car pour chaque lecture, il est nécessaire de lire un bloc de données par index. Notre index ne traite pas chaque enregistrement, mais chaque plage. Autrement dit, vous devrez lire toute la plage - il s'agit de 8192 64 lignes par défaut. Et vous devrez décompresser le bloc de données compressé de 1 Ko à XNUMX Mo. En règle générale, ces requêtes ciblées prennent quelques millisecondes. Mais c'est l'option la plus simple.
Essayons quelques calculs simples. Si vous multipliez quelques millisecondes par mille, vous obtenez quelques secondes. C’est comme s’il était impossible de répondre à mille requêtes par seconde, mais en fait c’est possible, car nous avons plusieurs cœurs de processeur. Ainsi, en principe, ClickHouse peut parfois détenir 1000 RPS, mais pour des demandes courtes, spécifiquement ciblées.
Si vous devez faire évoluer un cluster ClickHouse en fonction du nombre de requêtes simples, je recommande la chose la plus simple : augmenter le nombre de répliques et envoyer des requêtes à une réplique aléatoire. Si une réplique contient cinq cents requêtes par seconde, ce qui est tout à fait réaliste, alors trois répliques en traiteront mille cinq cents.
Parfois, bien sûr, vous pouvez configurer ClickHouse pour le nombre maximum de lectures de points. Que faut-il pour cela ? La première consiste à réduire la granularité de l’index. Dans ce cas, il ne faut pas le réduire à un, mais partir du principe que le nombre d'entrées dans l'index sera de plusieurs millions ou dizaines de millions par serveur. Si la table comporte cent millions de lignes, la granularité peut être définie sur 64.
Vous pouvez réduire la taille du bloc compressé. Il y a des paramètres pour cela taille minimale du bloc de compression, taille maximale du bloc de compression. Ils peuvent être réduits, remplis de données, et les requêtes ciblées seront alors plus rapides. Mais ClickHouse n’est pas une base de données clé-valeur. Un grand nombre de petites requêtes constituent un anti-modèle de charge.
Kirill Chvakov : Je donnerai des conseils au cas où il y aurait des comptes ordinaires là-bas. Il s'agit d'une situation assez courante lorsque ClickHouse stocke une sorte de compteur. J'ai un utilisateur, il vient de tel ou tel pays, et d'un troisième domaine, et j'ai besoin d'augmenter quelque chose progressivement. Prenez MySQL, créez une clé unique - dans MySQL, c'est une clé en double et dans PostgreSQL, c'est un conflit - et ajoutez un signe plus. Cela fonctionnera beaucoup mieux.
Lorsque vous ne disposez pas de beaucoup de données, cela ne sert à rien d’utiliser ClickHouse. Il existe des bases de données régulières et elles le font bien.
Que puis-je modifier dans ClickHouse pour que plus de données soient dans le cache ?
Imaginons une situation - les serveurs ont 256 Go de RAM, dans la routine quotidienne ClickHouse prend environ 60 à 80 Go, au maximum - jusqu'à 130. Ce qui peut être activé et modifié pour que plus de données soient dans le cache et, en conséquence, il y a moins de déplacements sur le disque ?
En règle générale, le cache de pages du système d'exploitation fait du bon travail. Si vous ouvrez simplement le haut, regardez là-bas en cache ou libre - cela indique également combien est mis en cache - alors vous remarquerez que toute la mémoire libre est utilisée pour le cache. Et lors de la lecture de ces données, elles ne seront pas lues à partir du disque, mais à partir de la RAM. En même temps, 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 plus certaines requêtes simples, il est possible d'activer un cache dans les données décompressées dans ClickHouse. On l'appelle cache non compressé. Dans le fichier de configuration config.xml, définissez la taille du cache non compressé sur la valeur dont vous avez besoin - je recommande de ne pas dépasser la moitié de la RAM libre, car le reste ira sous le cache des pages.
De plus, il existe deux paramètres de niveau de demande. Premier réglage - utiliser un cache non compressé - inclut son utilisation. Il est recommandé de l'activer pour toutes les requêtes, sauf les requêtes lourdes, qui permettent de lire toutes les données et de vider le cache. Et le deuxième paramètre est quelque chose comme le nombre maximum de lignes pour utiliser le cache. Il limite automatiquement les requêtes volumineuses afin qu'elles contournent le cache.
Comment puis-je configurer storage_configuration pour le stockage dans la RAM ?
Dans la nouvelle documentation ClickHouse, j'ai lu la section relative . La description contient un exemple avec un SSD rapide.
Je me demande comment la même chose peut être configurée avec la mémoire chaude du volume. Et encore une question. Comment Select fonctionne-t-il avec cette organisation de données, lira-t-il l'ensemble complet ou uniquement celui qui se trouve sur le disque, et ces données sont-elles compressées en mémoire ? Et comment la section prewhere fonctionne-t-elle avec une telle organisation de données ?
Ce paramètre affecte le stockage des blocs de données et leur format ne change en rien.
Regardons de plus près.
Vous pouvez configurer le stockage des données dans la RAM. Tout ce qui est configuré pour le disque est son chemin. Vous créez une partition tmpfs montée sur un chemin du système de fichiers. Vous spécifiez ce chemin comme chemin de stockage des données pour la partition la plus chaude, des morceaux de données commencent à arriver et à y être écrits, tout va bien.
Mais je ne recommande pas de le faire en raison de sa faible fiabilité, même si si vous disposez d'au moins trois répliques dans différents centres de données, c'est possible. Si quelque chose arrive, les données seront restaurées. Imaginons que le serveur soit soudainement éteint puis rallumé. La partition a été remontée, mais il n'y avait rien. Lorsque le serveur ClickHouse démarre, il constate qu'il ne dispose pas de ces éléments, même si, selon les métadonnées de ZooKeeper, ils devraient être là. Il regarde quelles répliques en possèdent, les demande et les télécharge. De cette façon, les données seront restaurées.
En ce sens, le stockage des données dans la RAM n'est pas fondamentalement différent du stockage sur disque, car lorsque les données sont écrites sur le disque, elles finissent également d'abord dans le cache des pages et sont écrites physiquement ultérieurement. Cela dépend de l'option de montage du système de fichiers. Mais juste au cas où, je dirai que ClickHouse ne se synchronise pas lors de l'insertion.
Dans ce cas, les données de la RAM sont stockées exactement dans le même format que sur le disque. De la même manière, la requête de sélection sélectionne les éléments qui doivent être lus, sélectionne les plages de données nécessaires dans les éléments et les lit. Et prewhere fonctionne exactement de la même manière, que les données se trouvent dans la RAM ou sur le disque.
Jusqu’à quel nombre de valeurs uniques la Low Cardinalité est-elle efficace ?
La faible cardinalité est intelligemment conçue. Il compile des dictionnaires de données, mais ils sont locaux. Premièrement, il existe différents dictionnaires pour chaque morceau, et deuxièmement, même au sein d'un même morceau, ils peuvent être différents pour chaque gamme. Lorsque le nombre de valeurs uniques atteint un seuil – un million, je pense – le dictionnaire est simplement mis de côté et un nouveau est créé.
La réponse est générale : pour chaque plage locale - disons, pour chaque jour - quelque part jusqu'à un million de valeurs uniques. Une faible cardinalité est efficace. Ensuite, il y aura simplement une solution de secours, dans laquelle de nombreux dictionnaires différents seront utilisés, et non un seul. Cela fonctionnera à peu près de la même manière qu'une colonne de chaînes ordinaire, peut-être un peu moins efficace, mais il n'y aura pas de dégradation sérieuse des performances.
Quelles sont les meilleures pratiques pour effectuer une recherche en texte intégral dans un tableau de cinq milliards de lignes ?
Il existe différentes réponses. La première est de dire que ClickHouse n’est pas un moteur de recherche en texte intégral. Il existe des systèmes spéciaux pour cela, par exemple и . Cependant, je vois de plus en plus de gens dire qu'ils passent d'Elasticsearch à ClickHouse.
Pourquoi cela arrive-t-il? Ils expliquent cela par le fait qu'Elasticsearch cesse de faire face à la charge sur certains volumes, à commencer par la construction des index. Les index deviennent trop encombrants et si vous transférez simplement les données vers ClickHouse, il s'avère qu'elles sont stockées plusieurs fois plus efficacement en termes de volume. Dans le même temps, les requêtes de recherche n'étaient souvent pas telles qu'il était nécessaire de trouver une expression dans l'ensemble du volume de données, en tenant compte de la morphologie, mais complètement différente. Par exemple, recherchez une sous-séquence d'octets dans les journaux des dernières heures.
Dans ce cas, vous créez un index dans ClickHouse dont le premier champ sera la date et l'heure. Et la plus grande limite de données sera basée sur la plage de dates. En règle générale, dans la plage de dates sélectionnée, il est déjà possible d'effectuer une recherche en texte intégral, même en utilisant la méthode de force brute en utilisant like. L'opérateur similaire dans ClickHouse est l'opérateur similaire le plus efficace que vous puissiez trouver. Si vous trouvez quelque chose de mieux, dites-le-moi.
Mais quand même, c’est comme une analyse complète. Et l'analyse complète peut être lente non seulement sur le processeur, mais également sur le disque. Si du coup vous disposez d'un téraoctet de données par jour et que vous recherchez un mot pendant la journée, vous devrez alors scanner le téraoctet. Et c'est probablement sur des disques durs ordinaires, et à la fin, ils seront chargés de telle manière que vous ne pourrez pas accéder à ce serveur via SSH.
Dans ce cas, je suis prêt à proposer encore une petite astuce. C'est expérimental – cela pourrait fonctionner, ou non. ClickHouse dispose d'index de texte intégral sous la forme de filtres trigrammes Bloom. Nos collègues d'Arenadata ont déjà essayé ces index, et ils fonctionnent souvent exactement comme prévu.
Afin de les utiliser correctement, vous devez bien comprendre exactement leur fonctionnement : ce qu'est un filtre trigramme Bloom et comment choisir sa taille. Je peux dire qu'ils aideront pour les requêtes sur certaines phrases rares, sous-chaînes rarement trouvées dans les données. Dans ce cas, les sous-plages seront sélectionnées par index et moins de données seront lues.
Récemment, ClickHouse a ajouté des fonctions encore plus avancées pour la recherche en texte intégral. Il s'agit, tout d'abord, d'une recherche d'un groupe de sous-chaînes à la fois en un seul passage, y compris des options sensibles à la casse, insensibles à la casse, avec prise en charge d'UTF-8 ou uniquement d'ASCII. Choisissez celui le plus efficace dont vous avez besoin.
La recherche de plusieurs expressions régulières en un seul passage est également apparue. Vous n'avez pas besoin d'écrire X comme une sous-chaîne ou X comme une autre sous-chaîne. Vous écrivez tout de suite et tout se fait le plus efficacement possible.
Troisièmement, il existe désormais une recherche approximative des expressions rationnelles et une recherche approximative des sous-chaînes. Si quelqu'un a mal orthographié un mot, la correspondance maximale sera recherchée.
Quelle est la meilleure façon d’organiser l’accès à ClickHouse pour un grand nombre d’utilisateurs ?
Dites-nous comment organiser au mieux l'accès pour un grand nombre de consommateurs et d'analystes. Comment former une file d'attente, prioriser le maximum de requêtes simultanées et avec quels outils ?
Si le cluster est suffisamment grand, alors une bonne solution serait d'augmenter deux serveurs supplémentaires, qui deviendront un point d'entrée pour les analystes. Autrement dit, n'autorisez pas les analystes à accéder à des fragments spécifiques du cluster, mais créez simplement deux serveurs vides, sans données, et configurez les droits d'accès sur ceux-ci. Dans ce cas, les paramètres utilisateur pour les requêtes distribuées sont transférés vers des serveurs distants. Autrement dit, vous configurez tout sur ces deux serveurs et les paramètres ont un effet sur l'ensemble du cluster.
En principe, ces serveurs ne disposent pas de données, mais la quantité de RAM qu'ils contiennent est très importante pour exécuter les 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 d'examiner les paramètres associés à toutes les limites possibles. Si je vais maintenant sur le cluster Yandex.Metrica en tant qu'analyste et pose une demande sélectionner le nombre de hits, alors je recevrai immédiatement une exception indiquant que je ne peux pas exécuter la demande. Le nombre maximum de lignes que je suis autorisé à analyser est de cent milliards, et au total il y en a cinquante mille milliards dans une table du cluster. C'est la première limite.
Disons que je supprime la limite de lignes et que je réexécute la requête. Ensuite, je verrai l'exception suivante : paramètre activé indice de force par date. Je ne peux pas terminer la requête si je n'ai pas spécifié de plage de dates. Vous n'avez pas besoin de compter sur des analystes pour le spécifier manuellement. Un cas typique est celui où une plage de dates est écrite où la date de l'événement se situe entre la semaine. Et puis ils ont simplement spécifié une parenthèse au mauvais endroit, et au lieu de et, il s'est avéré être ou - ou une correspondance d'URL. S'il n'y a pas de limite, il explorera la colonne URL et gaspillera simplement une tonne de ressources.
De plus, ClickHouse dispose de deux paramètres de priorité. Malheureusement, ils sont très primitifs. L'un s'appelle simplement priorité. Si la priorité ≠ 0 et que des requêtes avec une certaine priorité sont en cours d'exécution, mais qu'une requête avec une valeur de priorité inférieure à, ce qui signifie une priorité plus élevée, est en cours d'exécution, alors une requête avec une valeur de priorité supérieure, ce qui signifie une priorité plus faible. , est simplement suspendu et ne fonctionnera pas du tout pendant cette période.
Il s'agit d'un paramètre très rudimentaire qui ne convient pas aux cas où le cluster a une charge constante. Mais si vous avez des requêtes courtes et en rafale qui sont importantes et que le cluster est pour la plupart inactif, cette configuration est adaptée.
Le prochain paramètre de priorité est appelé Priorité du thread du système d'exploitation. Il définit simplement la bonne valeur pour tous les threads d'exécution de requêtes pour le planificateur Linux. Ça marche couci-couça, mais ça marche toujours. Si vous définissez la valeur minimale de nice - c'est la valeur la plus élevée, et donc la priorité la plus basse - et définissez -19 pour les requêtes à haute priorité, alors le processeur consommera environ quatre fois moins de requêtes à faible priorité que les requêtes à haute priorité.
Vous devez également configurer la durée maximale d'exécution de la requête, par exemple cinq minutes. La vitesse minimale d'exécution des requêtes est la chose la plus cool. Ce paramètre existe depuis longtemps, et il faut non seulement affirmer que ClickHouse ne ralentit pas, mais aussi le forcer.
Imaginez, vous configurez : si une requête traite moins d'un million de lignes par seconde, vous ne pouvez pas le faire. Cela déshonore notre réputation, notre bonne base de données. Interdisons simplement cela. Il existe en fait deux paramètres. L'un s'appelle vitesse d'exécution minimale - en lignes par seconde, et la seconde est appelée timeout avant de vérifier la vitesse d'exécution min - quinze secondes par défaut. Autrement dit, quinze secondes sont possibles, puis, si c'est lent, lancez simplement une exception et abandonnez la demande.
Vous devez également mettre en place des quotas. ClickHouse dispose d'une fonction de quota intégrée qui compte la consommation de ressources. Mais, malheureusement, pas de ressources matérielles telles que le processeur, les disques, mais logiques - le nombre de requêtes traitées, de lignes et d'octets lus. Et vous pouvez configurer, par exemple, un maximum de cent requêtes en cinq minutes et mille requêtes par heure.
Pourquoi c'est important? Parce que certaines requêtes d'analyse seront effectuées manuellement directement à partir du 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 entraînera l’exécution de la requête dans une boucle infinie. C’est contre cela que nous devons nous protéger.
Est-il possible de donner les résultats d’une requête à dix clients ?
Nous avons plusieurs utilisateurs qui aiment soumettre des demandes très volumineuses au même moment. La demande est volumineuse et, en principe, exécutée rapidement, mais du fait qu'il existe de nombreuses demandes de ce type en même temps, cela devient très pénible. Est-il possible d'exécuter une seule fois la même requête, arrivée dix fois de suite, et de donner le résultat à dix clients ?
Le problème est que nous n’avons pas les résultats du cache ou du cache des données intermédiaires. Il existe un cache de pages du système d'exploitation, qui vous empêchera de lire à nouveau les données du disque, mais, malheureusement, les données seront toujours décompressées, désérialisées et retraitées.
Je voudrais d'une manière ou d'une autre éviter cela, soit en mettant en cache les données intermédiaires, soit en alignant des requêtes similaires dans une sorte de file d'attente et en ajoutant un cache de résultats. Nous avons actuellement une pull request en développement qui ajoute un cache de requêtes, mais uniquement pour les sous-requêtes dans les sections in et join - c'est-à-dire que la solution est incomplète.
Cependant, nous sommes également confrontés à une telle situation. Un exemple particulièrement canonique est celui des requêtes paginées. Il y a un rapport, il a plusieurs pages, et il y a une demande de limite à 10. Puis la même chose, mais une limite à 10,10. Puis une autre page suivante. Et la question est : pourquoi compte-t-on tout cela à chaque fois ? Mais il n’y a désormais aucune solution, et il n’y a aucun moyen de l’éviter.
Il existe une solution alternative qui est placée comme side-car à côté de ClickHouse - .
Kirill Chvakov : ClickHouse Proxy dispose d'un limiteur de débit intégré et d'un cache de résultats intégré. De nombreux réglages y ont été effectués car un problème similaire était en cours de résolution. Le proxy vous permet de limiter les requêtes en les mettant en file d'attente et de configurer la durée de vie du cache des requêtes. Si les demandes étaient vraiment les mêmes, Proxy les enverra plusieurs fois, mais ne sera envoyé à ClickHouse qu'une seule fois.
Nginx dispose également d'un cache dans la version gratuite, et cela fonctionnera également. Nginx a même des paramètres selon lesquels si les demandes arrivent en même temps, il en ralentira les autres jusqu'à ce qu'une soit terminée. Mais c’est dans ClickHouse Proxy que la configuration se fait bien mieux. Il a été conçu spécifiquement pour ClickHouse, spécifiquement pour ces demandes, il est donc plus adapté. Eh bien, c’est facile à installer.
Qu’en est-il des opérations asynchrones et des vues matérialisées ?
Il existe un problème car les opérations avec le moteur de relecture sont asynchrones : les données sont d'abord écrites, puis elles s'effondrent. Si une tablette matérialisée avec quelques agrégats vit sous le signe, alors des doublons y seront écrits. Et s'il n'y a pas de logique complexe, alors les données seront dupliquées. Que peux-tu y faire?
Il existe une solution évidente : implémenter un déclencheur sur une certaine classe de matviews lors d'une opération de réduction asynchrone. Existe-t-il des solutions miracles ou des plans pour mettre en œuvre des fonctionnalités similaires ?
Il est utile de comprendre comment fonctionne la déduplication. Ce que je vais vous dire maintenant n’est pas pertinent par rapport à la question, mais juste au cas où cela vaut la peine de s’en souvenir.
Lors de l'insertion dans une table répliquée, il y a déduplication de l'intégralité des blocs insérés. Si vous réinsérez le même bloc contenant le même nombre de mêmes lignes dans le même ordre, alors les données sont dédupliquées. Vous recevrez « Ok » en réponse à l'insertion, mais en fait, un paquet de données sera écrit et il ne sera pas dupliqué.
Ceci est nécessaire pour plus de certitude. Si vous recevez « Ok » lors de l'insertion, cela signifie que vos données ont été insérées. Si vous recevez une erreur de ClickHouse, cela signifie qu'ils n'ont pas été insérés et que vous devez répéter l'insertion. Mais si la connexion est interrompue lors de 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 été réellement insérées et que vous les avez réinsérées, il y a une déduplication par bloc. Ceci est nécessaire pour éviter les doublons.
Et la manière dont cela fonctionne pour les vues matérialisées est également importante. Si les données ont été dédupliquées lors de leur insertion dans la table principale, elles n'iront pas non plus dans la vue matérialisée.
Maintenant à propos de la question. Votre situation est plus compliquée car vous enregistrez des doublons de lignes individuelles. Autrement dit, ce n'est pas l'intégralité du pack qui est dupliquée, mais des lignes spécifiques, et elles s'effondrent en arrière-plan. En effet, les données seront réduites dans la table principale, mais les données non réduites iront dans la vue matérialisée, et lors des fusions il n'arrivera rien aux vues matérialisées. Parce qu'une vue matérialisée n'est rien de plus qu'un déclencheur d'insertion. Lors d'autres opérations, il ne lui arrive rien de plus.
Et je ne peux pas te rendre heureux ici. Il vous suffit de rechercher une solution spécifique pour ce cas. Par exemple, est-il possible de le relire dans une vue matérialisée, et la méthode de déduplication pourrait fonctionner de la même manière. Mais malheureusement, pas toujours. S’il s’agit d’une agrégation, cela ne fonctionnera pas.
Kirill Chvakov : À l’époque, nous construisions également des béquilles. Il y a eu un problème avec les impressions publicitaires, et il existe certaines données que nous pouvons afficher en temps réel - ce ne sont que des impressions. Ils sont rarement dupliqués, mais si cela se produit, nous les réduirons de toute façon plus tard. Et il y avait des choses qui ne pouvaient pas être reproduites : les clics et toute cette histoire. Mais je voulais aussi les montrer presque immédiatement.
Comment ont été réalisées les vues matérialisées ? Il y avait des vues où cela était écrit directement - il était écrit dans des données brutes et écrit dans des vues. Là, à un moment donné, les données ne sont pas très correctes, elles sont dupliquées, etc. Et il y a une deuxième partie du tableau, où elles ressemblent exactement aux vues matérialisées, c'est-à-dire qu'elles ont une structure absolument identique. De temps en temps, nous recalculons les données, comptons les données sans doublons, écrivons dans ces tables.
Nous avons parcouru l'API - cela ne fonctionnera pas manuellement dans ClickHouse. Et l'API regarde : quand j'ai la date du dernier ajout à la table, où il est garanti que les données correctes ont déjà été calculées, et elle fait une requête à une table et à une autre table. De l'une, la demande sélectionne jusqu'à un certain temps et de l'autre, elle obtient ce qui n'a pas encore été calculé. Et cela fonctionne, mais pas uniquement via ClickHouse.
Si vous disposez d'une sorte d'API - pour les analystes, pour les utilisateurs - alors, en principe, c'est une option. Vous comptez toujours, vous comptez toujours. Cela peut être fait une fois par jour ou à un autre moment. Vous choisissez vous-même une plage dont vous n'avez pas besoin et qui n'est pas critique.
ClickHouse a beaucoup de journaux. Comment puis-je voir tout ce qui arrive au serveur d’un seul coup d’œil ?
ClickHouse possède un très grand nombre de logs différents, et ce nombre est en augmentation. Dans les nouvelles versions, certains d'entre eux sont même activés par défaut ; dans les anciennes versions, ils doivent être activés lors de la mise à jour. Pourtant, ils sont de plus en plus nombreux. En fin de compte, j'aimerais voir ce qui se passe avec mon serveur maintenant, peut-être sur une sorte de tableau de bord récapitulatif.
Avez-vous une équipe ClickHouse, ou les équipes de vos amis, qui prennent en charge certaines fonctionnalités de tableaux de bord prêts à l'emploi qui afficheraient ces journaux comme un produit fini ? En fin de compte, il suffit de consulter les journaux dans ClickHouse. Mais ce serait très cool s'il était déjà préparé sous la forme d'un tableau de bord. J'en prendrais un coup de pied.
Il existe des tableaux de bord, même s'ils ne sont pas standardisés. Dans notre entreprise, environ 60 équipes utilisent ClickHouse, et le plus étrange est que beaucoup d'entre elles ont des tableaux de bord qu'elles ont créés elles-mêmes, et légèrement différents. Certaines équipes utilisent une installation interne de Yandex.Cloud. Il existe quelques rapports prêts à l'emploi, mais pas tous ceux nécessaires. D'autres ont le leur.
Mes collègues de Metrica ont leur propre tableau de bord dans Grafana, et j'ai le mien pour leur cluster. Je regarde des choses comme le cache hit pour le cache serif. Et ce qui est encore plus difficile, c'est que nous utilisons des outils différents. J'ai créé mon tableau de bord à l'aide d'un très ancien outil appelé Graphite-web. Il est complètement laid. Et je l'utilise toujours de cette façon, même si Grafana serait probablement plus pratique et plus beau.
La base des tableaux de bord est la même. Il s'agit de métriques système pour le cluster : CPU, mémoire, disque, réseau. Autres - nombre de requêtes simultanées, nombre de fusions simultanées, nombre de requêtes par seconde, nombre maximum de morceaux pour les partitions de table MergeTree, délai de réplication, taille de la file d'attente de réplication, nombre de lignes insérées par seconde, nombre de blocs insérés par seconde. C'est tout ce qui est obtenu non pas à partir des journaux, mais à partir des métriques.
Vladimir Kolobaev : Alexey, je voudrais le corriger un peu. Il y a Grafana. Grafana dispose d'une source de données, qui est ClickHouse. Autrement dit, je peux faire des demandes de Grafana directement à ClickHouse. ClickHouse a un tableau avec les logs, c'est le même pour tout le monde. En conséquence, je souhaite accéder à cette table de journal dans Grafana et voir les requêtes effectuées par mon serveur. Ce serait formidable d'avoir un tableau de bord comme celui-ci.
Je l'ai fait moi-même. Mais j'ai une question : si tout est standardisé et que Grafana est utilisé par tout le monde, pourquoi Yandex n'a-t-il pas un tel tableau de bord officiel ?
Kirill Chvakov : En fait, la source de données destinée à ClickHouse prend désormais en charge Altinity. Et je veux juste donner un vecteur indiquant où creuser et qui pousser. Vous pouvez leur demander, car Yandex crée toujours ClickHouse, et non l'histoire qui l'entoure. Altinity est la principale société faisant actuellement la promotion de ClickHouse. Ils ne l’abandonneront pas, mais le soutiendront. Car, en principe, pour télécharger un tableau de bord sur le site Grafana, il vous suffit de vous inscrire et de le télécharger - il n'y a pas de problèmes particuliers.
Alexeï Milovidov : Au cours de la dernière année, ClickHouse a ajouté de nombreuses fonctionnalités de profilage de requêtes. Il existe des métriques pour chaque demande sur l'utilisation des ressources. Et tout récemment, nous avons ajouté un profileur de requêtes de niveau encore plus bas pour voir où passe une requête chaque milliseconde. Mais pour utiliser cette fonctionnalité, je dois ouvrir le client console et taper une requête, que j'oublie toujours. Je l'ai sauvegardé quelque part et j'oublie toujours où exactement.
J'aurais aimé qu'il y ait un outil qui vient de dire, voici vos requêtes lourdes, regroupées par classe de requêtes. J’en ai appuyé sur un, et ils me disaient que c’est pour ça qu’il est lourd. Une telle solution n’existe pas actuellement. Et c'est vraiment assez étrange que quand les gens me demandent : "Dites-moi, y a-t-il des tableaux de bord prêts à l'emploi pour Grafana ?", je réponds : "Allez sur le site Grafana, il y a une communauté "Dashboards", et il y a un tableau de bord de Dimka, il y a un tableau de bord de Kostyan. Je ne sais pas ce que c’est, je ne l’ai pas utilisé moi-même.
Comment influencer les fusions pour que le serveur ne crashe pas dans le MOO ?
J'ai une table, il n'y a qu'une seule partition dans la table, c'est ReplaceingMergeTree. J'y écris des données depuis quatre ans. Je devais y apporter une modification et supprimer certaines données.
Je l'ai fait et pendant le traitement de cette demande, toute la mémoire de tous les serveurs du cluster a été consommée et tous les serveurs du cluster sont entrés dans le MOO. Ensuite, ils se sont tous levés, ont commencé à fusionner cette même opération, ce bloc de données, et sont retombés dans le MOO. Puis ils se relevèrent et retombèrent. Et cette chose ne s'est pas arrêtée.
Ensuite, il s’est avéré qu’il s’agissait en fait d’un bug que les gars ont corrigé. C'est très cool, merci beaucoup. Mais il restait un résidu. Et maintenant, quand je pense à faire une sorte de fusion dans le tableau, j'ai une question : pourquoi ne puis-je pas influencer ces fusions d'une manière ou d'une autre ? Par exemple, limitez-les par la quantité de RAM requise ou, en principe, par la quantité qui traitera cette table particulière.
J'ai un tableau appelé « Métriques », veuillez le traiter pour moi dans deux fils de discussion. Il n’est pas nécessaire de créer dix ou cinq fusions en parallèle, faites-le en deux. Je pense que j'ai assez de mémoire pour deux, mais ce n'est peut-être pas suffisant pour en traiter dix. Pourquoi la peur demeure-t-elle ? Parce que la table s'agrandit, et qu'un jour je serai confronté à une situation qui, en principe, n'est plus due à un bug, mais parce que les données vont changer dans une telle quantité que je n'aurai tout simplement pas assez de mémoire sur le serveur. Et puis le serveur plantera dans le MOO lors de la fusion. De plus, je peux annuler la mutation, mais Merji n'est plus là.
Vous savez, lors de la fusion, le serveur ne tombera pas dans le MOO, car lors de la fusion, la quantité de RAM n'est utilisée que pour une petite plage de données. Ainsi, tout ira bien quelle que soit la quantité de données.
Vladimir Kolobaev : Bien. Ici, le moment est tel qu'après la correction du bug, j'ai téléchargé une nouvelle version pour moi-même, et sur une autre table, plus petite, où il y a de nombreuses partitions, j'ai effectué une opération similaire. Et lors de la fusion, environ 100 Go de RAM ont été brûlés sur le serveur. J’en avais 150 occupés, 100 mangés et il me restait une fenêtre de 50 Go, donc je ne suis pas tombé dans le MOO.
Qu'est-ce qui me protège actuellement de tomber dans le MOO s'il consomme réellement 100 Go de RAM ? Que faire si soudainement la RAM sur les fusions s'épuise ?
Alexeï Milovidov : Il existe un tel problème que la consommation de RAM spécifiquement pour la fusion n'est pas limitée. Et le deuxième problème est que si une sorte de fusion a été assignée, elle doit alors ê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 vous n'effectuez pas de manipulations manuelles qui annuleraient ce journal de réplication, la fusion devra être effectuée d'une manière ou d'une autre.
Bien sûr, il ne serait pas superflu d'avoir une limitation de RAM qui protège « au cas où » contre le MOO. Cela n'aidera pas la fusion à se terminer, elle 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 restriction.
Comment le pilote Golang pour ClickHouse sera-t-il développé ?
Le pilote Golang, écrit par Kirill Shvakov, est désormais officiellement pris en charge par l'équipe ClickHouse. Il , il est désormais grand et réel.
Une petite remarque. Il existe un référentiel merveilleux et bien-aimé de formes normales d’ordre infini : c’est Vertica. Ils disposent également de leur propre pilote Python officiel, pris en charge par les développeurs Vertica. Et à plusieurs reprises, il est arrivé que les versions de stockage et les versions de pilote divergent de manière assez spectaculaire, et le pilote à un moment donné a cessé de fonctionner. Et le deuxième point. Il me semble que la prise en charge de ce pilote officiel est assurée par le système "mamelon" - vous leur écrivez un problème, et il se bloque pour toujours.
J'ai deux questions. Désormais, le pilote Golang de Kirill est presque le moyen par défaut de communiquer depuis Golang avec ClickHouse. A moins que quelqu'un communique encore via l'interface http parce qu'il aime ça. Comment se déroulera le développement de ce pilote ? Sera-t-il synchronisé avec les modifications importantes apportées au référentiel lui-même ? Et quelle est la procédure à suivre pour examiner une question ?
Kirill Chvakov : La première est la manière dont tout est organisé bureaucratiquement. Ce point n'a pas été abordé, je n'ai donc rien à répondre.
Pour répondre à la question sur le problème, nous avons besoin d’un petit historique du conducteur. J'ai travaillé pour une entreprise qui disposait de beaucoup de données. Il s’agissait d’un outil publicitaire comportant un grand nombre d’événements qui devaient être stockés quelque part. Et à un moment donné, ClickHouse est apparu. Nous l'avons rempli de données, et au début tout allait bien, mais ClickHouse s'est ensuite écrasé. À ce moment-là, nous avons décidé que nous n’en avions pas besoin.
Un an plus tard, nous sommes revenus à l'idée d'utiliser ClickHouse, et nous devions y écrire des données d'une manière ou d'une autre. Le message d'introduction était le suivant : le matériel est très faible, il y a peu de ressources. Mais nous avons toujours travaillé de cette façon et nous nous sommes donc tournés vers le protocole natif.
Puisque nous travaillions chez Go, il était clair que nous avions besoin d’un pilote Go. Je le faisais presque à temps plein – c'était ma tâche professionnelle. Nous l'avons amené à un certain point et, en principe, personne ne pensait que quelqu'un d'autre que nous l'utiliserait. Ensuite, CloudFlare a rencontré exactement le même problème et pendant un certain temps, nous avons travaillé avec eux de manière très fluide, car ils avaient les mêmes tâches. De plus, nous l'avons fait nous-mêmes dans ClickHouse et dans le pilote.
À un moment donné, j'ai tout simplement arrêté de le faire, car mon activité en termes de ClickHouse et de travail a un peu changé. Les questions ne sont donc pas closes. Périodiquement, les personnes qui ont elles-mêmes besoin de quelque chose s’engagent dans le référentiel. Ensuite, je regarde la pull request et parfois je modifie même quelque chose moi-même, mais cela arrive rarement.
Je veux retourner auprès du chauffeur. Il y a plusieurs années, lorsque tout cela a commencé, ClickHouse était également différent et doté de capacités différentes. Nous comprenons maintenant comment refaire le pilote pour qu'il fonctionne correctement. Si cela se produit, alors la version 2 sera de toute façon incompatible en raison des béquilles accumulées.
Je ne sais pas comment organiser cette affaire. Je n'ai pas beaucoup de temps moi-même. Si certaines personnes terminent le driver, je peux les aider et leur dire quoi faire. Mais la participation active de Yandex au développement du projet n'a pas encore été discutée.
Alexeï Milovidov : En fait, il n’existe pas encore de bureaucratie concernant ces conducteurs. La seule chose est qu'ils sont soumis à une organisation officielle, c'est-à-dire que ce pilote est reconnu comme la solution officielle par défaut pour Go. Il existe d'autres pilotes, mais ils viennent séparément.
Nous n'avons aucun développement interne pour ces pilotes. La question est de savoir si nous pouvons embaucher une personne individuelle, non pas pour ce conducteur en particulier, mais pour le développement de tous les conducteurs communautaires, ou pouvons-nous trouver quelqu'un de l'extérieur.
Le dictionnaire externe ne se charge pas après un redémarrage avec le paramètre lazy_load activé. Ce qu'il faut faire?
Le paramètre lazy_load est activé et après le redémarrage du serveur, le dictionnaire ne se charge pas tout seul. Il n'est généré qu'après que l'utilisateur accède à ce dictionnaire. Et la première fois que j'y accède, cela donne une erreur. Est-il possible de charger automatiquement des dictionnaires à l'aide de ClickHouse, ou devez-vous toujours contrôler vous-même leur état de préparation afin que les utilisateurs ne reçoivent pas d'erreurs ?
Peut-être avons-nous une ancienne version de ClickHouse, donc le dictionnaire ne s'est pas chargé automatiquement. Est-ce que cela pourrait être le cas ?
Premièrement, les dictionnaires peuvent être chargés de force à l'aide d'une requête dictionnaires de rechargement du système. Deuxièmement, concernant l'erreur : si le dictionnaire est déjà chargé, les requêtes fonctionneront en fonction des données chargées. Si le dictionnaire n'a pas encore été chargé, il le sera directement lors de la requête.
Ce n’est pas très pratique pour les dictionnaires lourds. Par exemple, vous devez extraire un million de lignes de MySQL. Quelqu'un effectue une sélection simple, mais cette sélection attendra le même million de lignes. Il y a deux solutions ici. La première consiste à désactiver lazy_load. Deuxièmement, lorsque le serveur est opérationnel, avant de lui mettre la charge, faites dictionnaire de rechargement du système ou faites simplement une requête qui utilise un dictionnaire. Ensuite, le dictionnaire sera chargé. Vous devez contrôler la disponibilité des dictionnaires avec le paramètre lazy_load activé, car ClickHouse ne les charge pas automatiquement.
La réponse à la dernière question est soit la version est ancienne, soit elle doit être déboguée.
Que faire du fait que les dictionnaires de rechargement du système ne chargent aucun des nombreux dictionnaires si au moins l'un d'entre eux plante avec une erreur ?
Il y a une autre question concernant le rechargement des dictionnaires du système. Nous avons deux dictionnaires : l'un n'est pas chargé, le second est chargé. Dans ce cas, les dictionnaires de rechargement du système ne chargent aucun dictionnaire et vous devez en charger un spécifique point par point par son nom à l'aide du dictionnaire de rechargement du système. Est-ce également lié à la version ClickHouse ?
Je veux vous rendre heureux. Ce comportement était en train de changer. Cela signifie que si vous mettez à jour ClickHouse, cela changera également. Si vous n'êtes pas satisfait de votre comportement actuel dictionnaires de rechargement du système, mettez à jour et espérons que cela changera pour le mieux.
Existe-t-il un moyen de configurer les détails dans la configuration ClickHouse, mais de ne pas les afficher en cas d'erreurs ?
La question suivante concerne les erreurs liées au dictionnaire, à savoir les détails. Nous avons spécifié les détails de connexion dans la configuration ClickHouse pour le dictionnaire, et s'il y a une erreur, nous recevons ces détails et le mot de passe en réponse.
Nous avons résolu cette erreur en ajoutant des détails à la configuration du pilote ODBC. Existe-t-il un moyen de configurer les détails dans la configuration ClickHouse, mais de ne pas afficher ces détails en cas d'erreurs ?
La vraie solution ici consiste à spécifier ces informations d'identification dans odbc.ini et dans ClickHouse lui-même, à spécifier uniquement le nom de la source de données ODBC. Cela n'arrivera pas pour les autres sources de dictionnaires - ni pour le dictionnaire avec MySQL, ni pour les autres, vous ne devriez pas voir le mot de passe lorsque vous recevez un message d'erreur. Pour ODBC, je regarderai aussi - s'il existe, il vous suffit de le supprimer.
Bonus : arrière-plans pour Zoom lors de rassemblements
En cliquant sur l'image, des fonds bonus des rassemblements s'ouvriront pour les lecteurs les plus persistants. Nous éteignons le feu avec les mascottes technologiques Avito, nous discutons avec des collègues de la salle de l'administrateur système ou du club informatique de la vieille école et nous organisons des réunions quotidiennes sous le pont sur fond de graffitis.
Source: habr.com