关于大数据量查询接口优化的设计方案

前言

最近在做看板相关的项目，主要在做数据清洗和数据运算这块的东西，逻辑链路不长，就是各种奇形怪状的运算规则太折磨人了，也没法抽象出一些运算模块或者通用的工具类。本来以为一直都是搬砖来着，没想到遇到一个有意思的问题，网上百度了半天也没有合适的法子，所以自己就整了个野路子，算是一点不成熟的想法，但是夹杂了一些知识点，个人感觉还是有点意思，所以放了上来，希望对同样受难的读者们有所帮助。

需求及现状说明

需求简述

如上图，一共四个查询条件，高低版本、物料编码、波动风险，只有波动风险是固定的字典值，即高中低，其它三个都是从数据源中获取。

数据A来源于外系统Oracle多版本数据的去重。数据B来源于外系统同事给的一条查询SQL，入参有高低版本的快照时间。数据C需要根据数据D的数据通过公式得到结果。数据D需要从外系统获取每天的数据，计算低版本对应快照时间的未来9周+10月(约为1年)的数据，不同类型(例如低版本需求)有不同的计算公式。

在以上基础上需要根据查询条件分页。

当前看板列表是以物料为维度进行汇总，除此维度还需要供应商、采购员、大类、小类进行汇总。开发时间平摊下来一个人约1天处理这个列表，算上5个维度冗余的时间，大致会有两天半的时候做整个看板的数据库设计、方案设计以及代码实现。

问题描述

开发时间短

时间短这个不必多说，在对接了ERP提供的数据后，我突然发现大数据量成了瓶颈，在我完成最终的初版逻辑后运行，发现查询时间达到了半小时……然后我尝试放在redis里，发现最后筛选出来的数据有12mb，redis连接超时，大key问题…...麻了，问题很多，关键这是个查询接口，我只有两天不到的时间(不要问我为啥时间这么紧，问就是敏捷开发，"简单")

无法提前计算

所有性能问题的来源就在于无法提前计算，这样一个查询接口我需要拉取外系统、计算未来一年的数据，最重要的一个原因就是强关联的高低版本号是页面动态选择的。一年按周排除节假日会有约50个版本号，两两配对会有1225种情况。假设我提前算一年的数据，也就是每增加一个版本号，需要多算49版数据。列表有五大维度，物料、供应商、大类、小类和采购员，需要根据维度汇总数据，每个版本的物料数量差别不大，假设都是4000颗，也就是说提前计算一年的版本号的数据，会有1225x4000，这还是一个维度，并且数据量膨胀非常快

大量字段需要SQL读取或者运算

计算数据BCD，共需要如下4条SQL填充字段或者提供数据运算

1. 根据数据A中的版本号、开始时间、结束时间获取一段时间内该版本号对应的需求数量、需求日期
2. 根据数据A中的组织、供应商获取库存
3. 如果当前是物料维度࿰