Robot DBA Joe. Anatoly Stansler (Postgres.ai)

Comment un développeur backend comprend-il qu'une requête SQL fonctionnera bien sur une "prod" ? Dans les grandes entreprises ou en croissance rapide, tout le monde n'a pas accès au "produit". Et avec l'accès, toutes les demandes ne peuvent pas être vérifiées sans douleur, et la création d'une copie de la base de données prend souvent des heures. Pour résoudre ces problèmes, nous avons créé un DBA artificiel - Joe. Il a déjà été implémenté avec succès dans plusieurs entreprises et aide plus d'une dizaine de développeurs.

Vidéo:

Salut tout le monde! Je m'appelle Anatoly Stansler. je travaille pour une entreprise postgres.ai. Nous nous engageons à accélérer le processus de développement en supprimant les retards associés au travail de Postgres des développeurs, des DBA et des QA.

Nous avons d'excellents clients et aujourd'hui, une partie du rapport sera consacrée à des cas que nous avons rencontrés en travaillant avec eux. Je vais parler de la façon dont nous les avons aidés à résoudre des problèmes assez graves.

Lorsque nous développons et effectuons des migrations complexes à forte charge, nous nous posons la question : « Cette migration va-t-elle décoller ? ». Nous utilisons l'examen, nous utilisons les connaissances de collègues plus expérimentés, des experts DBA. Et ils peuvent dire s'il volera ou non.

Mais peut-être serait-il préférable que nous puissions le tester nous-mêmes sur des copies grandeur nature. Et aujourd'hui, nous allons simplement parler des approches actuelles des tests, de la manière dont cela peut être amélioré et avec quels outils. Nous parlerons également des avantages et des inconvénients de telles approches, et de ce que nous pouvons corriger ici.

Qui a déjà fait des index directement sur prod ou apporté des modifications ? Un peu de. Et pour qui cela a-t-il conduit au fait que des données ont été perdues ou qu'il y a eu des temps d'arrêt ? Alors vous connaissez cette douleur. Dieu merci, il y a des sauvegardes.

La première approche est le test en prod. Ou, lorsqu'un développeur est assis sur une machine locale, il a des données de test, il y a une sorte de sélection limitée. Et nous déployons la production, et nous obtenons cette situation.

Ça fait mal, c'est cher. C'est probablement mieux de ne pas le faire.

Et quelle est la meilleure façon de le faire ?

Prenons la mise en scène et sélectionnons une partie de la production là-bas. Ou au mieux, prenons une vraie prod, toutes les données. Et après l'avoir développé localement, nous vérifierons également la mise en scène.

Cela nous permettra de supprimer certaines des erreurs, c'est-à-dire de les empêcher d'être en prod.

Quels sont les problèmes?

• Le problème, c'est qu'on partage cette mise en scène avec des collègues. Et très souvent, il arrive que vous fassiez une sorte de changement, bam - et il n'y a pas de données, le travail est à l'eau. La mise en scène était de plusieurs téraoctets. Et il faut attendre longtemps pour qu'il remonte. Et nous décidons de le finaliser demain. Ça y est, nous avons un développement.
• Et, bien sûr, nous avons de nombreux collègues qui y travaillent, de nombreuses équipes. Et il faut le faire manuellement. Et c'est gênant.

Et cela vaut la peine de dire que nous n'avons qu'une seule tentative, un seul coup, si nous voulons apporter des modifications à la base de données, toucher les données, modifier la structure. Et si quelque chose n'allait pas, s'il y avait une erreur dans la migration, nous ne reculerions pas rapidement.

C'est mieux que l'approche précédente, mais il y a toujours une forte probabilité qu'une sorte d'erreur aille à la production.

Qu'est-ce qui nous empêche de donner à chaque développeur un banc de test, une copie grandeur nature ? Je pense que ce qui gêne est clair.

Qui a une base de données supérieure à un téraoctet ? Plus de la moitié de la pièce.

Et force est de constater que garder des machines pour chaque développeur, lorsqu'il y a une production aussi importante, coûte très cher, et en plus, cela prend beaucoup de temps.

