风控系统的性能测试揭示了数据库查询效率问题，主要由于数据集中导致索引未有效利用。通过调整数据分布、创建复合索引和优化执行计划，显著提升了查询速度。在面对数据集中的挑战时，结合数据库与Lucene文件索引可提供实时且高效的解决方案。测试表明，适时的数据分散和系统优化策略是关键。
反欺诈经过一周的性能测试，问题找到了也算是解决了。具体效果还得看真实环境。
数据库服务器的配置: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多毫秒。
其实这里面最主要的问题就是数据集中。因此做性能或压力测试时要注意这方面的问题。当数据不是问题的时候组合索引和计划任务优化才是着重考虑的方面。
从另一个
最低0.47元/天 解锁文章
扫一扫
1988
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
