日期:2014-05-16  浏览次数:20424 次

大数据量数据库配置部署方案思考
业务情况
8个月主要表每张产生了近300万条数据,目前很慢客户反映强烈 ps:如何好用就没我们什么事了。
目前数据库服务器配置 4CPU 8G内存 系统没有服务器端全都是客户端。
还有一台查询服务器,
c/s 结构 数据库 sqlserver2000
每天操作近百笔,用户近百人。
这个系统在设计时没有考虑到这么大的数据量因此没有做什么数据库优化


此问题有以下解决方式:
1、 更换数据库
鉴于MSSqlServer的数据吞吐能力比较低下,因此可采用性能优良的Oracle系列数据库
优点:可以在一定程度上减轻压力。
缺点:价格较高 单CPU 20万左右,且不能彻底解决问题。

2、 集群
可有效的分散数据,减轻单个数据库压力,鉴于MSSqlServer不支持透明集群,可采用数据库分散部署的办法即采用多台服务器部署多个数据库每台数据库包含不同的表。
优点:可靠性伸缩性能好。
缺点:购置服务器费用高昂,需采用跨数据库事务处理性能较差。对系统开发要求较高。

3、 分表
采用将大表分拆成多个小表,采用按时间、类型等方式分拆,使得单次操作数据量控制在可控的范围内。
优点:节省成本。
缺点:系统复杂,对系统开发要求很高。

因为缓存存在很多不确定性不好量化 请大家在不考虑缓存的情况下发表意见。
现在要从c/s结构翻到B/S结构。

大家有什麽思路,应该怎么处理。 说服客户花钱很难,且合同已经签了。
47 楼 licco1 2008-06-26  
也不要说楼主了,用了oracle,也可以省心些日子。当然,我觉得数据库不是系统慢的根源,楼上的很多兄弟都已经说了。被骗了,我以为是几kw级别的数据库配置部署方案的探讨呢。
48 楼 dy.f 2008-06-27  
优化SQL是关键,做查询的时候只把要查的字段找出来就OK了,千万不要把所有字段都查出来,然后只用其中一个,这两种SQL语句查询,在数据量大的时候,可以明显感觉出所需时间的差别,建议在以后写SQL语句的时候也考虑到性能问题
49 楼 cuiyi.crazy 2008-06-27  
eastPoint 写道
完全可以考虑使用oracle的表分区功能来完成。

时间证明oracle表分区才是解决问题的关键和根本。

使用纯sql是无法解决该问题的。


SQL Server也有表分区的啊
50 楼 ccxw1983 2008-06-27  
楼主,去找个专业级的dba瞧瞧吧。我们团队接手的一个项目以前也有性能问题导致不能上线。请了专业的dba和java高手后,一切都ok了。
自己没有能力就花点钱,请达人瞧瞧嘛。省得自己瞎操心。
51 楼 zhuyx808 2008-06-30  
cuiyi.crazy 写道
eastPoint 写道
完全可以考虑使用oracle的表分区功能来完成。

时间证明oracle表分区才是解决问题的关键和根本。

使用纯sql是无法解决该问题的。


SQL Server也有表分区的啊



MSSQL2005以上版本才有真正的表分区,2000以下的就没的了~


MSSQL 确实容易死锁的说

先搞个jwebap来看看问题出在哪里吧,换上连接池试下
52 楼 csrcom 2008-06-30  
不知道楼主对 Amoeba:分布式数据库Proxy解决方案 是否感兴趣?
http://amoeba.sf.net/amoeba.pdf
53 楼 ziyuan 2008-06-30  
换os和db就是工作量和成本比较大的做法。
我的建议是
1.读写分离
2.使用中间件
3.使用集群或分布式
54 楼 wlei9802 2008-06-30  
sql server没有你们说的那么差吧!
55 楼 jameswxx 2008-07-01  
    有人建议用oracle,好像一用oracle问题就全部解决了,8个月才300万的记录,也没有必要用到oracle的表分区。很多公司用只是把数据库当成一个简单的存放数据的地方,写的sql也不讲究,索引也不好好做,我只想说,如果sqlserver都没用好,用oracle只是徒劳,oracle的索引类型比sqlserver多多了,还有其他很多的优化途径,有更多的特性和细节可以让用户调控,以达到性能进一步优化的目的。
    其实8个月产生300万条记录,这样的数据量不算很大,绝对不会是数据库的问题呢,在确定系统结构合理的情况下,应检查数据库设计是否合理,我说的这个合理并不是说要遵循理论上的范式,而是因地制宜,比如适当的加一些多余的字段,sql的写法是否有比较高的效率,是否用查询分析器反复调试过sql的效率,数据文件的分配是否合理,索引的建立是否合理,数据库的一些全局参数是否合理,只有在确定数据库是瓶颈的情况下,你换成oracle,可能你的系统会进一步的健壮,如果你根本驾驭不了数据库深层的管理,优化策略,换oracle也是没用的。
56 楼 ironsabre 2008-07-01  
问题都没定位好问题,就开始张罗着换数据库。
这样做对客户很不负责任。
57 楼 liuzongan 2008-07-02  
看看http://dev.csd