Nous avons des clients qui ont réalisé qu'il est très important de tester toutes les modifications sur des copies pleine taille, mais leur base de données est inférieure à un téraoctet et il n'y a pas de ressources pour conserver un banc de test pour chaque développeur. Par conséquent, ils doivent télécharger les vidages localement sur leur machine et tester de cette manière. Ça prend beaucoup de temps.

Même si vous le faites à l'intérieur de l'infrastructure, télécharger un téraoctet de données par heure est déjà très bon. Mais ils utilisent des dumps logiques, qu'ils téléchargent localement depuis le cloud. Pour eux, la vitesse est d'environ 200 gigaoctets par heure. Et il faut encore du temps pour faire demi-tour depuis le vidage logique, remonter les index, etc.

Mais ils utilisent cette approche car cela leur permet de garder la production fiable.

Que pouvons-nous faire ici ? Faisons des bancs de test bon marché et donnons à chaque développeur son propre banc de test.

Et c'est possible.

Et dans cette approche, lorsque nous créons des clones légers pour chaque développeur, nous pouvons le partager sur une seule machine. Par exemple, si vous avez une base de données de 10 To et que vous souhaitez la donner à 10 développeurs, vous n'avez pas besoin d'avoir XNUMX bases de données de XNUMX To. Vous n'avez besoin que d'une seule machine pour faire des copies minces isolées pour chaque développeur utilisant une seule machine. Je vous dirai comment ça marche un peu plus tard.

Exemple réel :

• DB - 4,5 téraoctets.

• Nous pouvons obtenir des copies indépendantes en 30 secondes.

Vous n'avez pas à attendre un banc d'essai et dépendez de sa taille. Vous pouvez l'obtenir en quelques secondes. Il s'agira d'environnements complètement isolés, mais qui partagent des données entre eux.

C'est bien. On parle ici de magie et d'univers parallèle.

Dans notre cas, cela fonctionne en utilisant le système OpenZFS.

OpenZFS est un système de fichiers de copie sur écriture qui prend en charge les instantanés et les clones prêts à l'emploi. Il est fiable et évolutif. Elle est très facile à gérer. Il peut littéralement être déployé en deux équipes.

Il existe d'autres options :

• lvm,

• Stockage (par exemple, Pure Storage).

Le Database Lab dont je parle est modulaire. Peut être mis en œuvre à l'aide de ces options. Mais pour l'instant, nous nous sommes concentrés sur OpenZFS, car il y avait des problèmes avec LVM spécifiquement.

Comment ça fonctionne? Au lieu d'écraser les données à chaque fois que nous les modifions, nous les sauvegardons en marquant simplement que ces nouvelles données proviennent d'un nouveau point dans le temps, d'un nouvel instantané.

Et à l'avenir, lorsque nous voulons revenir en arrière ou créer un nouveau clone à partir d'une version plus ancienne, nous disons simplement : "OK, donnez-nous ces blocs de données qui sont marqués comme ceci."

Et cet utilisateur travaillera avec un tel ensemble de données. Il va progressivement les modifier, faire ses propres clichés.

Et nous allons ramifier. Chaque développeur dans notre cas aura la possibilité d'avoir son propre clone qu'il édite, et les données qui sont partagées seront partagées entre tout le monde.

Pour déployer un tel système chez vous, vous devez résoudre deux problèmes :

• Le premier est la source des données, d'où vous les prendrez. Vous pouvez configurer la réplication avec la production. Vous pouvez déjà utiliser les sauvegardes que vous avez configurées, j'espère. WAL-E, WAL-G ou Barman. Et même si vous utilisez une sorte de solution Cloud comme RDS ou Cloud SQL, vous pouvez utiliser des vidages logiques. Mais nous vous conseillons toujours d'utiliser des sauvegardes, car avec cette approche, vous conserverez également la structure physique des fichiers, ce qui vous permettra d'être encore plus proche des métriques que vous verriez en production afin de détecter les problèmes qui existent.

• Le second est l'endroit où vous souhaitez héberger le Database Lab. Cela pourrait être Cloud, cela pourrait être sur site. Il est important de dire ici que ZFS prend en charge la compression des données. Et ça le fait plutôt bien.

