反欺诈经过一周的性能测试,问题找到了也算是解决了。具体效果还得看真实环境。
数据库服务器的配置: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多毫秒。
其实这里面最主要的问题就是数据集中。因此做性能或压力测试时要注意这方面的问题。当数据不是问题的时候组合索引和计划任务优化