История изменений
Исправление borisych, (текущая версия) :
Ну ты не представляешь, а pgbouncer придумали не с пустого места - берём стопицот коннектов и работаем с ними.
pgbouncer может быть полезен весьма в специфичных ситуациях, а именно когда у приложения нет собственного пула для БД, т.е. расклад в реальности примерно такой:
- да, каждый раз подключаться к БД для выполнения запроса выходит довольно дорого, тут спора нет
- держать в приложении соединение открытым тоже ничем хорошим не сулит совершенно, в большинстве случаев получается так, что в приложение что-то из базы выбрало и пошло фигней страдать, в духе формировать json/xml/html для клиента и потом ждать, когда клиент этот трафик получит уже, а соединение все висит и висит открытым, т.е. у открытого соединения должно быть какое-то время жизни/скоуп - это вызывает потребность иметь пул соединений
- ну хорошо, случилось так, что у приклада пула собственного нет, чем тут поможет pgbouncer? мы думаем, что подключаться к БД - это дорого, а чего мы решили что подключаться к pgbouncer дешево? В первом случае у нас tcp handshake + fork (особо упоротые еще TLS впихивают), а во втором случае только tcp handshake - вот оно тоже нифига не дешево выходит, удешевлять можно только тем, что pgbouncer нужно устанавливать не на БД, не где-то как отдельный сервис, а, сюрприз, прямо на локалхосте, т.е. там же где крутится приклад, при таких раскладах, где мы под экземпляр приложения устанавливаем pgbouncer, возможности хоть как-то регулировать количество подключений к БД просто напросто нет - у нас клиентом БД становится не приклад, а pgbouncer, т.е. с точки зрения вводимых ограничений на количество одновременных соединений с БД разницы нет никакой (куда лучше в приложении использовать собственный пул)
- нужно понимать, что сам по себе pgbouncer был написан дидами еще черт знает когда, и в многопоточность/производительность он не умеет ну вообще никак, условно с трафиком в гигабит он точно не справляется, на счет полгигабита - уже на грани фола. Есть odyssey от Yandex (https://github.com/yandex/odyssey), но судя по тому что пишут в issues ситуация с ним примерно такая: он в яндексе скорее всего работает, потому что там потребности хоть и довольно специфичные, но при этом ограниченные (т.е. все делают по определенным шаблонам), но это никак не продукт для массовой аудитории. Есть еще решения от отечественного производителя: https://postgrespro.ru/docs/enterprise/16/connection-pooling - сделать более всратее нужно еще постараться
Исходная версия borisych, :
Ну ты не представляешь, а pgbouncer придумали не с пустого места - берём стопицот коннектов и работаем с ними.
pgbouncer может быть полезен весьма в специфичных ситуациях, а именно когда у приложения нет собственного пула для БД, т.е. расклад в реальности примерно такой:
- да, каждый раз подключаться к БД для выполнения запроса выходит довольно дорого, тут спора нет
- держать в приложении соединение открытым тоже ничем хорошим не сулит совершенно, в большинстве случаев получается так, что в приложение что-то из базы выбрало и пошло фигней страдать, в духе формировать json/xml/html для клиента и потом ждать, когда клиент этот трафик получит уже, а соединение все висит и висит открытым, т.е. у открытого соединения должно быть какое-то время жизни/скоуп - это вызывает потребность иметь пул соединений
- ну хорошо, случилось так, что у приклада пула собственного нет, чем тут поможет pgbouncer? мы думаем, что подключаться к БД - это дорого, а чего мы решили что подключаться к pgbouncer дешево? В первом случае у нас tcp handshake + fork (особо упоротые еще TLS впихивают), а во втором случае только tcp handshake - вот оно тоже нифига не дешево выходит, удешевлять можно только тем, что pgbouncer нужно устанавливать ни на БД, ни где-то как отдельный сервис, а, сюрприз, прямо на локалхосте, т.е. там же где крутится приклад, при таких раскладах, где мы под экземпляр приложения устанавливаем pgbouncer, возможности хоть как-то регулировать количество подключений к БД просто напросто нет
- нужно понимать, что сам по себе pgbouncer был написан дидами еще черт знает когда, и в многопоточность/производительность он не умеет ну вообще никак, условно с трафиком в гигабит он точно не справляется, на счет полгигабита - уже на грани фола. Есть odyssey от Yandex (https://github.com/yandex/odyssey), но судя по тому что пишут в issues ситуация с ним примерно такая: он в яндексе скорее всего работает, потому что там потребности хоть и довольно специфичные, но при этом ограниченные (т.е. все делают по определенным шаблонам), но это никак не продукт для массовой аудитории. Есть еще решения от отечественного производителя: https://postgrespro.ru/docs/enterprise/16/connection-pooling - сделать более всратее нужно еще постараться