性能优化是个手艺活

大数据的技术本质就是高性能，性能优化也是程序员们的永恒话题。

这里说的性能优化，主要是指在程序员的努力下能达到某种性能提高效果的过程。只要简单换台机器就能加速的事情，业主方要么早就作过了，要么就是条件不容许这么作。

这时候，优化方案的关键在于算法，具体来说，就是要设计出低复杂度的计算方案。咱们说过屡次，软件不可能提升硬件的性能，只有采用了低复杂度的算法，也就是计算规模有了实质性的降低时，才可能在相同硬件环境下得到更优的性能。

不幸的是，这类方案一般都是定制化的，换一个场景可能就没有效果了。换句话说，这些方案是专门为某个计算任务设计的。

以分组运算举例：若是咱们事先知道GROUP BY的结果集很小（能够在内存中放下），那么单次遍历不须要生成临时外存数据就能够完成运算，并且也容易采用并行计算。而若是结果集很大、内存没法装下时，则须要生成临时缓存数据用于保持中间结果，而这时候也几乎不可能再用并行机制，由于外存的并发冲突常常会抵销掉并行带来的好处。而若是咱们知道用于分组的数据已经针对分组字段有序时，则即便是大结果集也能够没必要生成临时缓存数据，这样又能够采起并行计算的手段来提升性能。反过来，若是咱们在大结果集时使用了小结果集的算法，那就会致使内存溢出；而在无序状况下使用了有序算法，则会得出错误的计算结果。

也就是说，看起来很是相似的计算任务，在不一样场景下会采用很不同的动做，这须要了解计算和数据特征才能作出选择。

若是要考虑通用的场景，那只能使用最保守的算法。对于分组运算来说，也就是使用大结果集且数据无序的算法，这样虽然能保证正确计算出结果，但性能就会不好。

这样，性能优化就是个手艺活了！

手艺活须要就事论事地精雕细刻，这又须要咱们手里有个好工具，可以让咱们快速实现设计出来的计算方案，不能发生想出好算法却没法实现的迥境。

做为当前数据计算主流的传统关系数据库在这方面作得不好。SQL提供的运算太少，并且透明度太高，程序员对计算过程的控制力度很弱，很难实现本身的想法。好比上面说过几种在某些场景下能够提高性能的分组算法，SQL都没有直接在语法层面上提供，只能期望数据库引擎的自动优化，而这又严重依赖于数据库系统以及当前场景的复杂性，这就常常会发生咱们明知有好算法却无能为力的现象。