Imaginez que pour chacun de ces clones, en fonction des opérations que nous effectuons avec la base, une sorte de développement se développera. Pour cela, dev aura également besoin d'espace. Mais du fait que nous avons pris une base de 4,5 téraoctets, ZFS va la compresser à 3,5 téraoctets. Cela peut varier en fonction des paramètres. Et nous avons encore de la place pour le développement.

Un tel système peut être utilisé pour différents cas.

• Ce sont des développeurs, des DBA pour la validation des requêtes, pour l'optimisation.

• Cela peut être utilisé dans les tests d'assurance qualité pour tester une migration particulière avant de la déployer en production. Et nous pouvons également créer des environnements spéciaux pour l'assurance qualité avec des données réelles, où ils peuvent tester de nouvelles fonctionnalités. Et cela prendra des secondes au lieu d'attendre des heures, et peut-être des jours dans certains autres cas où les copies minces ne sont pas utilisées.

• Et un autre cas. Si l'entreprise n'a pas mis en place de système d'analyse, nous pouvons isoler un clone léger de la base de produits et l'attribuer à de longues requêtes ou à des index spéciaux pouvant être utilisés dans l'analyse.

Avec cette approche :

1. Faible probabilité d'erreurs sur la "prod", car nous avons testé toutes les modifications sur des données en taille réelle.

2. Nous avons une culture de test, car maintenant vous n'avez plus à attendre des heures pour votre propre stand.

3. Et il n'y a pas de barrière, pas d'attente entre les tests. Vous pouvez effectivement aller vérifier. Et ce sera mieux ainsi à mesure que nous accélérons le développement.

• Il y aura moins de refactoring. Moins de bugs se retrouveront en prod. Nous les refactoriserons moins par la suite.

• Nous pouvons inverser des changements irréversibles. Ce n'est pas l'approche standard.

1. Ceci est bénéfique car nous partageons les ressources des bancs d'essais.

Déjà bon, mais quoi d'autre pourrait être accéléré ?

Grâce à un tel système, nous pouvons réduire considérablement le seuil d'entrée dans de tels tests.

Il y a maintenant un cercle vicieux où un développeur, pour avoir accès à des données réelles en taille réelle, doit devenir un expert. Il doit être digne de confiance avec un tel accès.

Mais comment grandir si ce n'est pas là. Mais que se passe-t-il si vous ne disposez que d'un très petit ensemble de données de test ? Ensuite, vous n'obtiendrez aucune expérience réelle.

Comment sortir de ce cercle ? Comme première interface, pratique pour les développeurs de tout niveau, nous avons choisi le bot Slack. Mais cela peut être n'importe quelle autre interface.

Qu'est-ce qu'il vous permet de faire ? Vous pouvez prendre une requête spécifique et l'envoyer à un canal spécial pour la base de données. Nous déploierons automatiquement un clone léger en quelques secondes. Exécutons cette requête. Nous recueillons des métriques et des recommandations. Montrons une visualisation. Et puis ce clone restera pour que cette requête puisse être en quelque sorte optimisée, ajouter des index, etc.

Et Slack nous offre également des opportunités de collaboration prêtes à l'emploi. Puisqu'il ne s'agit que d'un canal, vous pouvez commencer à discuter de cette demande directement dans le fil de discussion d'une telle demande, envoyer un ping à vos collègues, DBA qui sont à l'intérieur de l'entreprise.

Mais il y a bien sûr des problèmes. Parce que c'est le monde réel et que nous utilisons un serveur hébergeant plusieurs clones à la fois, nous devons compresser la quantité de mémoire et de puissance CPU disponible pour les clones.

Mais pour que ces tests soient plausibles, vous devez résoudre ce problème d'une manière ou d'une autre.

Il est clair que le point important est les mêmes données. Mais nous l'avons déjà. Et nous voulons réaliser la même configuration. Et nous pouvons donner une telle configuration presque identique.

Ce serait cool d'avoir le même matériel qu'en production, mais cela peut différer.

Rappelons-nous comment Postgres fonctionne avec la mémoire. Nous avons deux caches. Un du système de fichiers et un Postgres natif, c'est-à-dire le cache de tampon partagé.

