1. 問題說明
復(fù)現(xiàn)analyze AO表的效率低据过，實(shí)驗(yàn)的軟硬件情況如下：
條目說明
云服務(wù)器2核/2GB/50GB SSD/密集計(jì)算型ic4
操作系統(tǒng)CentOS / 8.2 x86_64 (64bit)?
Greenplum5.24邏輯集群，master/standby和3primary/3mirror
表1實(shí)驗(yàn)環(huán)境
1.1 創(chuàng)建AO列存分區(qū)表
1）建表語句
圖1 建表
2）表中記錄數(shù)
圖2 表記錄
1.2 耗時(shí)和資源占用
1）在基表上執(zhí)行統(tǒng)計(jì)信息收集
圖3 耗時(shí)統(tǒng)計(jì)
2）CPU和IO資源監(jiān)控
圖4 CPU資源消耗
圖5 IO資源消耗
通過實(shí)驗(yàn)可以觀察到在analyze執(zhí)行期間CPU占用資源較高带族，同時(shí)也產(chǎn)生一定的IO消耗。
2. 改進(jìn)思路
2.1 analyze部分列和分區(qū)
改進(jìn)點(diǎn)說明
analyze部分列使用analyze table(column, ...)為選擇的列生成統(tǒng)計(jì)信息,確保包含用在連接狡孔、WHERE子句免糕、SORT子句是目、GROUP BY子句或者HAVING子句中的列。
analyze部分分區(qū)只在更改過的分區(qū)上執(zhí)行analyze年枕，同時(shí)單獨(dú)執(zhí)行analyze rootpartition 收集根分區(qū)信息炫欺。
表2 analyze部分信息
2.2實(shí)驗(yàn)驗(yàn)證
1）analyze部分列并統(tǒng)計(jì)耗時(shí)
圖6 analyze部分信息命令
2）多次實(shí)驗(yàn)的結(jié)果
Cn表時(shí)analyze列的數(shù)量為n,耗時(shí)單位為毫秒。analyze的耗時(shí)和列數(shù)熏兄、分區(qū)數(shù)成類似正比關(guān)系品洛。
圖7 analyze耗時(shí)統(tǒng)計(jì)
3. 原理分析
3.1 疑問
疑點(diǎn)猜想
analyze基表為什么會(huì)耗時(shí)很長呢？對(duì)于分區(qū)表摩桶，會(huì)收集所有分區(qū)的信息桥状；即使數(shù)據(jù)沒有變化的分區(qū)也會(huì)重復(fù)收集；
analyze耗時(shí)和列關(guān)系是怎么樣的硝清？每個(gè)列都有對(duì)應(yīng)統(tǒng)計(jì)信息辅斟，列數(shù)多導(dǎo)致耗時(shí)變長。
analyze基表和分別analyze分區(qū)表有差別嗎芦拿？analyze基表是analyze分區(qū)表的合集操作
表3 疑問和猜想
3.2 源碼分析
核心代碼的實(shí)現(xiàn)在vacuum.c和analyze.c中士飒，通過對(duì)源碼的分析驗(yàn)證了4.1的猜想。
1）主流程
圖8 主流程
在步驟P3中分區(qū)表的數(shù)量會(huì)影響收集統(tǒng)計(jì)信息的耗時(shí)防嗡。
源碼：https://github.com/greenplum-db/gpdb/blob/5.24/src/backend/commands/vacuum.c
2）收集單分區(qū)的流程
圖9 單表收集
在步驟P4变汪、P5、P6中列的數(shù)量會(huì)影響收集統(tǒng)計(jì)信息的耗時(shí)蚁趁。
源碼：https://github.com/greenplum-db/gpdb/blob/5.24/src/backend/commands/analyze.c
3.3 analyze執(zhí)行時(shí)機(jī)
1）加載數(shù)據(jù)后
2）創(chuàng)建索引操作后
3）數(shù)據(jù)發(fā)生明顯變更后裙盾，如insert/update/delete操作后
4）analyze表上會(huì)申請(qǐng)讀鎖，注意和其他語句不要產(chǎn)生沖突
3.4 統(tǒng)計(jì)信息的保存
analyze命令收集的統(tǒng)計(jì)信息會(huì)保存到系統(tǒng)表pg_class和pg_statistic。
1）pg_class表大小信息
列名說明
relnametable, index, view等名稱番官。
relpages表占用的頁面（32K）數(shù)庐完，是查詢規(guī)劃器生成執(zhí)行計(jì)劃的輸入；通過vacuum和analyze來更新徘熔。
reltuples表的行數(shù)门躯，是查詢規(guī)劃器生成執(zhí)行計(jì)劃的輸入；通過vacuum和analyze來更新酷师。
表4 pg_class
2）pg_stats統(tǒng)計(jì)信息
列名說明
schemanameschema名稱
tablename表名
null_frac為空的列項(xiàng)所占的比例
attname表的行數(shù)讶凉，是查詢計(jì)劃器生成執(zhí)行計(jì)劃的輸入；通過vacuum和analyze來更新山孔。
avg_width該列中非null項(xiàng)的平均存儲(chǔ)寬度（以字節(jié)為單位）
n_distinct該列中可區(qū)分值的數(shù)量估計(jì),基于HLL算法進(jìn)行估算
most_common_vals該列中最常見值的數(shù)組
most_common_freqs包含most_common_vals數(shù)組中值的頻率
histogram_bounds一個(gè)值數(shù)組懂讯，它把列值劃分成大約相同尺寸的分組
correlation相關(guān)關(guān)系統(tǒng)計(jì)信息，Greenplum不計(jì)算該信息
表5 pg_stats
pg_stats是由pg_statistic系統(tǒng)表擴(kuò)展而來的系統(tǒng)視圖,記錄的是每個(gè)表每個(gè)字段的統(tǒng)計(jì)信息,用于規(guī)劃器做執(zhí)行計(jì)劃選擇的時(shí)候提供參考台颠。
4. 總結(jié)
基于Greenplum數(shù)據(jù)倉庫中會(huì)涉及比較多的業(yè)務(wù)表褐望，而如何高效的收集業(yè)務(wù)表的統(tǒng)計(jì)信息是比較關(guān)鍵的維護(hù)操作。本文通過對(duì)analyze的耗時(shí)長進(jìn)行優(yōu)化串前，采用最佳實(shí)踐的建議瘫里，并進(jìn)行實(shí)驗(yàn)驗(yàn)證，同時(shí)結(jié)合源碼進(jìn)行效率根因的深入分析荡碾。對(duì)analyze的原理進(jìn)一步了解谨读，對(duì)更好的使用和運(yùn)維Greenplum數(shù)據(jù)庫提供幫助芜赌。
5. 特別提示
在6版本中枣抱，analyze已經(jīng)做了很大的優(yōu)化舷夺，性能有了極大的提升竟纳，這主要?dú)w功于analyze的實(shí)現(xiàn)方式的優(yōu)化蛇损。在4版本中解藻，analyze時(shí)會(huì)先創(chuàng)建一個(gè)臨時(shí)表线椰，然后掃描analyze的目標(biāo)表衔彻，并通過random()函數(shù)來抽取樣本數(shù)據(jù)插入臨時(shí)表中女坑。之后填具，再根據(jù)臨時(shí)表中的數(shù)據(jù)生成最終的統(tǒng)計(jì)信息。在5版本中匆骗，進(jìn)行了一定的優(yōu)化劳景，去除了臨時(shí)表，直接通過掃描目標(biāo)表并使用random()函數(shù)抽取樣本數(shù)據(jù)碉就，生成最終的統(tǒng)計(jì)信息盟广。
而在6版本中，不再需要掃描目標(biāo)表瓮钥，而是通過數(shù)據(jù)抽樣的方式來獲取樣本數(shù)據(jù)筋量，極大提升了analyze的性能烹吵。在6版本之前，analyze的耗時(shí)與表尺寸成正相關(guān)桨武，而在6版本中肋拔，analyze的耗時(shí)與表尺寸不再有正相關(guān)性，只與統(tǒng)計(jì)信息的精度和收集統(tǒng)計(jì)信息的字段數(shù)量有關(guān)呀酸。
6. 參考信息
https://github.com/greenplum-db/gpdb
https://docs.greenplum.org/5280/ref_guide/system_catalogs/pg_statistic.html
https://gp-docs-cn.github.io/docs/admin_guide/intro/about_statistics.html
https://gp-docs-cn.github.io/docs/best-practices/analyze.html
7.本文轉(zhuǎn)自
Greenplum中文社區(qū)：https://mp.weixin.qq.com/s/RVN8YFcqWNGht6N32UQW0g
