大数据量数据库配置部署方案思考

2008-06-19

关键字: 数据库部署及处理

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

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

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

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

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

大家有什麽思路，应该怎么处理。说服客户花钱很难，且合同已经签了。

20:14
浏览 (146)
评论 (61)
进入论坛
相关推荐

runthu 2008-07-14

连接池
索引
查询sql优化
大表分区
加硬件，做集群

如果还不行？没办法了！300万条数据不多啊，照说。

xlongbuilder 2008-07-10

liuzongan 写道

看看http://dev.csdn.net/author/griefforyou/082b9b29299e4584b78bf6f7ccb57c0b.html

链接打不开

xlongbuilder 2008-07-10

谢谢各位的回复

澄清几点：
1、oracle 是客户长远考虑到结果，以后很可能数据不会这么点了流量会很大用户也会有很多增加这是在可预期的几年的考虑

2、我早就讲过oracle 不能解决根本问题，不过可以缓解问题。对开发人员来讲也会轻松些，作为架构及开发人员自由度也会大些。

3、问题已经了解到很清楚了，客户的c/s系统打开个每个界面都要查询20 几次操作，完成一个业务基本上要上百的操作，不满才怪，查询报表等sql 写的奇垃圾，没有任何索引优化措施所以主要原因还是该系统设计问题。

4、我们用sqlserver 可以用但是用的好就不轻松了，考虑到目前项目组情况，oracle 确实可以给我省不少力气。说实话站在用户角度长远点考虑 oracle 还是ok的

zt371 2008-07-04

8个月才300w条记录，现在主流的什么数据库都没问题的。
微软也是出来混饭的，这点都不至于搞不定。原来我们用SQL Server，千万级的数据跑的很好。
前面的应用搞不好，什么数据库都是死。没有数据库能直接承受前端压力，测试玩具除外。

liuzongan 2008-07-02

看看http://dev.csdn.net/author/griefforyou/082b9b29299e4584b78bf6f7ccb57c0b.html

ironsabre 2008-07-01

问题都没定位好问题，就开始张罗着换数据库。
这样做对客户很不负责任。

jameswxx 2008-07-01

有人建议用oracle，好像一用oracle问题就全部解决了，8个月才300万的记录，也没有必要用到oracle的表分区。很多公司用只是把数据库当成一个简单的存放数据的地方，写的sql也不讲究，索引也不好好做，我只想说，如果sqlserver都没用好，用oracle只是徒劳，oracle的索引类型比sqlserver多多了，还有其他很多的优化途径，有更多的特性和细节可以让用户调控，以达到性能进一步优化的目的。
其实8个月产生300万条记录，这样的数据量不算很大，绝对不会是数据库的问题呢，在确定系统结构合理的情况下，应检查数据库设计是否合理，我说的这个合理并不是说要遵循理论上的范式，而是因地制宜，比如适当的加一些多余的字段，sql的写法是否有比较高的效率，是否用查询分析器反复调试过sql的效率，数据文件的分配是否合理，索引的建立是否合理，数据库的一些全局参数是否合理，只有在确定数据库是瓶颈的情况下，你换成oracle，可能你的系统会进一步的健壮，如果你根本驾驭不了数据库深层的管理，优化策略，换oracle也是没用的。

wlei9802 2008-06-30

sql server没有你们说的那么差吧！

zxbyhcsdn 2008-06-30

Readonly 写道

M$的Sql server？那一定是跑在windows上了，啥都不说，先换操作系统，然后再换数据库呗

800W 麻，还是可以不同Oracle的牛刀。
SqlServer2005杀鸡刀可以了。
现在Sqlserver2005支持分区表了.再建好索引,优化一下Sql,完全没问题..

ziyuan 2008-06-30

换os和db就是工作量和成本比较大的做法。
我的建议是
1.读写分离
2.使用中间件
3.使用集群或分布式

csrcom 2008-06-30

不知道楼主对 Amoeba:分布式数据库Proxy解决方案是否感兴趣？
http://amoeba.sf.net/amoeba.pdf

zhuyx808 2008-06-30

cuiyi.crazy 写道

eastPoint 写道

完全可以考虑使用oracle的表分区功能来完成。

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

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

SQL Server也有表分区的啊

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

MSSQL 确实容易死锁的说

先搞个jwebap来看看问题出在哪里吧，换上连接池试下

ccxw1983 2008-06-27

楼主，去找个专业级的dba瞧瞧吧。我们团队接手的一个项目以前也有性能问题导致不能上线。请了专业的dba和java高手后，一切都ok了。
自己没有能力就花点钱，请达人瞧瞧嘛。省得自己瞎操心。

cuiyi.crazy 2008-06-27

eastPoint 写道

完全可以考虑使用oracle的表分区功能来完成。

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

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

SQL Server也有表分区的啊

dy.f 2008-06-27

优化ＳＱＬ是关键，做查询的时候只把要查的字段找出来就ＯＫ了，千万不要把所有字段都查出来，然后只用其中一个，这两种SQL语句查询，在数据量大的时候，可以明显感觉出所需时间的差别，建议在以后写SQL语句的时候也考虑到性能问题

licco1 2008-06-26

也不要说楼主了，用了oracle，也可以省心些日子。当然，我觉得数据库不是系统慢的根源，楼上的很多兄弟都已经说了。被骗了，我以为是几kw级别的数据库配置部署方案的探讨呢。

jason_help 2008-06-26

xlongbuilder 写道

baibai326 写道

MS的数据库过了200W级别的就有些吃力了，特别是一些大表，过了百万级，经常就是update死锁，等待……特折磨人。

还是换数据库吧，informix，db2_se是不错的选择，O系列太贵了，呵呵，如果只是做报表，数据存储，从性价比上来说，informix足够了，便宜量又足。

当然前提是，换数据库的操作系统。

严重同意目前就是这个问题
MS的数据库过了200W级别的就有些吃力了，特别是一些大表，过了百万级，经常就是update死锁，等待……特折磨人。
在本人的强烈要求下，客户已经决定采用oracle

这么点数据就用oracle，浪费！

airport 2008-06-26

1000万以下都应该好解决。MS的DB虽然赶不上Oracle但也不至于那么差劲。
问题肯定还在查询优化上了。没有好的DBA，碰到大数据量确实麻烦。

edwardpro 2008-06-26

看看连接池和数据库连接性能吧...

xlongbuilder 2008-06-25

ltshark 写道

我们刚做的一个系统，一小时平均1w的数据量，用的oracle，主表数据很短时间内就变大。我们开始也遇到这个问题，经常应用查询数据库导致数据库cache锁表，最后通过分表来提高应用交互数据库的速度提高。运行表只保持某些状态的数据，不经常处理的数据都弄走。
现在除了2个表union查询慢，其他都还好，不过查询可以通过分区来解决。
在这个过程中我们还发现，程序中很多sql由于写法不好或是别的什么导致数据库压力很大。建议楼主清查一下程序里面的sql，如果有dba最好请这些兄弟分析一下。
我感觉分表要好弄一些，虽然程序还有相应的变动。

谢谢回复我们将在设计过程中注意此问题