Il est important de noter que le cache de tampon partagé est alloué au démarrage de Postgres, en fonction de la taille que vous spécifiez dans la configuration.

Et le deuxième cache utilise tout l'espace disponible.

Et quand on fait plusieurs clones sur une même machine, il s'avère qu'on remplit peu à peu la mémoire. Et dans le bon sens, le cache de tampon partagé représente 25 % de la quantité totale de mémoire disponible sur la machine.

Et il s'avère que si nous ne modifions pas ce paramètre, nous ne pourrons exécuter que 4 instances sur une machine, c'est-à-dire 4 de tous ces clones légers. Et cela, bien sûr, est mauvais, car nous voulons en avoir beaucoup plus.

Mais d'un autre côté, Buffer Cache est utilisé pour exécuter des requêtes pour les index, c'est-à-dire que le plan dépend de la taille de nos caches. Et si nous prenons simplement ce paramètre et le réduisons, alors nos plans peuvent beaucoup changer.

Par exemple, si nous avons un grand cache sur prod, alors Postgres préférera utiliser un index. Et sinon, il y aura SeqScan. Et à quoi bon si nos plans ne coïncidaient pas ?

Mais ici, nous arrivons à la conclusion qu'en fait le plan dans Postgres ne dépend pas de la taille spécifique spécifiée dans le Shared Buffer dans le plan, cela dépend de effective_cache_size.

Effective_cache_size est la quantité estimée de cache qui nous est disponible, c'est-à-dire la somme du cache de tampon et du cache du système de fichiers. Ceci est défini par la configuration. Et cette mémoire n'est pas allouée.

Et grâce à ce paramètre, nous pouvons en quelque sorte tromper Postgres, en disant que nous avons en fait beaucoup de données disponibles, même si nous n'avons pas ces données. Et ainsi, les plans coïncideront complètement avec la production.

Mais cela peut affecter le timing. Et nous optimisons les requêtes en fonction du timing, mais il est important que le timing dépende de nombreux facteurs :

• Cela dépend de la charge qui est actuellement en prod.

• Cela dépend des caractéristiques de la machine elle-même.

Et c'est un paramètre indirect, mais en fait on peut optimiser exactement par la quantité de données que cette requête va lire pour obtenir le résultat.

Et si vous voulez que le timing soit proche de ce que nous verrons en prod, alors nous devons prendre le matériel le plus similaire et, éventuellement, encore plus pour que tous les clones s'adaptent. Mais c'est un compromis, c'est-à-dire que vous obtiendrez les mêmes plans, vous verrez combien de données une requête particulière lira et vous pourrez conclure si cette requête est bonne (ou migration) ou mauvaise, elle doit encore être optimisée .

Voyons comment Joe est spécifiquement optimisé.

Prenons une demande d'un système réel. Dans ce cas, la base de données est de 1 téraoctet. Et nous voulons compter le nombre de nouvelles publications qui ont eu plus de 10 likes.

Nous écrivons un message à la chaîne, un clone a été déployé pour nous. Et nous verrons qu'une telle demande se terminera en 2,5 minutes. C'est la première chose que nous remarquons.

B Joe vous montrera des recommandations automatiques basées sur le plan et les métriques.

Nous verrons que la requête traite trop de données pour obtenir un nombre de lignes relativement faible. Et une sorte d'index spécialisé est nécessaire, car nous avons remarqué qu'il y avait trop de lignes filtrées dans la requête.

Regardons de plus près ce qui s'est passé. En effet, nous constatons que nous avons lu près d'un gigaoctet et demi de données depuis le cache de fichiers ou même depuis le disque. Et ce n'est pas bon, car nous n'avons que 142 lignes.

Et, semble-t-il, nous avons une analyse d'index ici et aurait dû fonctionner rapidement, mais comme nous avons filtré trop de lignes (nous avons dû les compter), la demande a lentement fonctionné.

Et cela s'est produit dans le plan en raison du fait que les conditions de la requête et les conditions de l'index ne correspondent pas partiellement.

Essayons de rendre l'index plus précis et voyons comment l'exécution de la requête change par la suite.

