Comments 15
Pgbouncer чем не устроил?
Pgbouncer чем не устроил?
Он не интегрирован в приложение. А в приложении нужен коннешн пул, для того, чтобы приложение не тратило время на установку соединения. Ведь даже если у вас есть pgBouncer, с ним тоже надо устанавливать соединение и его потом разрывать. А раз коннекшн пул в приложении всё равно будет, то зачем дополнительный pgBouncer
pgBouncer хорош для масштабирования и уменьшения нагрузки на PostgreSQL, но в нашем случае он не нужен. В приложении уже есть встроенный connection pool (pgxpool в Go), который решает основную проблему — уменьшает накладные расходы на установку соединений. Если всё равно приходится использовать connection pool в приложении, добавление pgBouncer только усложнит архитектуру без значительного выигрыша.
Как только у вас будет запущен не один процесс приложения, а сотня-другая, все это превратится в тыкву, и без решения типа PgBouncer-а (пулер на стороне сервера) станет не обойтись. Придется иметь и то, и другое.
Согласен, при масштабировании на сотни процессов без pgBouncer не обойтись. Однако его необходимость зависит от реальной нагрузки и архитектуры. Пока встроенного пула в приложении (pgxpool) достаточно, а добавление pgBouncer лишь усложнит систему без ощутимой выгоды. Но если нагрузка возрастёт и появится узкое место в соединениях с БД, то конечно, рассмотрим его внедрение
Как только у вас будет запущен не один процесс приложения, а сотня-другая, все это превратится в тыкву
Для того, чтобы всё превратилось в тыкву, нужно, чтобы приложение было написано откровенно плохо. Оно должно забирать соединение из коннекшн пула и не возвращать его туда как можно дольше, при этом не делая через это соединение запросов.
Придется иметь и то, и другое.
Для того, чтобы возникла такая необходимость, нужно, чтобы разработчики не понимали, как нужно работать с базой данных и при этом, чтобы используемый технологический стек не поддерживал автоматичекий возврать соединения в пул, когда соединение больше не нужно. Тогда да, придётся ((
Ссылки по теме: статья про то, что в PostgreSQL одно соединение = один ОС-процесс, статья про work_mem.
в PostgreSQL одно соединение = один ОС-процесс
Это всё не новости. Но только если 10 приложений делают каждое по 10 соединений, через которые постоянно делаются запросы, им для работы нужно 100 живых соединений с постгресом. И если постгрес может обслуживать только, допустим 50 соединений, то чем тут поможет pgBouncer?
Как решаете проблемы в случае необходимости горизонтального масштабирования? pgx - контроль пула на стороне клиента, но при увеличении количества тех же подов сервиса, легко упереться в лимиты БД, если она одна на все
Пока встроенного пула в приложении (pgxpool) достаточно, а добавление pgBouncer лишь усложнит систему без ощутимой выгоды. Но если нагрузка возрастёт и появится узкое место в соединениях с БД, то конечно, рассмотрим его внедрение.
легко упереться в лимиты БД, если она одна на все
Если приложения нормально работают с коннекшнами, то когда они упрутся в лимиты БД, pgBouncer ничем не поможет. Потому что приложениям для нормальной работы всё равно нужно больше коннекшнов, чем им выдаёт база данных.
Ну разве что приложению никто не скажет, что соединение не удалось установить. Просто ответы на запросы начнут приходить гораздо медленнее, чем раньше.
Да впринципе такой режим работы, который нужен приложению, появился в pgBouncer года полтора назад. До этого вообще нельзя было использовать его для таких случаев. Я лично не уверен, что за полтора года получилось отловить все баги.
PostgreSQL Connection Pooling: Наш опыт и с чем его едят