大数据量的数据库设计

现在产品升级，数据库要重新设计，像全省的数据量太大了，数据库总是出问题，有几张表里面，一年的数据量大概有700到1000万条记录的样子，所以在这里面操作起来很慢，然后系统的并发量也很大，平均下来，大概70个请求/s，原来的老系统不怎么稳定，但是在这表里面的数据，有个特点，就是最近一个月的数据才会看，那些比较老的数据，在做年度报表，决策分析的时候，才会用到，所以想把那几个数据量很大的表的物理存储重新设计。
目前想到的第一种就是按照月来分，每个月让系统自动建一张表，然后把这个月的数据放在这个表里面，这样，每个月这个表的数据量大概只有几十万条，比以前就少多了，但是这样在做年度报表和决策分析的时候，就麻烦了，一年下来，就会有12表，要在这12张表里面，还要和其他的表的关联，这样做起来，也会很麻烦，数据库也未必受的了，第二种，就是用一个备份的数据服务器，把每个月的数据都导出到那个备份服务器上去，在备份服务器上面数据的存储不按月来分，按照年来分，每年建一张新表，做报表的时候，就到备份服务器上面操作。第三种，就是对这几张表用对象数据库，来存储一个月的数据，这数据是在内存的，操作起来，比操作关系数据库快，前段时间的数据还是放在关系数据库里面，这样就可以不用数据备份服务器了

大家遇到这种大数据量的问题，是怎么处理，给点意见

一年700-7000万条，70q/s，这个能算是数据量很大并发很大？一般数据库都能轻松处理吧。注意数据库配置、索引就可以了。

这个700到1000万,是一张表里面的数据，不是所有表加起来的数据，而且像这样的表有好几个，70q/s是平均值，不是最大值，高峰期的时候，会超过300q/s，现在系统不稳定的原因在数据库端，而且索引做多了，对插入数据也是有影响的，我觉得只是弄一下数据库的配置和索引，这样不能轻松对付吧

最简单的方法，就是利用数据库的表分区功能，这个功能Oracle,SqlServer2005都支持的。就利用表的时间字段来进行分区就可以了。这样按日期进行查询的时候速度比普通索引要快很多。

LZ的数据量其实并不算大，可以说如果对于oracle这样的数据库简直就是小菜。每天晚上可以定时做索引，定期做物理备份。

select count(1) from ......oracle这样的数据库简直就是小菜???????????????????

在既存的表的基础上，建一张表结构相同的履历表
在每个月的月末（当月处理结束）的时候，把当月的数据用一个月次batch转移到履历表中
再建一个view基于当月数据表和履历表的view，专门给年度报表，决策分析处理用

分区表就好了，没必要一个月一张表

再在“履历表”（这个用词很别扭，日语里的叫法？历史数据表、后备表？）上使用多字段表分区（Oracle支持多字段表分区）技巧，解决统计和数据分析查询的效率问题，两个方法结合，可以说是比较完美的办法。