相老师您好：
            我是您去年教过的学生，听过您的课真是受益匪浅，在此先郑重的表示感谢。
           先说一下我们的系统架构，目前我们这个系统是处理电信业务的，所以数据量非常大，每个小时采集的mr数据一个省市大概有20~50g的数据，数据是实时录入的，前端是N个采集数据的pc，每个采集机采集不同的小区，您可以理解为不同的地理位置的数据，经过信令解析程序处理然后把数据全部汇总到数据库中，最后再由数据库的procedure根据业务的需要进行数据汇总。针对这种数据量我们已经按小时做了分区，然后再在小时分区的基础之上进行二级分区，结合物化视图的功能,并行处理的技术以及rac的读写分离设计，在部分业务的查询速度上已经可以达到满足用户的需求，但是对于其中的一些业务比如用户信息的汇总，由于每个前端机采集的用户信息可能一样， 所以录入到数据库中后，实际上按时间做分区已经做不到分区消除的功能了，并且如果按用户分区也是很不现实的，毕竟用户的数据量很多。所以按现在的方式俩表一连接然后做分组聚合oracle基本汇不出来结果，oracle汇不出来结果就造成新录入数据的堆积，使数据存储占用很大地方，并且经过测试oracle的普通表存储的数据基本和存储到文本的大小一致，采用压缩表的话会能减少40%~50%,数据块的大小我们这边基本是16k，但由于指标比较多一般一个表都是在300~500的字段，一般要多个块才能存储一行，所以查询必然要同时读取多个块 这个也是很无语的。硬件方面我们是用的 m5000或者一些小鸡，基本属于中配的设备。根据这种应用场景我也参考了像 infobright这种的列式存储的数据库 他在汇总方面性能很好，但对于小数据量的查询以及价格很难让人接受，主要是还是价格问题，免费版的不支持dml操作，mysql cluster问了一下新浪的首席mysql DBA他觉得我们这种应用也不适合用mysql cluster，map reduce 这种东西还不是很了解，也就是所谓的云运算吧，目前我没找到相关人士可以深入了解这种东西应用场景。说了一堆主要目前想解决的问题就是汇总速度以及存储占用量的问题。希望相老师能针对这种应用的选型和设计的给一些建议参考。徒弟不胜感激!
                                                                                                                                      zhoubo

我关心两个问题：
1、你的分区机制，是否需要做分区置换和分区删除
2、RAC的节点数，是否能够实现不同的业务模块，采用不同的节点来实现（前提是cache fusion不要太大）
3、可以考虑timesten

LZ的分区是range-list分区(小时-地域)的吗？
由于每个前端机采集的用户信息可能一样， 所以录入到数据库中后，实际上按时间做分区已经做不到分区消除的功能了
为什么做不到分区消除？是不是汇总统计的需求不是以时间分组？（如：假如以地域分组）这时也能使用到分区消除不过过滤的分区可能不多，因为主分区是时间。感觉好像LZ的业务分为两大部分，一部分是常规的需求，这部分以时间作为查询条件，这时可以很好的实现分区消除，所以性能很好；另外一部分是用来汇总统计的，这部分是两张表做连接查询，然后对结果做统计，这两张表的连接条件不是以时间作为条件吧，所以分区消除的效果比较差。有没有办法把这两张表做到一张表中呢？到统计时就能省去表连接带来的开销（可能性很小呀）。

oracle汇不出来结果就造成新录入数据的堆积
按照这个说法来看，是不是经过汇总的数据就会从数据库中移除或分区交换出去？这个操作是不是通过一个JOB来完成的，比如每天定时汇总，汇总完毕后自动执行分区交换等操作。

但由于指标比较多一般一个表都是在300~500的字段，一般要多个块才能存储一行，所以查询必然要同时读取多个块
那也就是说每一条记录都发生了行迁移，则样的话对于索引扫描的代价是非常大的，有没有可能重新设计DB_BLOCK_SIZE?

另外很小心问一句，RAC能够实现读写分离吗？即使LZ的业务实现了分离，不同的业务使用不同的实例，但是他们都是使用共享存储呀，读写都使用共享存储，一直以来我都认为只有类似DG、STREAM等技术可以实现读写分离，这样来减轻主服务器的压力。如理解错误还请LZ指出；

嗯。这个可以学习。

RAC实现不了读写分离，huadaonan同学，你一定要关注一些RAC里面的等待事件，特别是和gc buffer相关的等待事件。
你的分区有问题、你的RAC设计也有问题。
另外，你的数据做置换吗？
对于有问题的SQL语句，你可以做执行计划来看一下，特别是需要加上谓词。

楼主的项目很像我之间参与的一个电信的BI项目，以下个人建议请LZ参考：

建议LZ初期的时候先不要考虑大量使用物化视图和并行查询这种解决方案，这解决不了本质问题。前期应该多从架构上考虑
1、将省市、业务类型等建立维表，数据表的相应字段与维表关联，尽可能的减少数据表的大小
2、汇总数据的时候不要从原始数据直接汇总一口气出结果，建议逻辑上划分为3个层次，接口层（原始数据）、汇总层（根据业务需求对原始数据进行过滤汇总）、展现层（对汇总数据进行最终汇总出结果，用户指访问展现层的表）
3、基于第2条，考虑将接口层的表设置为nologing，并且使用直接路径插入，接口表不建立索引，合理使用分区，如果条件允许业务有需要对原始数据排序后录入；
4、索引建立在展现层
目前就想到这些，总之想尽一切办法减少IO，分区是关键，索引只是辅助作用，建议LZ把重点放在分区上

如果你这么做的话，会带来一个问题，那就是数据不同步。
如果数据不同步允许的话，倒是可以考虑这个。