La création de l'index a pris beaucoup de temps, mais maintenant nous vérifions la requête et voyons que le temps au lieu de 2,5 minutes n'est que de 156 millisecondes, ce qui est assez bon. Et nous ne lisons que 6 mégaoctets de données.

Et maintenant, nous n'utilisons que l'analyse d'index.

Une autre histoire importante est que nous voulons présenter le plan d'une manière plus compréhensible. Nous avons implémenté la visualisation à l'aide de Flame Graphs.

C'est une demande différente, plus intense. Et nous construisons des Flame Graphs selon deux paramètres : il s'agit de la quantité de données qu'un nœud particulier a compté dans le plan et le timing, c'est-à-dire le temps d'exécution du nœud.

Ici, nous pouvons comparer des nœuds spécifiques les uns avec les autres. Et il sera clair lequel d'entre eux prend plus ou moins, ce qui est généralement difficile à faire dans d'autres méthodes de rendu.

Bien sûr, tout le monde connaît expliquer.depesz.com. Une bonne caractéristique de cette visualisation est que nous sauvegardons le plan de texte et mettons également quelques paramètres de base dans un tableau afin que nous puissions trier.

Et les développeurs qui n'ont pas encore approfondi ce sujet utilisent également expliquer.depesz.com, car il leur est plus facile de déterminer quelles mesures sont importantes et lesquelles ne le sont pas.

Il existe une nouvelle approche de la visualisation - il s'agit d'expliquer.dalibo.com. Ils font une visualisation arborescente, mais il est très difficile de comparer les nœuds entre eux. Ici, vous pouvez bien comprendre la structure, cependant, s'il y a une demande importante, vous devrez alors faire défiler d'avant en arrière, mais aussi une option.

Коллаборация

Et, comme je l'ai dit, Slack nous donne l'opportunité de collaborer. Par exemple, si nous rencontrons une requête complexe qui ne précise pas comment optimiser, nous pouvons clarifier ce problème avec nos collègues dans un fil de discussion dans Slack.

Il nous semble qu'il est important de tester sur des données grandeur nature. Pour ce faire, nous avons créé l'outil Update Database Lab, qui est disponible en open source. Vous pouvez également utiliser le bot Joe. Vous pouvez le prendre dès maintenant et le mettre en œuvre chez vous. Tous les guides y sont disponibles.

Il est également important de noter que la solution elle-même n'est pas révolutionnaire, car il y a Delphix, mais c'est une solution d'entreprise. C'est complètement fermé, c'est très cher. Nous sommes spécifiquement spécialisés dans Postgres. Ce sont tous des produits open source. Rejoignez-nous!

C'est là que je termine. Merci!

des questions

Bonjour! Merci pour le rapport ! Très intéressant, surtout pour moi, car j'ai résolu à peu près le même problème il y a quelque temps. Et donc j'ai plusieurs questions. J'espère en avoir au moins une partie.

Je me demande comment vous calculez la place pour cet environnement? La technologie signifie que dans certaines circonstances, vos clones peuvent atteindre la taille maximale. En gros, si vous disposez d'une base de données de dix téraoctets et de 10 clones, il est facile de simuler une situation dans laquelle chaque clone pèse 10 données uniques. Comment calculez-vous cet endroit, c'est-à-dire ce delta dont vous parliez, dans lequel vivront ces clones ?

Bonne question. Il est important de garder une trace des clones spécifiques ici. Et si un clone a un changement trop important, il commence à se développer, alors nous pouvons d'abord émettre un avertissement à l'utilisateur à ce sujet, ou arrêter immédiatement ce clone afin que nous n'ayons pas de situation d'échec.

Oui, j'ai une question imbriquée. Autrement dit, comment assurez-vous le cycle de vie de ces modules ? Nous avons ce problème et une toute autre histoire. Comment cela peut-il arriver?

Il y a du ttl pour chaque clone. Fondamentalement, nous avons un ttl fixe.

Quoi, sinon un secret?

1 heure, c'est-à-dire inactif - 1 heure. S'il n'est pas utilisé, alors nous le frappons. Mais il n'y a pas de surprise ici, puisque nous pouvons élever le clone en quelques secondes. Et si vous en avez besoin à nouveau, alors s'il vous plaît.

