我是不敢说合不合理,因为有这么多的高手会看到这个问题,我只说一下我听说的方案:
无线业务吧? 只能用oracle了.
在Java编程中有个c-jdbc,他可以把後端的数据库做的和RAID差不多,通过配置可以所
有后台数据库都有所有的表,或者根据你的配置不同的数据库拥有不同的表。当然所
有请求也会在在一个集中的前端进行处理,应该同样有瓶颈效应的,但具体的性能就
要看实现的能力了。
我想这个应该是模拟某些高端数据库集群的类似的功能吧。
还有就是规则的那个数据库感可以不用Sqlserver,实际上我门应该根据具体需要选用
数据库,甚至不用数据库,第一那个用户规则配置应该不大,所以也可以做成配置一
次Load到内存中。或者可以使用BerkeleyDB这样的使用键值--》数据的非关系数据
库,应该可以加速你的查询,它还可以配置内存缓存数据大小,缓存经常访问的数
据,在访问速度和数据量方面有个好的平衡。
对于海量数据和高并发的到最后检验架构的还是在实际的应用中。当然如果现在你们
就能很接近的模拟真实情况也是非常有帮助的。
在 Thu, 18 May 2006 14:59:12 +0800,MStar <msn...@gmail.com> 写道:
> 一条数据有多大?十几字节? 还是几K?
> 另外恐怕sqlserver难以承担重任啊。
>
> >
在 Thu, 18 May 2006 15:29:46 +0800,SevenCat <BastE...@gmail.com> 写道:
> 楼主的分表和分数据库是最常用的办法了。数据库自身的集群从来没用过,而且觉
> 得在很多情况下不如这种做法清爽。
>
> >
程序逻辑,我采用业务逻辑层的概念,对外提供应用服务器接口,全部的客户端通过应用服务器接口进行业务运算,应用服务器我也采用服务器群的概念,有一个主的应用服务器,有几个副应用服务器,全部客户端只知道该主应用服务器的地址,上线时登陆主应用服务器,然后主应用服务器根据各台应用服务器的负载情况返回给客户端真正的登陆地址(副应用服务器的地址),然后客户端再登陆到上面进行业务处理,每台应用服务器都能够访问各台数据服务器进行数据提取。
请问在这种架构合理么,需要每台应用服务器都配备一个公网ip么,还是有其他的方式可以只需要一个公网ip可以给全部的服务器公用?Nat能够实现么?
或者能否进行更好的负载均衡,就是客户端的各种业务都可以在不同的服务器上运算?谢谢各位的帮忙!!
主数据库不是所有访问的入口,要想获得具体客户的资料只能到相应的数据库中获取,我想他的压力跟其他非主数据库的压力应该查不多。
你的第二点意见,有没有相关的资料可以给我参考一下?
谢谢!
你的插入操作很多,所以建议你少建几个索引,其实一些业务完全可以在数据库中完成,通过触发器,约束和存储过程,这样性能会有大的提高。大数据的表,分区的确是必须的,当然,还需要更完善的维护计划,否则很容易,你的业务可能就会因为性能问题挂起了。
可以将同种逻辑业务放置在一个单一服务器上,这样服务器就可以为这种逻辑作特殊优化
比如web业务中,经常将图片作为单一服务器或服务器组来存放
> 类似的,Oracle好贵啊!!呵呵,能用我也想用!