反欺诈经过一周的性能测试，问题找到了也算是解决了。具体效果还得看真实环境。
数据库服务器的配置:16U,16G内存,Oracle 10G
测试工具:Road runner
主要涉及到的表6张，其中三张将近200万数据，另三张各将近20成。
中间经历了服务器无法正常响应,响应过慢,数据库CPU和数据库负载过高.
这些其实都与一个数据的执行效率有直接关系。因为风控设置的规则,特别是频率规则全部统计查询,十分耗资源.
第一感觉是检查SQL和优化数据库.
于是检查了SQL,去掉了一些不必要的表关联,再将相关表建上索引,可仍然没有明显改进.于是想到是不是因为大表关联响应性能了,打算合表,
之后和同事的沟通以及DBA的确认,认为大表关联还不是目前主要的问题.后来也证明了这一点.其实主要原因是表上的索引没用上。这跟oracl数据库的索引策略有关,当需要访问的数据超过所有数据的15%后 会导致索引全扫描。这就是数据集中的问题。
因为测试的时候某些字段是一样的,而SQL语句正好使用到这些字段查询,这就不可能走索引了。后来根据DBA的建议，手工将数据打散，打散
成1:100,即1%的数据重复率。效果马上显现出来了。起码能正常响应，只是速度还稍慢。DBA再建组合索引以及更改执行计划。性能再次提高
，实践证明执行计划优化很重要(目前线上环境的oracle采用基于成本的策略)。所有这些都做完以后离目标还是有挺大距离，到这时，DBA的结论是
从数据库方面来讲主要的性能提升方法已经用完了。说到底还是数据集中问题。根据数据统计的top 25大buyer订单率,再次将数据打散成1:1000,这时候执行几十个统计查询一共花费的平均时间为400多毫秒。
其实这里面最主要的问题就是数据集中。因此做性能或压力测试时要注意这方面的问题。当数据不是问题的时候组合索引和计划任务优化才是着重考虑的方面。
从另一个方面来说，其实我们也要考虑如果某些表的数据就是很集中如何处理。至少目前给我的感觉就是数据库对于 这类问题可能确实没办法，当然还可以根据实际情况来优化,某些情况下可以对表分区。如果数据确实无法达到性能要求的时候，必然要走非数据方式。比如用文件 索引lucene.基于当前风控的情况，其实可以考虑用数据库和lucene结合的方式。因为这里的统计都是基于时间段的，假如我们两天内的查询在数据库 完成，其余的通过lucene完成。这样做不但速度上有保证，而且是实时的。另外还有个好处就是,基于lucene的搜索服务器可以不断的扩展而且方便, 只是多布置一个应用而已,而数据库做起来就没它方便。
一点体会：如果事情不如预期那样完美，绝不要一味的想着非得解决掉，否则结果可能会令自己垂头丧气。这就有一个取舍，如果风险有较大把握控制得住，问题就可以先搁一边，也允许有问题，因为现在花大量的时间去解决一个未来可能存在的问题显得有点得不偿失，除非你有足够的时间，现实情况是时间总是不够用。而且就近一年时间的业务来看，性能不太可能成为问题。即使有问题了，到时候可以用其它的办法， 没必要非在这一点较真。 相信能想出办法，之前在搜索组里经验告诉我，没有想不出的解决方案，当然这里跟很多因素有关。