背景

在数据量过大时，常见的做法是将数据按部分归档键进行归档，当然可能是不同数据库，在报表的查询或者常规业务查询时， 往往需要合并多处的数据源，这时就需要一些小框架来支持，减少业务代码。

关于名字

1. 一开始因为数据分片的原因, 叫sharding；
2. 不满意后面因为数据组合，所以改叫compose；
3. 后来看了hadoop mapReduce，感觉有那么点意思（蹭蹭蹭。。。），改叫map-reduce了。
4. 其实主要做的事情，是归档数据处理，但是暂时不改名字，等缘分。

归档键：在demo中，归档键是high、low, 表示数据按这几个字段分别做多级归档，每级归档数据由一个归档实现处理。 归档实现：在demo中，OrderService 有一个Mongo和5个Mysql的归档实现。

需求

参数解析，取归档键

1. 通过反射获取
2. 通过spEl解析
3. 通过实现特定的接口获取。

参数处理这里有个影响因素：数据在不同数据库之间是否有冗余（例如A区的范围是1-10, 由于数据安全考虑有冗余，实际为1-15， B区的范围是11-20））， 如果有冗余，需要考虑重设查询参数。比如查询8-12，那么查询A区时，应该通过8-10去查，查询B区用11-12去查，这样才不用考虑想通数据归并的问题。 类 com.zhuojl.map.reduce.ComposeParamHandler就是这个作用。

在以前的实现中考虑了数据重复的问题，在后续的设计中，不考虑数据冗余的情况，通过spEl解析分片键。

请求路由

归档常按日期进行归档，比如一年前查某个mongo库，一月前查规格高一些的mongo库，一月内查mysql等。 根据查询的时间区间来确认需要查询哪类库。

结果集归并

这个实现比较简单，尽量减少业务的配置

分页

前期是很纠结这个，因为的确很难排序分页，内存和时间复杂度都支持不了，目前我们的框架和另外一个团队是按照先取热库再取冷库的方式来处理的。 这样总算有个解。

在现有的实现，参见ExecuteMode.PAGE描述

设计

疑惑