PostgreSQL 的客户端连接池与外部连接池有何优缺点？
给定一个针对其预期负载进行合理配置的 PostgreSQL 数据库，哪些因素会影响选择外部/中间件连接池（即 pgBouncer、pgPool）与客户端连接池（HikariCP、c3p0）。最后，在什么情况下您希望同时应用客户端和外部连接池？
根据我的经验和理解，外部池的缺点是：
- 额外的故障点（包括从安全角度来看）
- 额外的延迟
- 部署中的额外复杂性
- 安全复杂性和用户凭据
在研究这个问题时，我遇到了客户端和客户端的实例使用侧面池和外部池。这样部署的动机是什么？在我看来，这是为了获得我似乎错过的收益而加剧了大多数缺点。
Given a PostgreSQL database that is reasonably configured for its intended load what factors would contribute to selecting an external/middleware connection pool (i.e. pgBouncer, pgPool) vs a client-side connection pool (HikariCP, c3p0). Lastly, in what instances are you looking to apply both client-side and external connection pooling?
From my experience and understanding, the disadvantages of an external pool are:
- additional failure point (including from a security standpoint)
- additional latency
- additional complexity in deployment
- security complications w/ user credentials
In researching the question, I have come across instances where both client-side and external pooling are used. What is the motivation for such a deployment? In my mind that is compounding the majority of disadvantages for a gain that I appear to be missing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，由于您详细说明的原因，应用程序端的连接池是一件好事。 时，外部连接池才有意义
您的应用程序服务器没有连接池
您有多个（许多）应用程序服务器实例，因此无法有效地限制应用程序服务器中连接池的数据库连接数量
Usually, a connection pool on the application side is a good thing for the reasons you detail. An external connection pool only makes sense if
your application server does not have a connection pool
you have several (many) instances of the application server, so that you cannot effectively limit the number of database connections with a connection pool in the application server