Dre*_*rew 26 java mysql database tomcat connection-pooling
我负责开发和维护一组以类似数据为中心的Web应用程序.我当时决定的架构是每个应用程序都有自己的数据库和Web-root应用程序.每个应用程序都维护到自己的数据库的连接池和共享数据的中央数据库(登录等)
一位同事一直认为这种策略不会扩展,因为有这么多不同的连接池将无法扩展,我们应该重构数据库,以便所有不同的应用程序使用单个中央数据库,并且可能是任何修改系统特有的将需要从该数据库中反映出来,然后使用由Tomcat提供支持的单个池.他假定有很多"元数据"在网络中来回传递,以维护连接池.
我的理解是,通过适当的调整,在不同的池中使用尽可能多的连接(小批量应用程序获得更少的连接,大批量应用程序获得更多,等等),池的数量与数量相比无关紧要.连接或更正式地说,与1个30个连接池相比,维护3个10个连接池所需的开销差异可以忽略不计.
最初将系统分解为一个应用程序一个数据库设计的原因是,应用程序之间可能存在差异,并且每个系统都可以根据需要对架构进行修改.同样,它消除了系统数据渗透到其他应用程序的可能性.
不幸的是,公司没有强有力的领导作出艰难的决定.虽然我的同事只是模糊地支持他的担忧,但我想确保理解多个小型数据库/连接与一个大型数据库/连接池的分支.
Asa*_*aph 10
您的原始设计基于合理的原则.如果它对您的情况有帮助,则此策略称为水平分区或分片.它提供:
1)更高的可扩展性 - 因为如果需要,每个分片可以存在于单独的硬件上.
2)更高的可用性 - 因为单个分片的失败不会影响其他分片
3)更高的性能 - 因为被搜索的表具有更少的行,因此索引更小,从而产生更快的搜索.
您同事的建议可以让您进入单点故障设置.
至于你关于3个大小为10的连接池与1个大小为30的连接池的问题,解决这个争论的最好方法是使用基准测试.单独配置您的应用程序,然后使用ab(Apache Benchmark)进行一些压力测试,看看哪种方式表现更好.我怀疑不会有显着差异,但做基准来证明它.
| 归档时间： |
|
| 查看次数： |
8548 次 |
| 最近记录： |