讨论：随着数据量的日益增长，你想做数据库优化还是数据库架构设计？

alantany

随着数据库中数据量越来越大,性能问题变成前所未有的重要.
数据库的性能优化更像是一个微观层面范畴,而架构设计就像是一个宏观层面的范畴.
性能优化对数据库非常重要，但是架构设计对系统的性能具有决定性的作用。

大家更喜欢做哪一个呢？你会把哪一个作为你的职业规划呢？
欢迎参与讨论。

活动时间：
2012年7月9日—7月16日

活动奖励：
活动结束，将评选出五位分享最认真的会员赠与由我编写的《让oracle跑的更快2》一本。欢迎大家多多参与！

图书信息：


作　　者： 谭怀远 著
丛 书 名：ITPUB技术丛书

本期活动获奖会员：
wanenjie
jimn1982
mr_linzi
htyansp
miniid1

过过招

都喜欢。

他们往往是唇齿相依的，不是有那么一句话么：90%以上的性能，是设计出来的。

一旦结构设计定型，优化所能做的事，通常是非常有限的。

dingjun123

全做了，神马乱七八糟的全做了，从后台干到前台，从主机干到web页面

buptdream

先进行优良设计，再搞数据优化。

hwtong

说实在的 感觉架构应该会更有含金量的吧.
但是两个是不同的方面
架构 主要涉及到对硬件的一些了解.比如Server 网络设备等
但是数据库调优就主要是数据库的事了,当然也会了解一些硬件的东西.

wanenjie

我会选择调整架构，再进行调优。因为如果架构有问题，调优所起到的作用往往非常有限。最近遇到的一个数据库调优问题，先说说环境，请看下图

数据过于集中在总部业务系统数据库上，导致运行慢，每天产生归档数据大（一天约20G归档），锁紧张激烈，分店日结不完成不能进行数据分析，这个明显是系统问题，现在要做的1.把历史数据先从业务服务器移到BI上面，释放资源将历史查询功能先分离出来。2.分店销售日结JOB由每3小时传送一次改为12小时。3，分店销售上传到BI上，不要到核心业务数据库，通过DBLINK在BI上查询，有需要再插入到核心数据库中。

这些搞完再看TOP 5 SQL那些东西等，好多同时都觉得这个系统非常垃圾，不过领导当时上错没办法只是强行在使用，问题突然问题个人觉得是系统架构导致性能慢下来，不需要中间层的地方加了，需要的又不加~！

wanenjie

不知道这样搞是不是比较正确，请各位指导一下·！初步把历史数据移走，性能提高15%~！

nannan5000

没有好的设计
再优化也白搭。
所以要做设计！

jimn1982

首先我认为前期的调研很重要。非常重要。业务系统预计会有多少数据量，多少并发等等。
在此基础上设计的整体架构比后期的优化更重要。
地基不牢怎么能在此基础上盖更高更好的房子。盖上去也得塌下来。
就一豆腐渣工程。
就我们公司现在的系统，
业务挺简单，数据量一天两百万条记录，数据全部放一张表中，表中42个字段，web页面有查询更新等操作。有分页。
运行半年后，查询反应非常慢。做了以下调整：
1，分成历史和当天表。
2，WEB页面查询改成调用后台PROC。
3，把表做成分区表。
4，建全局索引（考虑过分区本地索引，但是效果不好）。
5，一次查询多页数据缓冲，不像以前翻一页查一次，数据库都忙不过来，还得查询总记录数。
6，查询时间长度做限制，前台发送一个语句查询一年的数据总数。再强的数据库都不一定能抗得过来吧。
7，感觉web页面把太多的压力都扔到了后台搞。不负责任。
8，再接下去删除数据，垃圾旧数据早该滚蛋了。

如果原先的架构不合理又不好改动，只能在豆腐渣工程上做优化了，我认为优化的效果还是得根据业务来。

bluemoon0083

肯定是架构设计了