以前做过一个打包下发查询（从设备查询）的组件，再在基础上做策略，把应用软件的性能提升了1－2个数量级。

?

现在以数据库为中心的软件设计中，设计中除了要利用nosql数据库中schema-free这种特性外（长项）。应用层，还要承担一些数据库的短项的工作，如关联查询，利用业务场景更智能的查询。从而提升性能。性能的提升主要是从应用场景和架构来提升。比如，不做过度复杂的设计。做一些针对具体业务场景的智能化和优化。

?

下面一个场景就是优化一列。

?

1.?很多任务，不做关联查询。把数据从资源里复制一份。实在找不到资源了，再让到前台去后台查询。这种设计看起来很简单，但数据重复，不能保持致性。另外，增加了前台业务逻辑，这个逻辑的复杂会让系统更加不稳定和不可靠。所以，简单粗暴的设计肯定是不行的，如果这个方法很笨，但肯定还有更好的方法没有被找到。

?

Completed 200 OK in 21ms (Views: 7.7ms)

?

这种方法rails查询完成是21ms。把业务复杂度推给了前台，以数据重复存储，不一致性，降低可靠性为代价。

2.?查询每一个任务都去查一下相关的资源，这样的好处是查询逻辑很简单。但来的问题是，做了大量关联查询。如25个任务，则要做25条关联查询。这样性能就不能达到基线了，光是25个任务就用了106ms.

Completed 200 OK in 106ms (Views: 37.8ms)

?

3.?最后的方案是查询还是做在后台，前台在得到任务的时候得到相关资源。优化的方案就是打包查询，如25个任务合并一起来，做一次数据库查询。再由应用层把查询结果塞到对象里去。

?

Completed 200 OK in 48ms (Views: 30.7ms)

这样，性能达到基线。整体业务逻辑没有变复杂，可靠性没有下降。