本文主要分為三部分：
- GP優化需要准備的一些關於優化之外的知識，包括清空緩存、性能監控、執行計划分析。
- 具體優化措施，從以下四個方面考慮：
- 表、字段
- sql
- GP配置、服務器配置
- 硬件及節點資源
- 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）。
https://www.cnblogs.com/arthurqin/p/6243277.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配置
- 硬件及節點資源
1、表字段設計
如上面例子所示，優化某些字段的設計，以提高性能
2、表存儲方式
Heap 或 Append-Only存儲：GP默認使用堆表。堆表最好用在小表，如：維表(初始化后經常更新)。Append-Only表不能update和delete。一般用來做批量數據導入。 不建議單行插入。
多列查詢請求
- 行存儲 => 在select或where子句中，查詢所有列或大部分列
- 列存儲 => 在where或having子句中，查詢單列的值匯總或單行過濾
若數據需要頻繁地更新或者插入，則使用行存儲。
若需要同時訪問一個表的很多字段，則使用行存儲。
對於通用或者混合型業務，建議使用行存儲。
若查詢訪問的字段數目較少，或者僅在少量字段上進行聚合操作，則使用列存儲。
若僅常常修改表的某一字段而不修改其他字段，則使用列存儲。
3、壓縮
對於大AO表和分區表使用壓縮，以提高系統I/O。
在字段級別配置壓縮。
考慮壓縮比和壓縮性能之間的平衡。
壓縮的性能取決於硬件、查詢調優設置、其它因素。
- QuickLZ - 低壓縮率、低cpu消耗、壓縮數據塊
- zlib - 高壓縮率、低速
4、列存儲
列存里面可以啟動壓縮。
只適合append-only表。
5、索引
高基數的列（唯一值多）
一般來說，在Greenplum數據庫中索引不是必需的。
對於高基數的列存儲表，如果需要遍歷且查詢選擇性較高，則創建單列索引。
頻繁更新的列不要建立索引。
在加載大量數據之前刪除索引，加載結束后再重新創建索引。
優先使用 B 樹索引。
不要為需要頻繁更新的字段創建位圖索引。
不要為唯一性字段、基數非常高或者非常低的字段創建位圖索引。
不要為事務性負載創建位圖索引。
一般來說不要索引分區表。如果需要建立索引，則選擇與分區鍵不同的字段。
可優化部分小結果集查詢。
6、分布鍵
7、 分組擴展
Greenplum數據庫的GROUP BY擴展可以執行某些常用的計算，且比應用程序或者存儲過程效率高。
GROUP BY ROLLUP(col1, col2, col3)
GROUP BY CUBE(col1, col2, col3)
GROUP BY GROUPING SETS((col1, col2), (col1, col3))
8、分區
黃金法則
目前Greenplum支持LIST和RANGE兩種分區類型。
分區的目的是盡可能的縮小QUERY需要掃描的數據量，因此必須和查詢條件相關聯。
只為大表設置分區，不要為小表設置分區。
僅在根據查詢條件可以實現分區裁剪時使用分區表。
建議優先使用范圍 (Range) 分區，否則使用列表 (List) 分區。
根據查詢特點合理設置分區。
不要使用相同的字段既做分區鍵又做分布鍵。
不要使用默認分區。
避免使用多級分區；盡量少地創建分區，每個分區的數據會多些。
通過查詢計划的 EXPLAIN 結果來確保對分區表執行的查詢是選擇性掃描（分區裁剪）。
對於列存儲的表，不要創建過多的分區，否則會造成物理文件過多：
Physical files = Segments * Columns * Partitions。
9、根據監控定位資源占用較多的情況：
- CPU
- 內存
- IO
- 網絡
筆者目前耗費資源比較多的是內存，主要需要優化內存、增加內存。
10、 數據庫配置優化
-
Greenplum企業應用實戰第8章
-
查詢緩存
-
線程數量與內存
-
gp_statement_mem ：單個查詢可以使用的內存總量。如果它太大，則並發數越小。所以要有所折衷。
11、硬件選型
-
- Greenplum企業應用實戰第8章
- gp性能管理
硬件考慮因素：
- （1）Segment服務器具有相同的硬件配置；推薦：雙核，32GB Mem，高速磁盤陣列，4個以上千兆網口。
- （2）Master服務器具有較高的cpu和內存資源；
- （3）基准性能：3.2GB/s（綜合的系統磁盤讀寫速度）
12、 估值計算
估值計算是統計學的常用手段。因為數據量龐大，求精確數值需要耗費巨大的資源，而統計分析並不要求完全精確的數據，因此估值計算是一種折中的方法，廣泛應用於統計分析場景。
秒級任意維度分析1TB級大表 - 通過采樣估值滿足高效TOP N等統計分析需求
13、 服務器參數調整
- 共享內存
- 網絡
- 系統對用戶的限制，比如打開文件句柄的數量。
GP的性能極限分析
MPP架構
Greenplum實現了基於數據庫的分布式數據存儲和並行計算
MPP架構的極限思考？
根據木桶原理以及這篇文章（https://clickhouse.yandex/benchmark.html#["100000000",["Greenplum"],["0","1","2"]]）的測試結果，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-性能評估公式---阿里雲hybriddb-for-postgresql最佳實踐