Je m'intéresse également au choix des technologies, car, par exemple, nous utilisons plusieurs méthodes en parallèle pour une raison ou une autre. Pourquoi ZFS ? Pourquoi n'as-tu pas utilisé LVM ? Vous avez mentionné qu'il y avait des problèmes avec LVM. Quels étaient les problèmes ? À mon avis, l'option la plus optimale est avec le stockage, en termes de performances.

Quel est le principal problème avec ZFS ? Le fait que vous devez exécuter sur le même hôte, c'est-à-dire que toutes les instances vivront dans le même système d'exploitation. Et dans le cas du stockage, vous pouvez connecter différents équipements. Et le goulot d'étranglement n'est que les blocs qui se trouvent sur le système de stockage. Et la question du choix des technologies est intéressante. Pourquoi pas LVM ?

Plus précisément, nous pouvons discuter de LVM lors d'une rencontre. À propos du stockage - c'est juste cher. Nous pouvons implémenter le système ZFS n'importe où. Vous pouvez le déployer sur votre machine. Vous pouvez simplement télécharger le référentiel et le déployer. ZFS est installé presque partout si nous parlons de Linux. Autrement dit, nous obtenons une solution très flexible. Et ZFS lui-même donne beaucoup de résultats. Vous pouvez télécharger autant de données que vous le souhaitez, connecter un grand nombre de disques, il y a des instantanés. Et, comme je l'ai dit, c'est facile à administrer. C'est-à-dire qu'il semble très agréable à utiliser. Il est testé, il a de nombreuses années. Il a une très grande communauté qui grandit. ZFS est une solution très fiable.

Nikolai Samokhvalov : Puis-je commenter davantage ? Je m'appelle Nikolay, nous travaillons avec Anatoly. Je suis d'accord que le stockage est grand. Et certains de nos clients ont Pure Storage, etc.

Anatoly a correctement noté que nous nous concentrons sur la modularité. Et à l'avenir, vous pourrez implémenter une interface - prendre un instantané, créer un clone, détruire le clone. Tout est facile. Et le stockage est cool, si c'est le cas.

Mais ZFS est accessible à tous. DelPhix est déjà suffisant, ils ont 300 clients. Parmi ceux-ci, Fortune 100 compte 50 clients, c'est-à-dire qu'ils sont destinés à la NASA, etc. Il est temps que tout le monde se procure cette technologie. Et c'est pourquoi nous avons un noyau open source. Nous avons une partie interface qui n'est pas open source. C'est la plate-forme que nous allons montrer. Mais nous voulons qu'il soit accessible à tous. Nous voulons faire une révolution pour que tous les testeurs arrêtent de deviner sur les ordinateurs portables. Nous devons écrire SELECT et voir immédiatement que c'est lent. N'attendez plus que le DBA vous en parle. Voici l'objectif principal. Et je pense que nous y viendrons tous. Et nous faisons cette chose pour que tout le monde l'ait. Donc ZFS, car il sera disponible partout. Merci à la communauté d'avoir résolu les problèmes et d'avoir une licence open source, etc.*

Salutations! Merci pour le rapport ! Je m'appelle Maxime. Nous avons traité les mêmes problèmes. Ils ont décidé par eux-mêmes. Comment partagez-vous les ressources entre ces clones ? Chaque clone peut faire sa propre chose à un moment donné : l'un teste une chose, l'autre une autre, quelqu'un construit un index, quelqu'un a un gros travail. Et si vous pouvez toujours diviser par CPU, puis par IO, comment divisez-vous ? C'est la première question.

Et la deuxième question porte sur la dissemblance des stands. Disons que j'ai ZFS ici et que tout va bien, mais le client sur prod n'a pas ZFS, mais ext4, par exemple. Comment dans ce cas ?

Les questions sont très bonnes. J'ai mentionné un peu ce problème avec le fait qu'on partage les ressources. Et la solution est la suivante. Imaginez que vous testez sur la mise en scène. Vous pouvez également avoir une telle situation en même temps que quelqu'un donne une charge, quelqu'un d'autre. Et par conséquent, vous voyez des métriques incompréhensibles. Même le même problème peut être avec prod. Lorsque vous voulez vérifier une demande et que vous voyez qu'il y a un problème avec elle - cela fonctionne lentement, alors en fait le problème n'était pas dans la demande, mais dans le fait qu'il y a une sorte de charge parallèle.

