Greenplum實戰之查詢優化

本文主要分爲三部分：

1. GP優化須要準備的一些關於優化以外的知識，包括清空緩存、性能監控、執行計劃分析。
2. 具體優化措施，從如下四個方面考慮：

• 表、字段
• sql
• GP配置、服務器配置
• 硬件及節點資源

1. GP的性能極限分析

1. 前置知識

1.1 GP清除緩存

數據庫通常都有緩存，因此咱們爲了測試查詢性能，須要將緩存清除。

中止數據庫並不能清空緩存,由於緩存是由操做系統建立的,通常只有重啓操做系統能夠徹底清空.
參考思路以下：

#!/usr/bin/sudo bash

gpstop -r

sync      //清空高速緩存前嘗試將數據刷新至磁盤

//釋放linux內存
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches

gpstart

1.2 性能監控Performance Monitor

新一代Greenplum監控管理平臺Pivotal Greenplum Command Center (GPCC)。

實際使用過程當中發現對於6-8秒的查詢（單表億級數據），GPCC反應比較慢，CPU、IO等信息爲0，目前擬採用其餘工具，實時監控CPU、內存、IO、網絡等信息。

1.3 執行計劃分析

• EXPLAIN會爲查詢顯示其查詢計劃和估算的代價，可是不執行該查詢。
• EXPLAIN ANALYZE除了顯示查詢的查詢計劃以外，還會執行該查詢。EXPLAIN ANALYZE會丟掉任何來自SELECT語句的輸出，可是該語句中的其餘操做會被執行（例如INSERT、UPDATE或者DELETE）。

http://www.javashuo.com/article/p-mynyvdxx-eh.html

slice、motion

GPDB 有一個特有的算子：移動（ motion ）。移動操做涉及到查詢處理期間在 Segment 之間移動數據。motion 分爲廣播（ broadcast ）、重分佈（ redistribute motion ）、Gather motion。正是 motion 算子將查詢計劃分割爲一個個 slice ，上一層 slice 對應的進程會讀取下一層各個 slice 進程廣播或重分佈的數據，而後進行計算。

每個廣播或重分佈或gather會產生一個slice。每個切片在每一個數據節點會對應發起一個進程來處理該slice負責的數據。SQL中要控制切片的數量，若是太多，應適當將sql拆分，避免因爲進程太多，給數據庫、機器帶來太多的負擔，也容易致使sql失效。

Gather motion的做用就在於將每一個節點上面的中間結果集中到主節點上面。

優化

總的思路

• 表、字段
• sql
• GP配置、OS配置
• 硬件及節點資源

一、表字段設計

• PostgreSQL 用CPU "硬解碼" 提高1倍 數值運算能力 助力金融大數據量計算

如上面例子所示，優化某些字段的設計，以提升性能

二、表存儲方式

Heap 或 Append-Only存儲：GP默認使用堆表。堆表最好用在小表，如：維表(初始化後常常更新)。Append-Only表不能update和delete。通常用來作批量數據導入。 不建議單行插入。

多列查詢請求

• 行存儲 => 在select或where子句中，查詢全部列或大部分列
• 列存儲 => 在where或having子句中，查詢單列的值彙總或單行過濾

若數據須要頻繁地更新或者插入，則使用行存儲。
若須要同時訪問一個表的不少字段，則使用行存儲。
對於通用或者混合型業務，建議使用行存儲。
若查詢訪問的字段數目較少，或者僅在少許字段上進行聚合操做，則使用列存儲。
若僅經常修改表的某一字段而不修改其餘字段，則使用列存儲。

三、壓縮

對於大AO表和分區表使用壓縮，以提升系統I/O。
在字段級別配置壓縮。
考慮壓縮比和壓縮性能之間的平衡。

壓縮的性能取決於硬件、查詢調優設置、其它因素。

• QuickLZ - 低壓縮率、低cpu消耗、壓縮數據塊
• zlib - 高壓縮率、低速

四、列存儲
列存裏面能夠啓動壓縮。

只適合append-only表。

五、索引
高基數的列（惟一值多）

