{"id":96515,"date":"2020-10-12T19:43:02","date_gmt":"2020-10-12T17:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/odyssey-roadmap-chto-eshhyo-my-hotim-ot-pulera-soedinenij-andrej-borodin-2019"},"modified":"2020-10-12T19:43:02","modified_gmt":"2020-10-12T17:43:02","slug":"odyssey-roadmap-chto-eshhyo-my-hotim-ot-pulera-soedinenij-andrej-borodin-2019","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/odyssey-roadmap-chto-eshhyo-my-hotim-ot-pulera-soedinenij-andrej-borodin-2019","title":{"rendered":"Feuille de route d'Odyssey : que voulons-nous encore du pooler de connexions. Andre\u00ef Borodine (2019)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Feuille<\/p>\n

<\/p>\n

Dans son rapport, Andre\u00ef Borodin expliquera comment ils ont pris en compte l'exp\u00e9rience de mise \u00e0 l'\u00e9chelle de PgBouncer lors de la conception du pooler de connexions. Odyssey<\/a><\/noindex>, comment ils l'ont d\u00e9ploy\u00e9 en production. De plus, nous discuterons des fonctionnalit\u00e9s que nous aimerions voir dans les nouvelles versions du pooler : il est important pour nous non seulement de satisfaire nos besoins, mais aussi de faire \u00e9voluer la communaut\u00e9 des utilisateurs. Odyss\u00e9e<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Vid\u00e9o :<\/p>\n

\n

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Bonjour \u00e0 tous ! Je m'appelle Andre\u00ef. <\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Chez Yandex, je travaille sur le d\u00e9veloppement de bases de donn\u00e9es open source. Aujourd'hui, notre sujet porte sur le pooler de connexions. <\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Si vous savez comment appeler un pooler de connexions en russe, faites-le moi savoir. Je suis vraiment d\u00e9sireux de trouver un bon terme technique qui devrait s'\u00e9tablir dans la litt\u00e9rature technique. <\/p>\n

<\/p>\n

Le sujet est assez complexe, car dans de nombreuses bases de donn\u00e9es, le pooler de connexions est int\u00e9gr\u00e9 et il n'est m\u00eame pas n\u00e9cessaire d'en \u00eatre inform\u00e9. Certaines configurations existent partout, mais cela ne fonctionne pas ainsi dans Postgres. En parall\u00e8le (\u00e0 HighLoad++ 2019), il y a une pr\u00e9sentation de Nikolai Samokhvalov sur la configuration des requ\u00eates dans Postgres. Je comprends que les personnes ici ont d\u00e9j\u00e0 configur\u00e9 les requ\u00eates de mani\u00e8re optimale, et ce sont des personnes qui rencontrent des probl\u00e8mes syst\u00e8me plus rares li\u00e9s au r\u00e9seau et \u00e0 l'utilisation des ressources. Parfois, cela peut \u00eatre assez compliqu\u00e9 au niveau de la clart\u00e9 des probl\u00e8mes.<\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Yandex dispose de Postgres. Dans Yandex.Cloud, vivent de nombreux services de Yandex. Nous avons plusieurs p\u00e9taoctets de donn\u00e9es, qui g\u00e9n\u00e8rent pas moins d'un million de requ\u00eates par seconde dans Postgres. <\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Nous fournissons un cluster assez typique \u00e0 tous les services \u2013 il s'agit de la n\u0153ud principal primaire, de deux r\u00e9pliques ordinaires (synchrones et asynchrones), d'une sauvegarde et de la mise \u00e0 l'\u00e9chelle des requ\u00eates de lecture sur la r\u00e9plique. <\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Chaque n\u0153ud du cluster est un Postgres, sur lequel, en plus de Postgres et des syst\u00e8mes de surveillance, un pooler de connexions est \u00e9galement install\u00e9. Le pooler de connexions est utilis\u00e9 pour le fencing et pour sa fonction principale. <\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Quelle est la fonction principale d'un pooler de connexions ? <\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Dans Postgres, un mod\u00e8le de processus est adopt\u00e9 pour travailler avec la base de donn\u00e9es. Cela signifie qu'une connexion \u00e9quivaut \u00e0 un processus, un backend Postgres. Et dans ce backend, il y a de nombreux caches diff\u00e9rents, qui sont assez co\u00fbteux \u00e0 cr\u00e9er de mani\u00e8re distincte pour diff\u00e9rentes connexions. <\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

En outre, dans le code de Postgres, il y a un tableau appel\u00e9 procArray. Il contient les principales informations sur les connexions r\u00e9seau. Et presque tous les algorithmes de traitement de procArray ont une complexit\u00e9 lin\u00e9aire, parcourant l'ensemble du tableau des connexions r\u00e9seau. C'est une boucle assez rapide, mais avec un grand nombre de connexions r\u00e9seau entrantes, cela devient un peu plus co\u00fbteux. Et quand cela devient un peu plus co\u00fbteux, au final, on peut payer un tr\u00e8s gros prix pour un grand nombre de connexions r\u00e9seau. <\/p>\n

<\/p>\n

\"Feuille<\/p>\n

<\/p>\n

Il existe trois approches possibles :<\/p>\n

<\/p>\n