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

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


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

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

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

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

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

评论

66 楼 超级潜水员 2009-01-08  

才三百万的数据量,根本不值一提,LZ找找自身程序的问题吧,别乱怨数据库

65 楼 lilei9963 2009-01-08  

刚300W,数据量也不大啊.

64 楼 LucasLee 2008-12-25  

xlongbuilder 写道

谢谢各位的回复

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

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

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

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

你看你自己说的，没有任何索引优化措施...我就说了，你同样这样不建索引的话，你就是搞上最高版本的Oracle也白搭！
基本上不客气地说，你们是不会用数据库，所以给你们啥高级数据库也无法缓解你们的问题。
除非有傻瓜化的数据库，能自动考虑如何建索引的（好像还没听说过）。

索引是最基本的，通常也是最有效的优化方式。
什么表分区之类那都是后续招数了。

63 楼 younggun 2008-11-17  

按照这样的服务器，几百万数据一般来说应该是没有什么问题的，先分析一下系统的瓶颈吧

62 楼 atian25 2008-11-17  

8个月主要表每张产生了近300万条数据

这个数据量不算大吧.以前用sybase做项目的时候,都是日分表的,单某个表都日增300w.

61 楼 runthu 2008-07-14  

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

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

60 楼 xlongbuilder 2008-07-10  

liuzongan 写道

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

链接打不开

59 楼 xlongbuilder 2008-07-10  

谢谢各位的回复

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

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

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

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

58 楼 zt371 2008-07-04  

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

57 楼 liuzongan 2008-07-02  

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

56 楼 ironsabre 2008-07-01  

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

55 楼 jameswxx 2008-07-01  

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

54 楼 wlei9802 2008-06-30  

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

53 楼 ziyuan 2008-06-30  

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

52 楼 csrcom 2008-06-30  

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

51 楼 zhuyx808 2008-06-30  

cuiyi.crazy 写道

eastPoint 写道

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

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

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

SQL Server也有表分区的啊

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


MSSQL 确实容易死锁的说

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

50 楼 ccxw1983 2008-06-27  

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

49 楼 cuiyi.crazy 2008-06-27  

eastPoint 写道

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

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

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

SQL Server也有表分区的啊

48 楼 dy.f 2008-06-27  

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

47 楼 licco1 2008-06-26  

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