通常來講，在Greenplum數據庫中索引不是必需的。
對於高基數的列存儲表，若是須要遍歷且查詢選擇性較高，則建立單列索引。
頻繁更新的列不要創建索引。
在加載大量數據以前刪除索引，加載結束後再從新建立索引。
優先使用 B 樹索引。
不要爲須要頻繁更新的字段建立位圖索引。
不要爲惟一性字段、基數很是高或者很是低的字段建立位圖索引。
不要爲事務性負載建立位圖索引。
通常來講不要索引分區表。若是須要創建索引，則選擇與分區鍵不一樣的字段。

可優化部分小結果集查詢。

六、分佈鍵
七、 分組擴展
Greenplum數據庫的GROUP BY擴展能夠執行某些經常使用的計算，且比應用程序或者存儲過程效率高。

GROUP BY ROLLUP(col1, col2, col3)
    GROUP BY CUBE(col1, col2, col3)
    GROUP BY GROUPING SETS((col1, col2), (col1, col3))

八、分區

黃金法則

目前Greenplum支持LIST和RANGE兩種分區類型。

分區的目的是儘量的縮小QUERY須要掃描的數據量，所以必須和查詢條件相關聯。

只爲大表設置分區，不要爲小表設置分區。
僅在根據查詢條件能夠實現分區裁剪時使用分區表。
建議優先使用範圍 (Range) 分區，不然使用列表 (List) 分區。
根據查詢特色合理設置分區。
不要使用相同的字段既作分區鍵又作分佈鍵。
不要使用默認分區。
避免使用多級分區；儘可能少地建立分區，每一個分區的數據會多些。
經過查詢計劃的 EXPLAIN 結果來確保對分區表執行的查詢是選擇性掃描（分區裁剪）。
對於列存儲的表，不要建立過多的分區，不然會形成物理文件過多：
    Physical files = Segments * Columns * Partitions。

九、根據監控定位資源佔用較多的狀況：

• CPU
• 內存
• IO
• 網絡

筆者目前耗費資源比較多的是內存，主要須要優化內存、增長內存。

十、 數據庫配置優化

• Greenplum企業應用實戰第8章
• 《Greenplum 數據庫最佳實踐》第二章

• https://blog.csdn.net/u012948976/article/details/52695372

• 查詢緩存
• 線程數量與內存

• gp_statement_mem ：單個查詢可使用的內存總量。若是它太大，則併發數越小。因此要有所折衷。

• http://blog.51cto.com/michaelkang/2170608

十一、硬件選型

• • Greenplum企業應用實戰第8章
• gp性能管理

硬件考慮因素：

• （1）Segment服務器具備相同的硬件配置；推薦：雙核，32GB Mem，高速磁盤陣列，4個以上千兆網口。
• （2）Master服務器具備較高的cpu和內存資源；
• （3）基準性能：3.2GB/s（綜合的系統磁盤讀寫速度）

十二、 估值計算
估值計算是統計學的經常使用手段。由於數據量龐大，求精確數值須要耗費巨大的資源，而統計分析並不要求徹底精確的數據，所以估值計算是一種折中的方法，普遍應用於統計分析場景。

秒級任意維度分析1TB級大表 - 經過採樣估值知足高效TOP N等統計分析需求

1三、 服務器參數調整

• 共享內存
• 網絡
• 系統對用戶的限制，好比打開文件句柄的數量。

GP的性能極限分析

MPP架構

Greenplum實現了基於數據庫的分佈式數據存儲和並行計算

MPP架構的極限思考？

根據木桶原理以及這篇文章（https://clickhouse.yandex/benchmark.html#[%22100000000%22,[%22Greenplum%22],[%220%22,%221%22,%222%22]]）的測試結果，segment節點的PG實例的處理速度決定。若是OLAP的處理速度在3秒內，能夠計算單segment在3秒之內能處理多少速度，而後再作橫向擴展。

參考文獻

• Greenplum性能調優
• gp性能管理
• http://greenplum.cn/articles/gpdb-best-practice.html
• 清空postgresql shared_buffers
• https://yq.aliyun.com/articles/73038?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&201745&utm_content=m_15961
• Greenplum優化--SQL調優篇
• https://github.com/digoal/blog/blob/master/201707/20170725_01.md#greenplum-%E6%80%A7%E8%83%BD%E8%AF%84%E4%BC%B0%E5%85%AC%E5%BC%8F---%E9%98%BF%E9%87%8C%E4%BA%91hybriddb-for-postgresql%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5