Et par conséquent, il est important ici de se concentrer sur ce que sera le plan, quelles mesures nous prendrons dans le plan et combien de données nous collecterons pour cela. Le fait que nos disques, par exemple, soient chargés avec quelque chose, cela affectera spécifiquement le timing. Mais nous pouvons estimer la charge de cette requête par la quantité de données. Il n'est pas si important qu'en même temps il y ait une sorte d'exécution.

J'ai deux questions. C'est un truc très cool. Y a-t-il eu des cas où les données de production sont critiques, comme les numéros de carte de crédit ? Y a-t-il déjà quelque chose de prêt ou s'agit-il d'une tâche distincte ? Et la deuxième question - y a-t-il quelque chose comme ça pour MySQL ?

À propos des données. Nous ferons de l'obscurcissement jusqu'à ce que nous le fassions. Mais si vous déployez exactement Joe, si vous ne donnez pas accès aux développeurs, il n'y a pas d'accès aux données. Pourquoi? Parce que Joe ne montre pas de données. Il ne montre que les métriques, les plans et c'est tout. Cela a été fait exprès, car c'est l'une des exigences de notre client. Ils voulaient pouvoir optimiser sans donner l'accès à tout le monde.

À propos de MySQL. Ce système peut être utilisé pour tout ce qui stocke l'état sur disque. Et puisque nous faisons Postgres, nous faisons maintenant toute l'automatisation pour Postgres en premier. Nous voulons automatiser l'obtention de données à partir d'une sauvegarde. Nous configurons Postgres correctement. Nous savons comment faire correspondre les plans, etc.

Mais comme le système est extensible, il peut également être utilisé pour MySQL. Et il y a de tels exemples. Yandex a une chose similaire, mais ils ne la publient nulle part. Ils l'utilisent dans Yandex.Metrica. Et il y a juste une histoire à propos de MySQL. Mais les technologies sont les mêmes, ZFS.

Merci pour le rapport ! J'ai aussi quelques questions. Vous avez mentionné que le clonage peut être utilisé pour l'analyse, par exemple pour y créer des index supplémentaires. Pouvez-vous en dire un peu plus sur son fonctionnement ?

Et je vais tout de suite poser la deuxième question sur la similarité des stands, la similarité des plans. Le plan dépend également des statistiques collectées par Postgres. Comment pouvez-vous résoudre ce problème?

Selon les analyses, il n'y a pas de cas spécifiques, car nous ne l'avons pas encore utilisé, mais il existe une telle opportunité. Si nous parlons d'index, imaginez qu'une requête recherche une table avec des centaines de millions d'enregistrements et une colonne qui n'est généralement pas indexée dans prod. Et nous voulons y calculer certaines données. Si cette requête est envoyée à prod, il est possible que ce soit simple sur prod, car la requête y sera traitée pendant une minute.

Ok, faisons un clone fin qui n'est pas terrible à arrêter quelques minutes. Et afin de rendre la lecture des analyses plus confortable, nous ajouterons des indices pour les colonnes dans lesquelles nous nous intéressons aux données.

L'index sera créé à chaque fois ?

Vous pouvez faire en sorte que nous touchions les données, que nous fassions des instantanés, puis nous récupérerons de cet instantané et générerons de nouvelles requêtes. Autrement dit, vous pouvez faire en sorte que vous puissiez élever de nouveaux clones avec des indices déjà apposés.

Quant à la question sur les statistiques, si nous restaurons à partir d'une sauvegarde, si nous faisons de la réplication, alors nos statistiques seront exactement les mêmes. Parce que nous avons toute la structure physique des données, c'est-à-dire que nous apporterons également les données telles qu'elles sont avec toutes les mesures statistiques.

Voici un autre problème. Si vous utilisez une solution cloud, seuls les vidages logiques y sont disponibles, car Google, Amazon ne vous autorisent pas à prendre une copie physique. Il y aura un problème.

