La contribution de Yandex aux bases de données suivantes sera examinée.
- Cliquez Maison
- Odyssey
- Récupération à un moment donné (WAL-G)
- PostgreSQL (y compris logerrors, Amcheck, heapcheck)
- Prune verte
Vidéo:
Bonjour le monde! Je m'appelle Andreï Borodine. Et ce que je fais chez Yandex.Cloud, c'est développer des bases de données relationnelles ouvertes dans l'intérêt des clients Yandex.Cloud et Yandex.Cloud.
Dans cette présentation, nous aborderons les défis auxquels sont confrontées les bases de données ouvertes à grande échelle. Pourquoi c'est important? Parce que des petits problèmes qui, comme les moustiques, se transforment ensuite en éléphants. Ils deviennent gros lorsque vous avez de nombreux clusters.
Mais ce n'est pas l'essentiel. Des choses incroyables se produisent. Des choses qui arrivent dans un cas sur un million. Et dans un environnement cloud, vous devez vous y préparer, car des choses incroyables deviennent hautement probables lorsque quelque chose existe à grande échelle.
Mais! Quel est l’avantage des bases de données ouvertes ? Le fait est que vous avez une opportunité théorique de résoudre n'importe quel problème. Vous avez le code source, vous avez des connaissances en programmation. On le combine et ça marche.
Quelles approches existe-t-il pour travailler sur des logiciels open source ?
- L'approche la plus simple consiste à utiliser un logiciel. Si vous utilisez des protocoles, si vous utilisez des standards, si vous utilisez des formats, si vous écrivez des requêtes dans un logiciel open source, alors vous le supportez déjà.
- Vous agrandissez son écosystème. Vous augmentez la probabilité de détection précoce d’un bug. Vous augmentez la fiabilité de ce système. Vous augmentez la disponibilité des développeurs sur le marché. Vous améliorez ce logiciel. Vous êtes déjà un contributeur si vous venez de créer du style et de bricoler quelque chose là-bas.
- Une autre approche compréhensible consiste à sponsoriser des logiciels open source. Par exemple, le célèbre programme Google Summer of Code, dans lequel Google verse de l'argent compréhensible à un grand nombre d'étudiants du monde entier afin qu'ils développent des projets de logiciels ouverts qui répondent à certaines exigences de licence.
- C'est une approche très intéressante car elle permet au logiciel d'évoluer sans détourner l'attention de la communauté. Google, en tant que géant de la technologie, ne dit pas que nous voulons cette fonctionnalité, nous voulons corriger ce bug et c'est là que nous devons creuser. Google dit : « Faites ce que vous faites. Continuez simplement à travailler comme vous l’avez fait et tout ira bien.
- La prochaine approche pour participer à l’open source est la participation. Lorsque vous rencontrez un problème avec un logiciel open source et qu'il y a des développeurs, vos développeurs commencent à résoudre les problèmes. Ils commencent à rendre votre infrastructure plus efficace, vos programmes plus rapides et plus fiables.
L'un des projets Yandex les plus célèbres dans le domaine des logiciels open source est ClickHouse. Il s'agit d'une base de données née en réponse aux défis auxquels Yandex.Metrica est confronté.
Et en tant que base de données, elle a été réalisée en open source afin de créer un écosystème et de le développer avec d'autres développeurs (pas seulement au sein de Yandex). Et maintenant, il s’agit d’un grand projet dans lequel de nombreuses entreprises différentes sont impliquées.
Dans Yandex.Cloud, nous avons créé ClickHouse au-dessus de Yandex Object Storage, c'est-à-dire au-dessus du stockage cloud.
Pourquoi est-ce important dans le cloud ? Parce que toute base de données fonctionne dans ce triangle, dans cette pyramide, dans cette hiérarchie de types de mémoire. Vous disposez de registres rapides mais petits et de SSD, disques durs et autres périphériques bloc bon marché, grands mais lents. Et si vous êtes efficace au sommet de la pyramide, alors vous disposez d’une base de données rapide. si vous êtes efficace au bas de cette pyramide, alors vous disposez d’une base de données à grande échelle. Et à cet égard, l’ajout d’une autre couche par le bas est une approche logique pour augmenter l’évolutivité de la base de données.
Comment pourrait-on le faire? C’est un point important de ce rapport.
- Nous pourrions implémenter ClickHouse sur MDS. MDS est une interface de stockage cloud Yandex interne. Il est plus complexe que le protocole S3 commun, mais il est plus adapté à un périphérique bloc. C'est mieux pour enregistrer des données. Cela nécessite plus de programmation. Les programmeurs vont programmer, c’est même bien, c’est intéressant.
- S3 est une approche plus courante qui simplifie l’interface au prix d’une moindre adaptation à certains types de charges de travail.
Naturellement, souhaitant fournir des fonctionnalités à l'ensemble de l'écosystème ClickHouse et effectuer la tâche nécessaire dans Yandex.Cloud, nous avons décidé de nous assurer que l'ensemble de la communauté ClickHouse en bénéficierait. Nous avons implémenté ClickHouse sur S3, et non ClickHouse sur MDS. Et c'est beaucoup de travail.
Liens:
"Couche d'abstraction du système de fichiers"
"Intégration AWS SDK S3"
« Implémentation de base de l'interface IDisk pour S3 »
"Intégration des moteurs de stockage de logs avec l'interface IDisk"
"Prise en charge du moteur de journalisation pour S3 et SeekableReadBuffer"
"Prise en charge du stockage Stripe Log S3"
« Prise en charge initiale de Storage MergeTree pour S3 »
"Prise en charge complète de MergeTree pour S3"
"Prise en charge de ReplicatedMergeTree sur S3"
"Ajouter des informations d'identification par défaut et des en-têtes personnalisés pour le stockage s3"
"S3 avec configuration de proxy dynamique"
"S3 avec résolveur proxy"
Il s'agit d'une liste de demandes d'extraction pour la mise en œuvre d'un système de fichiers virtuel dans ClickHouse. Il s’agit d’un grand nombre de pull request.
Liens:
"Implémentation optimale des liens durs DiskS3"
« Client HTTP S3 – Évitez de copier le flux de réponses en mémoire »
"Évitez de copier l'intégralité du flux de réponse en mémoire dans S3 HTTP
client"
« Possibilité de mettre en cache les fichiers de marquage et d'indexation pour le disque S3 »
"Déplacer des pièces de DiskLocal vers DiskS3 en parallèle"
Mais le travail ne s'est pas arrêté là. Une fois la fonctionnalité créée, des travaux supplémentaires ont été nécessaires afin d'optimiser cette fonctionnalité.
Liens:
"Ajouter des événements SelectedRows et SelectedBytes"
"Ajouter des événements de profilage de la requête S3 à system.events"
"Ajouter QueryTimeMicroseconds, SelectQueryTimeMicroseconds et InsertQueryTimeMicroseconds"
Et puis il a fallu le rendre diagnostiquable, mettre en place un suivi et le rendre gérable.
Et tout cela a été fait pour que toute la communauté, tout l'écosystème ClickHouse, reçoive le résultat de ce travail.
Passons aux bases de données transactionnelles, aux bases de données OLTP, qui sont plus proches de moi personnellement.
Il s'agit de la division de développement de SGBD open source. Ces gars font de la magie de rue pour améliorer les bases de données ouvertes transactionnelles.
L'un des projets, à l'aide d'un exemple dont nous pouvons parler de comment et de ce que nous faisons, est le Connection Pooler dans Postgres.
Postgres est une base de données de processus. Cela signifie que la base de données doit disposer du moins de connexions réseau possible pour gérer les transactions.
D'un autre côté, dans un environnement cloud, une situation typique est celle où un millier de connexions arrivent simultanément sur un cluster. Et la tâche du pooleur de connexions est de regrouper un millier de connexions dans un petit nombre de connexions serveur.
On peut dire que le pooleur de connexions est l'opérateur téléphonique qui réorganise les octets pour qu'ils atteignent efficacement la base de données.
Malheureusement, il n’existe pas de bon mot russe pour désigner un pooleur de connexions. Parfois, on parle de connexions multiplexeurs. Si vous savez comment appeler le pooler de connexions, n'hésitez pas à me le dire, je serai très heureux de parler le langage technique russe correct.
Nous avons étudié les poolers de connexions adaptés à un cluster Postgres géré. Et PgBouncer était le meilleur choix pour nous. Mais nous avons rencontré un certain nombre de problèmes avec PgBouncer. Il y a de nombreuses années, Volodia Borodine a rapporté que nous utilisons PgBouncer, nous aimons tout, mais il y a des nuances, il y a quelque chose sur lequel travailler.
Et nous avons travaillé. Nous avons résolu les problèmes que nous avons rencontrés, nous avons corrigé Bouncer et essayé de pousser les requêtes pull en amont. Mais le monothreading fondamental était difficile à travailler.
Nous avons dû collecter des cascades auprès de videurs corrigés. Lorsque nous avons de nombreux Bouncers monothread, les connexions de la couche supérieure sont transférées vers la couche interne des Bouncers. Il s’agit d’un système mal géré, difficile à construire et à faire évoluer.
Nous sommes arrivés à la conclusion que nous avons créé notre propre pool de connexions, appelé Odyssey. Nous l'avons écrit à partir de zéro.
En 2019, lors de la conférence PgCon, j'ai présenté ce pooler à la communauté des développeurs. Nous avons désormais un peu moins de 2 000 étoiles sur GitHub, c'est-à-dire que le projet est vivant, le projet est populaire.
Et si vous créez un cluster Postgres dans Yandex.Cloud, il s'agira alors d'un cluster avec Odyssey intégré, qui est reconfiguré lors de la mise à l'échelle du cluster en avant ou en arrière.
Qu’avons-nous appris de ce projet ? Lancer un projet concurrent est toujours une démarche agressive, c'est une mesure extrême quand on dit qu'il y a des problèmes qui ne sont pas résolus assez rapidement, qui ne sont pas résolus dans les délais qui nous conviendraient. Mais c'est une mesure efficace.
PgBouncer a commencé à se développer plus rapidement.
Et maintenant, d'autres projets sont apparus. Par exemple, pgagroal, développé par les développeurs Red Hat. Ils poursuivent des objectifs similaires et mettent en œuvre des idées similaires, mais, bien sûr, avec leurs propres spécificités, plus proches des développeurs de pgagroal.
Un autre cas de travail avec la communauté postgres est la restauration à un moment donné. Il s'agit d'une récupération après une panne, d'une récupération à partir d'une sauvegarde.
Il existe de nombreuses sauvegardes et elles sont toutes différentes. Presque tous les fournisseurs Postgres disposent de leur propre solution de sauvegarde.
Si vous prenez tous les systèmes de sauvegarde, créez une matrice de fonctionnalités et calculez en plaisantant le déterminant dans cette matrice, il sera nul. Qu'est-ce que cela signifie? Que se passe-t-il si vous prenez un fichier de sauvegarde spécifique, il ne peut alors pas être assemblé à partir de morceaux de tous les autres. Il est unique dans sa mise en œuvre, il est unique dans son objectif, il est unique dans les idées qui y sont intégrées. Et ils sont tous spécifiques.
Pendant que nous travaillions sur cette problématique, CitusData a lancé le projet WAL-G. Il s'agit d'un système de sauvegarde conçu en tenant compte de l'environnement cloud. Désormais, CitusData fait déjà partie de Microsoft. Et à ce moment-là, nous avons vraiment aimé les idées énoncées dans les premières versions de WAL-G. Et nous avons commencé à contribuer à ce projet.
Il y a maintenant plusieurs dizaines de développeurs dans ce projet, mais parmi les 10 principaux contributeurs de WAL-G figurent 6 Yandexoïdes. Nous y avons apporté beaucoup de nos idées. Et, bien sûr, nous les avons implémentés nous-mêmes, les avons testés nous-mêmes, les avons nous-mêmes mis en production, nous les utilisons nous-mêmes, nous déterminons nous-mêmes où aller ensuite, tout en interagissant avec la grande communauté WAL-G.
Et de notre point de vue, ce système de sauvegarde, notamment en tenant compte de nos efforts, est devenu optimal pour un environnement cloud. C'est le meilleur coût pour sauvegarder Postgres dans le cloud.
Qu'est-ce que ça veut dire? Nous promouvions une idée assez grande : la sauvegarde doit être sécurisée, peu coûteuse à exploiter et aussi rapide que possible à restaurer.
Pourquoi son fonctionnement devrait-il être peu coûteux ? Quand rien n’est cassé, vous ne devriez pas savoir que vous disposez de sauvegardes. Tout fonctionne bien, vous gaspillez le moins de CPU possible, vous utilisez le moins de ressources disque possible et vous envoyez le moins d'octets possible au réseau afin de ne pas interférer avec la charge utile de vos précieux services.
Et quand tout tombe en panne, par exemple, que l'administrateur a abandonné les données, que quelque chose s'est mal passé et que vous avez un besoin urgent de revenir dans le passé, vous récupérez avec tout l'argent, car vous voulez que vos données soient récupérées rapidement et intactes.
Et nous avons promu cette idée simple. Et il nous semble que nous avons réussi à le mettre en œuvre.
Mais ce n'est pas tout. Nous voulions encore une petite chose. Nous voulions de nombreuses bases de données différentes. Tous nos clients n'utilisent pas Postgres. Certaines personnes utilisent MySQL, MongoDB. Dans la communauté, d'autres développeurs ont pris en charge FoundationDB. Et cette liste ne cesse de s’allonger.
La communauté aime l'idée que la base de données soit exécutée dans un environnement géré dans le cloud. Et les développeurs maintiennent leurs bases de données, qui peuvent être sauvegardées uniformément avec Postgres avec notre système de sauvegarde.
Qu’avons-nous appris de cette histoire ? Notre produit, en tant que division de développement, n'est pas constitué de lignes de code, ce ne sont pas des instructions, ce ne sont pas des fichiers. Notre produit n'est pas une demande de tirage. Ce sont les idées que nous transmettons à la communauté. Il s’agit de l’expertise technologique et du mouvement de la technologie vers un environnement cloud.
Il existe une base de données telle que Postgres. J'aime le plus le noyau Postgres. Je passe beaucoup de temps à développer le noyau de Postgres avec la communauté.
Mais ici, il faut dire que Yandex.Cloud dispose d'une installation interne de bases de données gérées. Et cela a commencé il y a longtemps dans Yandex.Mail. L'expertise qui a maintenant conduit à Postgres géré a été accumulée lorsque le courrier a voulu migrer vers Postgres.
Le courrier a des exigences très similaires à celles du cloud. Il faut que vous soyez capable d'évoluer vers une croissance exponentielle inattendue à tout moment dans vos données. Et le courrier était déjà chargé de plusieurs centaines de millions de boîtes aux lettres d'un grand nombre d'utilisateurs qui font constamment de nombreuses demandes.
Et c’était un défi de taille pour l’équipe qui développait Postgres. À l’époque, tous les problèmes que nous rencontrions étaient signalés à la communauté. Et ces problèmes ont été corrigés, et corrigés par la communauté à certains endroits même au niveau du support payant pour certaines autres bases de données et même mieux. Autrement dit, vous pouvez envoyer une lettre au pirate informatique PgSQL et recevoir une réponse dans les 40 minutes. Le support payant dans certaines bases de données peut penser qu'il y a des choses plus prioritaires que votre bug.
Désormais, l'installation interne de Postgres représente quelques pétaoctets de données. Cela représente quelques millions de requêtes par seconde. Ce sont des milliers de clusters. C'est à très grande échelle.
Mais il y a une nuance. Il ne réside pas sur des lecteurs réseau sophistiqués, mais sur du matériel assez simple. Et il existe un environnement de test spécifiquement pour les nouveautés intéressantes.
Et à un certain moment dans l'environnement de test, nous avons reçu un message indiquant que les invariants internes des index de la base de données avaient été violés.
Un invariant est une sorte de relation que nous espérons maintenir toujours.
Une situation très critique pour nous. Cela indique que certaines données peuvent avoir été perdues. Et la perte de données est carrément catastrophique.
L’idée générale que nous suivons dans les bases de données gérées est que même avec des efforts, il sera difficile de perdre des données. Même si vous les supprimez délibérément, vous devrez quand même ignorer leur absence pendant une longue période. La sécurité des données est une religion que nous suivons avec beaucoup de diligence.
Et voici une situation qui suggère qu’il pourrait y avoir une situation à laquelle nous ne sommes peut-être pas préparés. Et nous avons commencé à nous préparer à cette situation.
La première chose que nous avons faite a été d’enterrer les logs de ces milliers de clusters. Nous avons découvert lesquels des clusters se trouvaient sur des disques dotés d'un micrologiciel problématique et qui perdaient les mises à jour des pages de données. Marqué tout le code de données Postgres. Et nous avons marqué les messages indiquant des violations d'invariants internes avec un code conçu pour détecter la corruption des données.
Ce patch a été pratiquement accepté par la communauté sans trop de discussions, car dans chaque cas spécifique, il était évident que quelque chose de grave s'était produit et devait être signalé dans le journal.
Après cela, nous sommes arrivés au point où nous avons une surveillance qui analyse les journaux. Et en cas de messages suspects, il réveille l'officier de permanence, et l'officier de permanence le répare.
Mais! L'analyse des journaux est une opération peu coûteuse sur un cluster et extrêmement coûteuse pour un millier de clusters.
Nous avons écrit une extension appelée . Il crée une vue de la base de données dans laquelle vous pouvez sélectionner rapidement et à moindre coût des statistiques sur les erreurs passées. Et si nous devons réveiller l'officier de service, nous le découvrirons sans analyser les fichiers de plusieurs gigaoctets, mais en extrayant quelques octets de la table de hachage.
Cette extension a été adoptée, par exemple, dans le référentiel pour . Si vous souhaitez l'utiliser, vous pouvez l'installer vous-même. Bien sûr, c'est open source.
Mais ce n'est pas tout. Nous avons commencé à utiliser Amcheck, une extension créée par la communauté, pour détecter les violations invariantes dans les index.
Et nous avons découvert que si vous l’exploitez à grande échelle, il y a des bugs. Nous avons commencé à les réparer. Nos corrections ont été acceptées.
Nous avons découvert que cette extension ne peut pas analyser les index GiST & GIT. Nous leur avons apporté du soutien. Mais ce support est toujours en discussion au sein de la communauté, car il s'agit d'une fonctionnalité relativement nouvelle et elle contient de nombreux détails.
Et nous avons également découvert que lors de la vérification des index pour violations sur le leader de la réplication, sur le maître, tout fonctionne bien, mais sur les répliques, sur le suiveur, la recherche de corruption n'est pas si efficace. Tous les invariants ne sont pas vérifiés. Et un invariant nous a beaucoup gêné. Et nous avons passé un an et demi à communiquer avec la communauté afin de permettre ce contrôle sur les répliques.
Nous avons écrit du code qui devrait suivre tous les protocoles can.... Nous avons discuté de ce patch pendant un certain temps avec Peter Gaghan de Crunchy Data. Il a dû modifier légèrement le B-tree existant dans Postgres afin d'accepter ce patch. Il a été accepté. Et désormais, la vérification des index sur les répliques est également devenue suffisamment efficace pour détecter les violations que nous avons rencontrées. Autrement dit, ce sont les violations qui peuvent être causées par des erreurs dans le micrologiciel du disque, des bogues dans Postgres, des bogues dans le noyau Linux et des problèmes matériels. Une liste assez longue de sources de problèmes auxquelles nous nous préparions.
Mais outre les index, il existe une partie telle que le tas, c'est-à-dire l'endroit où les données sont stockées. Et il n’existe pas beaucoup d’invariants pouvant être vérifiés.
Nous avons une extension appelée Heapcheck. Nous avons commencé à le développer. Et en parallèle, avec nous, la société EnterpriseDB a également commencé à écrire un module, qu'ils ont appelé de la même manière Heapcheck. Seulement, nous l'avons appelé PgHeapcheck, et ils l'ont simplement appelé Heapcheck. Ils l'ont avec des fonctions similaires, une signature légèrement différente, mais avec les mêmes idées. Ils les ont mis en œuvre un peu mieux à certains endroits. Et ils l'ont déjà publié en open source.
Et maintenant nous développons leur expansion, car il ne s’agit plus de leur expansion, mais de l’expansion de la communauté. Et à l'avenir, cela fait partie du noyau qui sera fourni à chacun afin qu'il puisse être informé à l'avance des problèmes futurs.
À certains endroits, nous sommes même parvenus à la conclusion que nos systèmes de surveillance présentaient des faux positifs. Par exemple, le système 1C. Lors de l'utilisation d'une base de données, Postgres y écrit parfois des données qu'il peut lire, mais pg_dump ne peut pas les lire.
Cette situation ressemblait à une corruption de notre système de détection des problèmes. L'officier de service a été réveillé. L'officier de service a regardé ce qui se passait. Après un certain temps, un client est venu et m'a dit que j'avais des problèmes. Le préposé a expliqué quel était le problème. Mais le problème réside dans le noyau de Postgres.
J'ai trouvé une discussion sur cette fonctionnalité. Et il a écrit que nous avons rencontré cette fonctionnalité et que c'était désagréable, une personne se réveillait la nuit pour comprendre de quoi il s'agissait.
La communauté a répondu : « Oh, nous devons vraiment résoudre ce problème. »
J'ai une analogie simple. Si vous marchez dans une chaussure contenant un grain de sable, vous pouvez en principe passer à autre chose - pas de problème. Si vous vendez des bottes à des milliers de personnes, fabriquons des bottes sans sable du tout. Et si l’un des utilisateurs de vos chaussures va courir un marathon, alors vous voulez fabriquer de très bonnes chaussures, puis les adapter à tous vos utilisateurs. Et ces utilisateurs inattendus se trouvent toujours dans l’environnement cloud. Il y a toujours des utilisateurs qui exploitent le cluster de manière originale. Vous devez toujours vous y préparer.
Qu’avons-nous appris ici ? Nous avons appris une chose simple : le plus important est d'expliquer à la communauté qu'il y a un problème. Si la communauté a reconnu le problème, alors une concurrence naturelle apparaît pour résoudre le problème. Parce que tout le monde veut résoudre un problème important. Tous les fournisseurs, tous les pirates informatiques comprennent qu'ils peuvent eux-mêmes marcher sur ce râteau et veulent donc les éliminer.
Si vous travaillez sur un problème, mais que cela ne dérange personne d'autre que vous, mais que vous y travaillez systématiquement et qu'il est finalement considéré comme un problème, alors votre pull request sera définitivement acceptée. Votre patch sera accepté, vos améliorations ou même vos demandes d'améliorations seront examinées par la communauté. En fin de compte, nous améliorons la base de données les uns pour les autres.
Une base de données intéressante est Greenplum. Il s'agit d'une base de données hautement parallèle basée sur la base de code Postgres, que je connais très bien.
Et Greenplum a des fonctionnalités intéressantes : ajoutez des tableaux optimisés. Ce sont des tableaux que vous pouvez compléter rapidement. Ils peuvent être en colonnes ou en lignes.
Mais il n'y avait pas de clustering, c'est-à-dire qu'il n'y avait aucune fonctionnalité permettant d'organiser les données situées dans la table conformément à l'ordre qui se trouve dans l'un des index.
Les gars du taxi sont venus vers moi et m'ont dit : « Andrey, tu connais Postgres. Et ici, c'est presque pareil. Passez à 20 minutes. Prenez-le et faites-le. Je pensais que oui, je connais Postgres, je change pendant 20 minutes - je dois le faire.
Mais non, ce n'était pas 20 minutes, je l'ai écrit pendant des mois. Lors de la conférence PgConf.Russia, j'ai contacté Heikki Linakangas de Pivotal et lui ai demandé : « Y a-t-il des problèmes avec cela ? Pourquoi n’y a-t-il pas de clustering de table optimisé pour l’ajout ? » Il dit : « Vous prenez les données. Vous triez, vous réorganisez. C'est juste un travail." Moi : "Oh, oui, tu as juste besoin de le prendre et de le faire." Il dit : « Oui, nous avons besoin d’avoir les mains libres pour faire cela. » Je pensais que je devais absolument faire ça.
Et quelques mois plus tard, j'ai soumis une pull request qui implémentait cette fonctionnalité. Cette pull request a été examinée par Pivotal en collaboration avec la communauté. Bien sûr, il y avait des bugs.
Mais le plus intéressant est que lorsque cette pull request a été fusionnée, des bugs ont été trouvés dans Greenplum lui-même. Nous avons constaté que les tables de tas interrompent parfois la transactionnalité lorsqu'elles sont regroupées. Et c’est une chose qui doit être corrigée. Et elle est à l'endroit que je viens de toucher. Et ma réaction naturelle a été : d’accord, laisse-moi faire ça aussi.
J'ai corrigé ce bug. Envoyé une pull request aux réparateurs. Il a été tué.
Après quoi, il s'est avéré que cette fonctionnalité devait être obtenue dans la version Greenplum pour PostgreSQL 12. Autrement dit, l'aventure de 20 minutes se poursuit avec de nouvelles aventures intéressantes. Il était intéressant d'aborder le développement actuel, où la communauté supprime de nouvelles fonctionnalités les plus importantes. C'est gelé.
Mais cela ne s'est pas arrêté là. Après tout, il s’est avéré que nous devions rédiger une documentation pour tout cela.
J'ai commencé à rédiger de la documentation. Heureusement, les documentaristes de Pivotal sont venus. L'anglais est leur langue maternelle. Ils m'ont aidé avec la documentation. En fait, ils ont eux-mêmes réécrit ce que je proposais dans un anglais véritable.
Et ici, semble-t-il, l'aventure s'est terminée. Et savez-vous ce qui s'est passé ensuite ? Les gars du taxi sont venus vers moi et m'ont dit : « Il y a encore deux aventures, chacune d'une durée de 10 minutes. » Et que dois-je leur dire ? J'ai dit que maintenant je ferais un rapport à grande échelle, puis nous verrons vos aventures, car c'est un travail intéressant.
Qu’avons-nous appris de cette affaire ? Parce que travailler avec l'open source, c'est toujours travailler avec une personne spécifique, c'est toujours travailler avec la communauté. Parce qu'à chaque étape, j'ai travaillé avec un développeur, un testeur, un hacker, un documentariste, un architecte. Je n'ai pas travaillé avec Greenplum, j'ai travaillé avec des gens autour de Greenplum.
Mais! Il y a un autre point important : c’est juste du travail. Autrement dit, vous venez, buvez du café, écrivez du code. Toutes sortes d’invariants simples fonctionnent. Faites-le normalement - tout ira bien ! Et c'est un travail assez intéressant. Il y a une demande pour ce travail de la part des clients Yandex.Cloud, utilisateurs de nos clusters à la fois à l'intérieur de Yandex et à l'extérieur. Et je pense que le nombre de projets auxquels nous participons va augmenter et que la profondeur de notre implication va également augmenter.
C'est tout. Passons aux questions.
Séance de questions
Bonjour! Nous avons une autre séance de questions et réponses. Et dans le studio Andrei Borodine. C'est la personne qui vient de vous parler de la contribution de Yandex.Cloud et Yandex à l'open source. Notre rapport ne porte plus entièrement sur le Cloud, mais en même temps, nous nous basons sur de telles technologies. Sans ce que vous avez fait dans Yandex, il n'y aurait pas de service dans Yandex.Cloud, alors merci personnellement. Et la première question de l’émission : « Sur quoi est écrit chacun des projets que vous avez mentionnés ?
Le système de sauvegarde dans WAL-G est écrit en Go. C'est l'un des projets les plus récents sur lesquels nous avons travaillé. Il n'a littéralement que 3 ans. Et une base de données est souvent une question de fiabilité. Cela signifie que les bases de données sont assez anciennes et qu'elles sont généralement écrites en C. Le projet Postgres a débuté il y a environ 30 ans. Alors le C89 était le bon choix. Et Postgres est écrit dessus. Les bases de données plus modernes telles que ClickHouse sont généralement écrites en C++. Tout le développement du système est basé sur C et C++.
Une question de notre responsable financier, responsable des dépenses chez Cloud : "Pourquoi le Cloud dépense-t-il de l'argent pour soutenir l'open source ?"
Il y a ici une réponse simple pour le directeur financier. Nous faisons cela pour améliorer nos services. De quelles manières pouvons-nous faire mieux ? Nous pouvons faire les choses plus efficacement, plus rapidement et les rendre plus évolutives. Mais pour nous, cette histoire est avant tout une question de fiabilité. Par exemple, dans un système de sauvegarde, nous examinons 100 % des correctifs qui s'y appliquent. Nous savons quel est le code. Et nous sommes plus à l’aise pour déployer de nouvelles versions en production. C'est-à-dire avant tout une question de confiance, de préparation au développement et de fiabilité.
Autre question : « Les exigences des utilisateurs externes qui vivent dans Yandex.Cloud sont-elles différentes de celles des utilisateurs internes qui vivent dans le Cloud interne ?
Le profil de charge est bien entendu différent. Mais du point de vue de mon service, tous les cas particuliers et intéressants sont créés sur une charge non standard. Les développeurs qui ont de l'imagination, ceux qui font l'inattendu, sont aussi susceptibles d'être trouvés en interne qu'en externe. À cet égard, nous sommes tous à peu près pareils. Et, probablement, la seule caractéristique importante du fonctionnement des bases de données Yandex sera que nous avons un enseignement à l'intérieur de Yandex. À un moment donné, certaines zones de disponibilité tombent complètement dans l'ombre et tous les services Yandex doivent continuer à fonctionner malgré cela. C'est une petite différence. Mais cela crée beaucoup de développement de recherche à l’interface de la base de données et de la pile réseau. Sinon, les installations externes et internes génèrent les mêmes demandes de fonctionnalités et des demandes similaires d'amélioration de la fiabilité et des performances.
Question suivante : « Que pensez-vous personnellement du fait qu'une grande partie de ce que vous faites est utilisée par d'autres Cloud ? » Nous n’en citerons pas de spécifiques, mais de nombreux projets réalisés dans Yandex.Cloud sont utilisés dans les cloud d’autres personnes.
C'est cool. Premièrement, c’est le signe que nous avons fait quelque chose de bien. Et ça gratte l’ego. Et nous sommes plus sûrs d’avoir pris la bonne décision. D'un autre côté, on espère qu'à l'avenir cela nous apportera de nouvelles idées, de nouvelles demandes d'utilisateurs tiers. La plupart des problèmes sur GitHub sont créés par des administrateurs système individuels, des administrateurs de base de données individuels, des architectes individuels, des ingénieurs individuels, mais parfois des personnes ayant une expérience systématique viennent dire que dans 30 % des cas, nous avons ce problème et réfléchissons à la manière de le résoudre. C’est ce que nous attendons le plus. Nous sommes impatients de partager nos expériences avec d'autres plateformes cloud.
Vous avez beaucoup parlé du marathon. Je sais que tu as couru un marathon à Moscou. Par conséquent? Vous avez dépassé les gars de PostgreSQL ?
Non, Oleg Bartunov court très vite. Il a fini une heure avant moi. Dans l’ensemble, je suis satisfait du chemin parcouru. Pour moi, le simple fait de terminer était un exploit. Dans l'ensemble, il est surprenant qu'il y ait autant de coureurs dans la communauté postgres. Il me semble qu'il existe une sorte de relation entre les sports aérobiques et le désir de programmation systémique.
Êtes-vous en train de dire qu’il n’y a pas de coureurs chez ClickHouse ?
Je sais avec certitude qu'ils sont là. ClickHouse est également une base de données. D’ailleurs, Oleg m’écrit maintenant : « On va courir après le rapport ? C'est une bonne idée.
Autre question de l'émission de Nikita : « Pourquoi avez-vous corrigé vous-même le bug de Greenplum et ne l'avez-vous pas donné aux juniors ? Certes, on ne sait pas très clairement quel est le bug et dans quel service, mais il s'agit probablement de celui dont vous avez parlé.
Oui, en principe, il aurait pu être donné à quelqu'un. C'était juste le code que je viens de changer. Et c’était naturel de continuer à le faire tout de suite. En principe, l’idée de partager une expertise avec l’équipe est une bonne idée. Nous partagerons certainement les tâches de Greenplum entre tous les membres de notre division.
Puisque nous parlons des juniors, voici une question. La personne a décidé de créer le premier commit dans Postgres. Que doit-il faire pour effectuer le premier commit ?
C’est une question intéressante : « Par où commencer ? Il est généralement assez difficile de démarrer avec quelque chose dans le noyau. Dans Postgres, par exemple, il existe une liste de tâches. Mais en fait, c’est une feuille de ce qu’ils ont essayé de faire, mais sans succès. Ce sont des choses compliquées. Et généralement, vous pouvez trouver des utilitaires dans l'écosystème, des extensions qui peuvent être améliorées, qui attirent moins l'attention des développeurs du noyau. Et, par conséquent, il y a plus de points de croissance là-bas. Lors du programme Google Summer of code, la communauté postgres propose chaque année de nombreux sujets différents qui pourraient être abordés. Cette année, nous avions, je pense, trois étudiants. L'un d'entre eux a même écrit dans WAL-G sur des sujets importants pour Yandex. Dans Greenplum, tout est plus simple que dans la communauté Postgres, car les hackers de Greenplum traitent très bien les pull request et commencent immédiatement à les examiner. Envoyer un patch à Postgres n'est qu'une question de mois, mais Greenplum viendra dans un jour et verra ce que vous avez fait. Une autre chose est que Greenplum doit résoudre les problèmes actuels. Greenplum n’est pas largement utilisé, il est donc assez difficile de trouver votre problème. Et avant tout, nous devons bien sûr résoudre les problèmes.
Source: habr.com