连接池策略：好，坏或丑？ [英] Connection Pool Strategy: Good, Bad or Ugly?
问题描述
我负责开发和维护一组以类似数据为中心的Web应用程序。我当时决定的架构是每个应用程序都有自己的数据库和Web根应用程序。每个应用程序都维护着一个到自己的数据库的连接池和一个用于共享数据（登录等）的中央数据库。
一个同事一直认为这个策略不会因为具有这么多不同的连接池将不是可扩展的，并且我们应当重构数据库，使得所有不同的应用使用单个中央数据库，并且对于系统可能是唯一的任何修改将需要从那个数据库，然后使用由Tomcat提供支持的单个池。他假定有很多元数据在网络中来回切换以维护连接池。
我的理解是，通过适当调整，只使用不同池之间所需的连接数量（低容量应用程序连接少，应用程序数量增多等）。 ），与连接数相比，池的数量无关紧要，或者更正式地表明，维持3个10个连接的池所需的开销差异是可以忽略的1个30个连接的池。
最初将系统打破为单应用程序单数据库设计的原因是应用程序之间可能会有差异并且每个系统可以根据需要对模式进行修改。同样，它消除了系统数据流向其他应用程序的可能性。
不幸的是，公司没有强大的领导力做出艰难的决定。虽然我的同事只是模糊地回顾了他的忧虑，我想确保我明白多个小数据库/连接与一个大型数据库/连接池的后果。
您的原始设计是基于合理的原则。如果它有助于您的情况，这种策略称为水平分区或分片。它提供：
1）更高的可扩展性 - 因为每个分片可以在独立的硬件上，如果需要的话。
2）更高的可用性 - 因为单个分片的失败不会影响其他分片。
3 ）更高的性能 - 因为正在搜索的表格行数更少，因此索引更小，从而获得更快的搜索速度。
您的同事的建议会将您转到单点故障设置。 / p>
至于你对大小为10的3个连接池和大小为30的连接池的问题，解决这个争论的最好方法是使用基准。每次配置你的应用程序，然后用ab（Apache Benchmark）做一些压力测试，看看哪个方法表现更好。我怀疑不会有明显的差异，但做基准证明它。
I'm in charge of developing and maintaining a group of Web Applications that are centered around similar data. The architecture I decided on at the time was that each application would have their own database and web-root application. Each application maintains a connection pool to its own database and a central database for shared data (logins, etc.)
A co-worker has been positing that this strategy will not scale because having so many different connection pools will not be scalable and that we should refactor the database so that all of the different applications use a single central database and that any modifications that may be unique to a system will need to be reflected from that one database and then use a single pool powered by Tomcat. He has posited that there is a lot of "meta data" that goes back and forth across the network to maintain a connection pool.
My understanding is that with proper tuning to use only as many connections as necessary across the different pools (low volume apps getting less connections, high volume apps getting more, etc.) that the number of pools doesn't matter compared to the number of connections or more formally that the difference in overhead required to maintain 3 pools of 10 connections is negligible compared to 1 pool of 30 connections.
The reasoning behind initially breaking the systems into a one-app-one-database design was that there are likely going to be differences between the apps and that each system could make modifications on the schema as needed. Similarly, it eliminated the possibility of system data bleeding through to other apps.
Unfortunately there is not strong leadership in the company to make a hard decision. Although my co-worker is backing up his worries only with vagueness, I want to make sure I understand the ramifications of multiple small databases/connections versus one large database/connection pool.
Your original design is based on sound principles. If it helps your case, this strategy is known as horizontal partitioning or sharding. It provides:
1) Greater scalability - because each shard can live on separate hardware if need be.
2) Greater availability - because the failure of a single shard doesn't impact the other shards
3) Greater performance - because the tables being searched have fewer rows and therefore smaller indexes which yields faster searches.
Your colleague's suggestion moves you to a single point of failure setup.
As for your question about 3 connection pools of size 10 vs 1 connection pool of size 30, the best way to settle that debate is with a benchmark. Configure your app each way, then do some stress testing with ab (Apache Benchmark) and see which way performs better. I suspect there won't be a significant difference but do the benchmark to prove it.
这篇关于连接池策略：好，坏或丑？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
