Get best of the week

Qu'advient-il de la popularité de MySQL et PostgreSQL? Discussion Mitap

Le 24 avril, nous avons hébergé le mitap en ligne MySQL @ Scale sur les problèmes d'évolutivité de MySQL . Des intervenants d'Avito, Badoo et ECOMMPAY ont participé: Andrey Aksenov (auteur de Sphinx, leader de l'infrastructure de recherche), Evgeny Kuzovlev (CIO ECOMMPAY), Vladimir Fedorkov (expert MySQL / DBA en ECOMMPAY) et Nikolai Korolev (expert MySQL / DBA en Badoo).

Mitap est sorti longtemps, nous avons donc décidé de le publier en parties et de commencer par la fin - avec une discussion très intéressante à notre avis sur la popularité de MySQL et PostgreSQL, les raisons de la popularité de PostgreSQL, ORM, l'inadéquation de l'impédance, les indices fractals, la colère, le déni, la négociation et la mise en place de l'aspirateur automatique et d'autres problèmes de choix d'un SGBD par les développeurs de livres d'or sur NodeJS. Attention! Il n'y a pas de vocabulaire très censuré, un certain nombre de généralisations incorrectes ont été remplacées, et toutes les coïncidences sont aléatoires et en aucun cas de nature offensante.

Alexey Rybak : Prenez MySQL vs PostgreSQL, pas seulement un holivar, mais une chose assez mesurable et visible. Il y a des analyses, je n'ai pas regardé qu'un seul indicateur. Maintenant, je me souviens de deux choses dans ma tête. Nous avons un groupe Facebook sur la gestion et le développement de grands projets. Il y a plusieurs milliers de personnes. J'ai fait un sondage sur PostgreSQL ou MySQL, y compris qui est le cloud, les utilisations non-cloud, car c'est aussi un sujet tellement nouveau, très chaud ces dernières années.

Et il s'est avéré que Postgres est (légèrement) en avance sur MySQL, et pour moi, c'était essentiellement une sorte de nouvelle histoire, car il semblait que la proportion devrait être différente. Et il y a des sondages qui sont menés lors des conférences HighLoad, ils ont été publiés. Je n'ai pas de comparaison systématique simple d'année en année, mais cela a clairement montré que Postgres à un moment donné sur le nombre de réponses à la question "quelle est votre base de données principale" a rattrapé et dépassé MySQL.

J'ai eu une conversation avec Petya Zaitsev. Il y a assez longtemps, il y a peut-être deux ans, il est venu à Moscou. Ce sont essentiellement toutes les pensées de Petya. Les réflexions sont telles que, premièrement, beaucoup a été fait pour introduire différents types de solutions de gestion ou d'opérateurs dans l'histoire du cloud. Et l'écart initial entre le choix de MySQL ou Postgres, il semblait être nivelé, dans le sens où si tout était plus simple avec MySQL, cela prenait et ça fonctionnait, alors Postgres devait d'abord avoir beaucoup de danses avec des tambourins pour que cette chose guérisse . Et dans l'environnement cloud, vous avez quelque chose: cliqué sur un bouton - tout est apparu. Autrement dit, d'une part, cet écart a été supprimé. Puis une certaine perception générale en termes de licences, propriétaires, non propriétaires, bla bla bla, également affectée. En gros, si vous le simplifiez complètement, si je n'aime pas le faire avec un seul bouton, je choisirai ce qui est le plus gratuit, eh bien,ou ils disent que c'est gratuit. En fait, ce n'est pas clair, mais néanmoins. Ce qui est emballé dans une boîte idéologiquement plus correcte. Ceci est une histoire.

Et la deuxième histoire est que c'est spécifiquement pour la Russie, car je compte sur les données, après tout, pas le monde, mais le russe, peut-être que dans le monde, l'histoire est un peu différente. Il y avait une telle histoire que, à un moment donné, les post-congrès se sont unis assez fortement et ont commencé à faire beaucoup de relations publiques. Et ils ont créé des groupes de travail et des conférences, et depuis plusieurs années, il y a une entreprise qui fabrique la solution d'entreprise russe.

Tout d'abord, que pensez-vous, en Russie, dans le monde, de ce rééquilibrage entre MySQL et Postgres, et si oui, quelles sont ses raisons, combien de ses raisons que j'ai indiquées sont rationnelles, raisonnables, peut-être y en a-t-il d'autres causes?

Evgeny Kuzovlev: Pour être honnête, je n'ai jamais pensé que le cloud semblait aplanir toutes les différences, probablement parce que j'ai tout sur place. Pour moi, les nuages ​​sont des choses qui, disons là, quelque chose sur l'Amazonie, remplissons-le rapidement, puis ce sont des nuages ​​pour moi. Par conséquent, de ce côté, je n'ai jamais pensé. Mais ici, en effet, la complexité est réduite.

Plus tôt, conditionnellement, il y a environ huit ans, pour que Postgres travaille juste pour vous, il fallait tellement danser avec un tambourin que la mère ne pleurait pas en ce moment. Et vous avez mis MySQL hors de la boîte et cela a fonctionné pour vous. Peut-être pas huit ans, peut-être 10-12 ans. En effet, cette complexité dans Postgres a été considérablement réduite, et le point d'entrée est opérationnel et de développement, il a été comparé à MySQL d'une manière ou d'une autre.

Mais moi, par exemple, pour nous-mêmes, nous avons résolu un tel problème, j'ai essayé d'approcher, et j'essaie d'approcher le plus loin possible. Nous avions besoin, lorsque nous avons démarré DWH, de sélectionner le moteur de la table dénormalisée. En même temps, il n'y a pas d'analyse là-bas, l'analyse est à un niveau légèrement différent. C'est juste du stockage pur. Un SGBD révolutionnaire était nécessaire pour fournir, respectivement, une analyse de comparaison des données.

Et nous avons abordé cette question MySQL ou Postgres, et malgré le fait que les ressources opérationnelles soient assez hautement qualifiées, nous avons choisi. Et j'ai, par exemple, l'impression que Postgres, il est, vous savez, universitaire. Comme écrit dans le manuel, cela fonctionnera. Et MySQL, il est en quelque sorte assez léger et avec un tas de hacks. Mais en même temps, ces hacks fonctionnent dans 99% des cas. Et peu importe le nombre de gars de Postgres qui donnent des benchmarks synthétiques, dans des situations réelles, qui couvrent 99% de l'utilisation réelle des bases de données, MySQL séduit les utilisateurs ordinaires.

Et le plus, vraiment, bon sang, c'est juste un énorme plus de MySQL, qu'il n'a pas de vide automatique. Parce que mettre en place cette chose dans Postgres, tout le monde ne peut pas. Et dès que les utilisateurs ...

Vladimir Fedorkov: Sonne méchamment (par rapport aux ingénieurs - env. AR ).

Evgeny Kuzovlev: Et dès que les utilisateurs se retrouvent dans le vide automatique, ils commencent à rencontrer les problèmes les plus fous. C'est, comme ça, pour obtenir une dégradation de 60% du système, c'est pour vous, c'est ...

Alexei Rybak: Non, je suis juste entré dans l'atout.

Evgeny Kuzovlev: Eh bien, je suis désolé. Immédiatement disposé comme sur une table. Cependant, je sais, bien sûr, que nous avons Postgres. Nous en avons beaucoup. Nous avons des problèmes avec l'aspirateur automatique, Dieu merci, non. Mais dans ma carrière, je suis passé par tous ces cas - colère, déni, négociation et réglage de l'aspirateur automatique. Mais c'est une sensation tellement douloureuse, je vais vous le dire. MySQL ne cause pas autant de douleur.

En même temps, je suis extrêmement furieux parce que dans MySQL je n'ai pas l'opportunité ... je veux, mais ici j'ai un index B-tree et c'est tout. Et même si vous craquez! Je ne sais pas, je ne peux pas simplement construire ...

Alexey Rybak: Il y a des index de hachage.

Evgeny Kuzovlev: Oui. Mais, comparons le nombre d'index que nous avons dans MySQL et le nombre d'index que nous avons dans Postgres. C'est incomparable. En même temps, on peut en dire autant des moteurs de table. Chez MySQL, nous avons un moteur de table, vous voulez, je ne sais pas, vous allez prendre du TokuDB, et vous apprécierez dans un pour cent des cas et dans 99% des cas, vous ne comprenez pas pourquoi vous l'avez pris ...

Andrey Aksyonov: frottis avec des fractales.

Alexey Rybak:Eh bien, attendez, avec les moteurs, c'est aussi un canular. Auparavant, quand il a été inventé, cela semblait être une chose cool. Mais en fait, rien n'a vraiment pris racine.

Andrey Aksyonov: Pourquoi n’a-t-il pas pris racine? InnoDB a pris racine.

Alexey Rybak: Non, je veux dire, à part InnoDB. Autrement dit, InnoDB est devenu juste une norme. Et toutes les autres histoires avec des morceaux de colonne, avec des morceaux plus spécifiques, comme Toku. Tu as raison, je ne sais même pas où est ce pourcentage. Autrement dit, les moteurs se sont avérés être une chose si douteuse.

Evgeny Kuzovlev: Vous savez, la psychologie humaine est telle que parfois la possibilité même de choix est plus importante que le choix lui-même. MySQL le donne.

Alexei Rybak: Les gens ne choisissent pas MySQL contre Postgres, car il existe différents moteurs. Je pense que c'est le dernier ...

Vladimir Fedorkov: Parce que quand les gens choisissent MySQL contre Postgres, s'il y a au moins quelqu'un dans l'entreprise qui est derrière Postgres, il sera choisi parce que c'est une religion.

Alexey Rybak: MySQL est aussi une religion.

Vladimir Fedorkov: Non, en aucun cas.

Andrey Aksyonov:Personne n'a soulevé un autre point important, appelé «contingent a augmenté». Les exigences ont naturellement augmenté dans une certaine couche. La question initiale est de savoir pourquoi le pourcentage de Postgres augmente, le pourcentage de ce misérable faux appelé MySQL diminue régulièrement. Et, bien sûr, à la fin, En principe, la planète est la même, les dinosaures piétineront et MongoDB vaincra tout le monde, mais c'est à l'avenir, mais l'échelle Web est toujours importante, car les exigences que les applications font, elles changent dans le temps - une fois et à un moment donné Postgres mûri, pour sa part, et un ensemble d'exigences des développeurs arrivés à échéance de leur part.

Alexei Rybak: . Ecoutez, je ne crois pas, pardonnez - moi Dis - moi, nous allons spécifiquement ...

Andrey Aksyonov: . Allez spécifiquement look, 1995 ...

Alexey Rybak:Les sociétés qui ont lancé à l'origine des produits à l'échelle du Web qui sont conçus pour les mêmes mecs ... Dieu, est sorti de ma tête! Je viens d'appeler ... Maintenant, voici qui va vaincre tout le monde ...

Andrey Aksyonov: Mongo va gagner.

Alexey Rybak: Mongo, oui, oui, oui, désolé, oui. Donc, Mongo avait initialement deux choses. Tout d'abord, le magasin d'objets, ne pensez pas, en bref, ORM, écrivez, enregistrez et n'avez besoin de rien, SQL n'a pas besoin de savoir, bref, c'est tout. Cela a conduit certains gars, leurs exigences n'ont pas changé, ils sont simples: oui, mais c'était possible, SQL ne pouvait pas être enseigné, wow! Comme c'est cool! Il a simplement dit: sauvez l'objet, et il m'a laissé quelque part, classe! C'est le premier.

Deuxièmement quoi? Ne pensez pas à la tolérance aux pannes, nous pouvons initialement le faire dans plusieurs DC et ainsi de suite. Au début, c'était des conneries de marketing. Ensuite, ils ont tordu quelque chose et, en principe, si je comprends bien, dans les dernières versions maintenant (cela fonctionne et) beaucoup où vraiment Mongo est utilisé dans de grandes installations.

Je veux dire, ceci est un bon exemple lorsque vous entrez sur le marché, un autre marché, ressentant ces deux possibilités, que, premièrement, les personnes qui ont grandi dans le paradigme de programmation en langage objet, en général, cette inadéquation d'impédance, Ceci est une histoire fondamentale. Il leur est plus facile d'utiliser des outils qui disent: «sauve-moi juste», je ferai tout pour toi. Et en même temps, hors de la boîte, de telles choses associées à la file d'attente, et autre chose.
Ici, je comprendrais, malgré le fait que je dis encore une fois, vous troll, vous le mettez comme une sorte de cas hyperbolique, relativement parlant, une sorte de fiction. Néanmoins, ce cas, dit-il exactement à ce sujet, que vous pouvez sortir avec un tel produit, trouver une telle niche, et il volera, piétinera, explosera. Je ne comprends pas ce que Postgres a suggéré ou comment ils ont changé et quelles exigences Postgres est soudainement devenu si attrayant, selon votre logique.

Andrey Aksyonov: Je répète encore une fois. Germes des deux côtés; Postgres sur certains paramètres, d'une part, et développeurs sur certains paramètres, d'autre part. Encore une fois, 1995. Vous êtes développeur. Vous êtes assis en B ... ( Atyrau ), gagnez 15 $, et c'est un an. Et vous écrivez c ***** ( sans valeur) livre d'or en Perl. Et puis vous obtenez le processus de sélection - quelle base de données choisir. Étonnamment, MySQL et Postgres existent déjà. Et s'ils ne le sont pas, ils apparaîtront en 1996. Mais vous, s *** (femelle de la famille canine) , la créatrice du livre d'or sur Perl en B ... ( Syzran )! Vous avez une tâche de cette ampleur, vous les résolvez.

La seule référence à laquelle vous pouvez penser est le nombre de requêtes «par cercle» par seconde que vous allez aspirer. Et «sur le cercle» des demandes par seconde en ce moment, Postgres tire quatre fois et demie de moins. Juste comme ça, juste parce que tu te fous. Après cela, vous regardez: bien, oui, mais dans les transactions Postgres, et dans MySQL 3.23 MyISAM. Mais pour être honnête, les transactions pour mon livre d'or sont n **** pour moi ( pas du tout)Pas besoin. Choisissez fortement MySQL.

Maintenant, un peu de temps s'est écoulé, 25 ans. En principe, vous vivez toujours en B ... ( Tuymazy ), vous n'écrivez plus en Perl, mais en NodeJS, votre salaire a été indexé, car c'est juste l'inflation en dollars, et maintenant c'est 15 dollars, multipliés par l'inflation, - 45, et c'est un mois. Vous avez les mêmes problèmes, plus 100 500 packages dans NodeJS. Et ces packages 100500 NodeJS doivent stocker leur état entier quelque part, des requêtes complexes sur le gestionnaire de packages, etc.

Et puis soudain, vos exigences, que vous mordez dans la base de données, ont un peu augmenté. Par exemple, pour une raison quelconque, vous ne pouvez pas vivre et ne voulez pas vivre sans transactions. Quelle étonnante coïncidence! Vous avez encore besoin de jointures. Voici quelques index étranges qui commencent à penser, et pas seulement un arbre B automatique, comme: oh, bon sang! Mais ce serait bien d'avoir un index géographique, un arbre R ou, disons, Dieu nous sauve, des arbres fractals.

Cela a changé la série d'exigences par les développeurs, les temps. Et d'autre part, Postgres, qui dans les années des anciens ralentit naturellement simplement de manière enchanteresse sur de simples "cercles" ( demandes), qui étaient stupides et nécessaires à tout le monde, il s'est considérablement amélioré au cours de la dernière courte période de 25 ans, pour sa part. Et donc ils se sont rencontrés soudainement, et de plus en plus de gens sont surpris de découvrir ça, op! Tu regarde! Mais Postgres n'est pas si mal, il s'avère! Et c'est un peu mieux pour mes besoins. Mon hypothèse est exactement telle que, grosso modo, au début de MySQL ...

Alexey Rybak: Écoutez, mais je ne comprends pas où est le meilleur? Qu'est-ce qui est mieux? Je comprends qu'ils sont égaux en quelque chose, mais quoi de mieux, je ne comprends pas.

Andrey Aksyonov: Ils sont donc tous les deux pires.

Alexey Rybak: Que Mongo?

Andrey Aksyonov:Bien sûr, que, entre guillemets, "Mongo". Mais c'est un sujet pour toute une conversation séparée, et un fil de conversation séparé appelé "où est le brillant avenir".

Vladimir Fedorkov: Il n'y a pas d'avenir brillant. La base de données est mauvaise. Dès que vous sélectionnez une base de données, vous vous signez une condamnation à mort. N'utilisez pas de bases de données. Écrire des fichiers.

Alexey Rybak: / dev / null! Écrivez à / dev / null, mes amis, dev / null est une échelle Web.

Andrey Aksyonov: Oui. Eh bien, d'accord, vous pouvez également exécuter / dev / null en principe sur les performances, nous le pouvons.

Alexey Rybak: D'accord, mes amis. Tout le monde est probablement très fatigué. Nous parlons depuis plus de deux heures.

Andrey Aksyonov: Mais des questions vraiment intéressantes n'ont pas été soulevées.

Nikolay Korolev:Juste commencé.

Alexey Rybak: Sérieusement? Voulez-vous continuer?

Andrey Aksyonov: Je n'ai pas non plus versé de whisky.

Alexey Rybak: Mais c'est une grande question pourquoi vous ne l'avez pas fait.

Andrei Aksyonov: Je ne me suis pas préparé, bien sûr ...

Vladimir Fedorkov: Donc, ils ont dit que la radiodiffusion, la radiodiffusion, rien n'est impossible, vous ne pouvez pas jurer, vous ne pouvez pas dodu.

Alexey Rybak: Ah! Copains! Tous ceux qui regardaient l'émission, merci beaucoup d'être avec nous. Nous commençons la partie non officielle, où s'éteint-elle ... Maintenant ... Je supprime le flux en direct. Merci à tous, merci à nos invités - Vladimir, Andrey, Eugene, Nikolai. Stream off, au revoir, à plus tard.

(fin de l'enregistrement)

Le dossier complet du mitap peut être consulté sur youtube:



Dans un avenir proche, nous publierons également d'autres parties sur l'infrastructure, les modèles de mise à l'échelle / tolérance aux pannes et l'état de l'écosystème MySQL.

Si vous aimez ce format, alors ce vendredi il y aura un autre rallye dédié aux infrastructures conteneurs, il y a encore des places pour cela . Participants: Evgeny Potapov (PDG d'ITSumma), Dmitry Stolyarov (CTO Flant), Denis Remchukov (alias Eric Oldmann, COO argotech.io, ex - RAO UES de Russie), Andrey Fedorovsky (CTO News360.com) et Ivan Kruglov (ingénieur système, ex - Booking.com). Parlons des outils, des problèmes et des perspectives des conteneurs et des Kubernetes dans une infrastructure moderne.

Nous avons également le groupe Facebook mentionné «Gestion et développement de grands projets informatiques» , la chaîne @feedmeto avec des publications intéressantes de blogs technologiques (principalement étrangers) et la chaîne de l'auteur @rybakalexey sur la gestion du développement dans les entreprises alimentaires.

More articles:


All Articles