千万表级联查询优化

需求背景:
某大型物流公司CRM提供可视化营销功能,一线员工可以在界面中直接按条件搜索到本门店下属各个用户:潜在客户,大客户,散户等,并显示用户的各种数据:基本信息,来源信息,花费金额,花费频率,回访信息,统计报表等数据;
涉及到表 :用户表基本信息表,用户附加信息表,订单表,用户来源表
表基数:用户表1000万,附加信息3000万,订单表5000万,用户来源表1000万
正式进入查询阶段:
第一阶段sql查询:在数据库中添加相应索引,通过条件减少sql执行时,搜索范围
优化结果:12秒完成一次搜索
第二阶段数据表结构优化:相应的表添加分区,以部分为分区单位进行range分区,
优化结果:5秒完成一次搜索
压测结果:30并发下,数据库CPU消耗达到85%
成本增加:多张表分区的维护成本:分区带来在线重定义工作,分区后全局索引重建,分区索引重建等工作量
第三阶段数据表结构优化: 在1,2基础上,增加统计数据部分的物化视图,中间表
优化结果:1.2秒完成一次搜索,
压测结果:通过50并发压测,数据库CPU消耗在70%以内,其他指标正常
成本增加: 中间表的维护,增量更新脚本,全量恢复脚本;物化视图的维护成本,增量更新脚本

一个半月终于将这么看似庞大且操蛋的需求完成了,过程中基本天天泡在DBA哪里,优化sql,优化数据表,任何一个又可能的过程都不会放过,险些转行做了DBA;当时感觉是一个很屌的一个成果,但是现在看来,很多需要反思之处!!!
总结一下:对于千万级别的数据而已,说大不大说小不小,一般这个级别SQL本身的查询优化以及很乏力了,需要依靠数据表结构 数据库层的一些优化才能够到达预期的目标,而且会因为这些的增加,增加很多其他的维护成本:多出来很多中间表,中间表的维护脚本,增量更新的脚步等等,有时候也要考虑一下这些成本的增加是否值得或者适合,或者可以考虑一下新型的技术来解决比如spark/strom等新型的数据处理技术,但是这样成本会更高一点点,需要全面的权衡

你可能感兴趣的:(oracle,物流,大表查询)