Merci pour le rapport. Il y avait deux bonnes questions ici sur MySQL et le partage des ressources. Mais, en fait, tout se résume au fait qu'il ne s'agit pas d'un sujet de SGBD spécifique, mais du système de fichiers dans son ensemble. Et, en conséquence, les problèmes de partage des ressources devraient également être résolus à partir de là, non pas à la fin qu'il s'agisse de Postgres, mais dans le système de fichiers, dans le serveur, par exemple.

Ma question est un peu différente. Il est plus proche de la base de données multicouche, où il y a plusieurs couches. Par exemple, nous avons mis en place une mise à jour d'image de dix téraoctets, nous répliquons. Et nous utilisons spécifiquement cette solution pour les bases de données. La réplication est en cours, les données sont mises à jour. Ce sont 100 salariés qui travaillent en parallèle ici, qui lancent en permanence ces différents plans. Ce qu'il faut faire? Comment s'assurer qu'il n'y a pas de conflit, qu'ils en ont lancé un, puis que le système de fichiers a changé, et que ces images ont toutes disparu ?

Ils n'iront pas parce que c'est ainsi que fonctionne ZFS. Nous pouvons conserver séparément dans un thread les modifications du système de fichiers dues à la réplication. Et conservez les clones que les développeurs utilisent sur les anciennes versions des données. Et ça marche pour nous, tout est en ordre avec ça.

Il s'avère que la mise à jour aura lieu en tant que couche supplémentaire, et toutes les nouvelles images iront déjà, sur la base de cette couche, n'est-ce pas ?

Des couches précédentes qui provenaient de réplications précédentes.

Les calques précédents tomberont, mais ils feront référence à l'ancien calque et prendront-ils de nouvelles images du dernier calque reçu dans la mise à jour ?

En général oui.

Ensuite, par conséquent, nous aurons jusqu'à une figue de couches. Et avec le temps, il faudra les compresser ?

Oui tout est correct. Il y a une fenêtre. Nous gardons des instantanés hebdomadaires. Cela dépend de la ressource dont vous disposez. Si vous avez la possibilité de stocker beaucoup de données, vous pouvez stocker des instantanés pendant une longue période. Ils ne partiront pas d'eux-mêmes. Il n'y aura pas de corruption de données. Si les instantanés sont obsolètes, comme il nous semble, c'est-à-dire que cela dépend de la politique de l'entreprise, nous pouvons simplement les supprimer et libérer de l'espace.

Bonjour, merci pour le rapport ! Question sur Jo. Vous avez dit que le client ne voulait pas que tout le monde ait accès aux données. Strictement parlant, si une personne a le résultat d'Expliquer Analyser, alors elle peut lire les données.

C'est comme ça. Par exemple, on peut écrire : "SELECT FROM WHERE email = to that". Autrement dit, nous ne verrons pas les données elles-mêmes, mais nous pouvons voir des signes indirects. Cela doit être compris. Mais d'un autre côté, tout y est. Nous avons un audit des logs, nous avons le contrôle d'autres collègues qui voient aussi ce que font les développeurs. Et si quelqu'un essaie de le faire, le service de sécurité viendra vers lui et travaillera sur ce problème.

Bon après-midi Merci pour le rapport ! J'ai une petite question. Si l'entreprise n'utilise pas Slack, y a-t-il maintenant un lien avec Slack, ou est-il possible pour les développeurs de déployer des instances afin de connecter une application de test aux bases de données ?

Maintenant, il y a un lien vers Slack, c'est-à-dire qu'il n'y a pas d'autre messager, mais je veux vraiment prendre en charge d'autres messagers aussi. Que pouvez-vous faire? Vous pouvez déployer DB Lab sans Joe, aller avec l'aide de l'API REST ou avec l'aide de notre plateforme et créer des clones et vous connecter avec PSQL. Mais cela peut se faire si vous êtes prêt à donner accès aux données à vos développeurs, car il n'y aura plus d'écran.

Je n'ai pas besoin de cette couche, mais j'ai besoin d'une telle opportunité.

Alors oui, c'est faisable.

Source: habr.com