性能優化是個手藝活

大數據的技術本質就是高性能，性能優化也是程序員們的永恆話題。

這裏說的性能優化，主要是指在程序員的努力下能達到某種性能提高效果的過程。只要簡單換臺機器就能加速的事情，業主方要麼早就作過了，要麼就是條件不容許這麼作。

這時候，優化方案的關鍵在於算法，具體來說，就是要設計出低複雜度的計算方案。咱們說過屢次，軟件不可能提升硬件的性能，只有採用了低複雜度的算法，也就是計算規模有了實質性的降低時，纔可能在相同硬件環境下得到更優的性能。

不幸的是，這類方案一般都是定製化的，換一個場景可能就沒有效果了。換句話說，這些方案是專門爲某個計算任務設計的。

以分組運算舉例：若是咱們事先知道GROUP BY的結果集很小（能夠在內存中放下），那麼單次遍歷不須要生成臨時外存數據就能夠完成運算，並且也容易採用並行計算。而若是結果集很大、內存沒法裝下時，則須要生成臨時緩存數據用於保持中間結果，而這時候也幾乎不可能再用並行機制，由於外存的併發衝突常常會抵銷掉並行帶來的好處。而若是咱們知道用於分組的數據已經針對分組字段有序時，則即便是大結果集也能夠沒必要生成臨時緩存數據，這樣又能夠採起並行計算的手段來提升性能。反過來，若是咱們在大結果集時使用了小結果集的算法，那就會致使內存溢出；而在無序狀況下使用了有序算法，則會得出錯誤的計算結果。

也就是說，看起來很是相似的計算任務，在不一樣場景下會採用很不同的動做，這須要瞭解計算和數據特徵才能作出選擇。

若是要考慮通用的場景，那隻能使用最保守的算法。對於分組運算來說，也就是使用大結果集且數據無序的算法，這樣雖然能保證正確計算出結果，但性能就會不好。

這樣，性能優化就是個手藝活了！

手藝活須要就事論事地精雕細刻，這又須要咱們手裏有個好工具，可以讓咱們快速實現設計出來的計算方案，不能發生想出好算法卻沒法實現的迥境。

做爲當前數據計算主流的傳統關係數據庫在這方面作得不好。SQL提供的運算太少，並且透明度太高，程序員對計算過程的控制力度很弱，很難實現本身的想法。好比上面說過幾種在某些場景下能夠提高性能的分組算法，SQL都沒有直接在語法層面上提供，只能期望數據庫引擎的自動優化，而這又嚴重依賴於數據庫系統以及當前場景的複雜性，這就常常會發生咱們明知有好算法卻無能爲力的現象。