设计的问题？？

Question

一条记录有300字节一小时的量有500万,每秒有1400多的记录，要插入库
这个数据库同时还要 支持其它的一些应用这个设计，这个些记录是先存在文件里，然后每小时分析库入库里，还是每向几分钟一个批处理存入库里
哪种设计效率会更好，或者还有什么其它的方法这些记录就算用分区数据量也这个表的量也会很大，有什么好方法数据库是oralce 
 

Answer 1

存在文本文件，然后每小时用 sql loader来提取数据

Answer 2

如果对数据延时要求不是很高的话，时间越长，累积数据量越大，LOAD的效率会越好。分区必定要做，表中的数据没有索引就是垃圾，如果不使用分区来减少索引的体积，LOAD的效率在最后就可想而知了。当然你也可以保证分区没有数据更新后再建立索引。另外，LOAD尽量避免向多个分区灌入数据，这样也会降低LOAD效率。

Answer 3

Oracle 有那个每天自动插入数据的机制，很好狠强大。
当然是在每天的晚上或者固定的一段时间进行系统备份，但同时也要向数据库插入数据。
楼上说的很好，对于你这种插入频率搞，量大的选手一定要分清几个地方、再插入。

Answer 4

个人的一些想法，供楼主参考，请大家指正：
1.这些记录生成文件后，是否存在当天对这些数据查询的实时性要求 =》决定入库是否的实时性
2.数据库的忙闲时间如何：高峰时段，空闲时段，其它时间压力情况 =》如果1）的实时性要求不高，可以考虑在非忙时入库
3.这些记录生成的文件是否有一定规则，比如按一定时间存放到相同文件等 =》作为表分区创建规则，以及并行导入的依据
4.每小时或每天产生记录是否入库到同一个表，还是有一定的分表规则 =》同上
5.这些记录入库后是否需要更新(DML)，还是作为历史沉淀数据，定期清理等 =》作为是否需要建索引的依据
PS: 楼上多位同志已经提到了用sqlldr导入，按楼主提供的数据，每小时大概生成500W/1.4G的数据,sqlldr导入应该还快的（如果主机不会太差的话）

Answer 5

像这样的数据大小，oracle10g每秒可以承受多大的数据 量

Answer 6

可承受的数据量要看存储是否足够
另外按楼主提供数据，在无索引情况下：数据增长速度大概为1.4G/小时，33.5G/天，一个月的增长总量将近1TB
这么大的量，应该会考虑历史数据清理机制的吧，或者容灾备份历史数据，当前生产保留最近N天或几个月的数据