?介紹

本文介紹PivotalGreenplumDatabase數據庫（以下簡稱：Greenplum

數據庫，或GPDB）的最佳實踐。

最佳實踐是指能持續產生比其他方法更好結果的方法或者技術，它來自于

實戰閱歷，并被證明了遵循這些方法可以獲得牢靠的預期結果。本最佳實

踐旨在通過利用全部可能的學問和技術為正確運用GPDB供應有效參考。

本文不是在教您如何運用Grccnplum數據庫的功能，而是幫助您在設計、

實現和運用Greenplum數據庫時了解須要遵循哪些最佳實踐。關于如何

運用和實現具體的Greenplum數據庫特性，請參考上的Greenplum

數據庫幫助文檔以與上的Sandbox和實踐指南。

本文H的不是要涵蓋整個產品或者產品特性，而是概述GPDB實踐中最

重要的因素。本文不涉與依靠于GPDB具體特性的邊緣用例，后者須要

精通數據庫特性和您的環境，包括SQL訪問、查詢執行、并發、負載和

其他因素。

通過駕馭這些最佳實踐學問，會增加GPDB集群在維護、支持、性能和

可擴展性等方面的勝利率。

第一章最佳實踐概述

本部分概述了Greenplum數據庫最佳實踐所涉與的概念與要點。

數據模型

GPDB是一個基于大規模并行處理(MPP)和無共享架構的分析型數據庫。

這種數據庫的數據模式與高度規范化的事務性SMP數據庫顯著不同。通

過運用非規范化數據庫模式，例如具有大事實表和小維度表的星型或者雪

花模式，GPDB在處理MPP分析型業務時表現優異。

跨表關聯(JOIN)時字段運用相同的數據類型。

詳見數據庫模式設計(后續章節)

堆存儲和追加優化存儲(Append-Optimized,下稱AO)

若表和分區表須要進行迭代式的批處理或者頻繁執行單個UPDATE、

DELETE或INSERT操作，運用堆存儲。

若表和分區表須要并發執行UPDATE、DELETE或INSERT操作，運用

堆存儲。

若表和分區表在數據初始加載后更新不頻繁，且僅以批處理方式插入數據,

則運用AO存儲。

不要又寸AO表執行單個INSERT、UPDATE或DELETE操作。

不要對AO表執行并發批量UPDATE或DELETE操作，但可以并發執行

批量INSERT操作。

詳見堆存儲和AO存儲（后續章忖

行存儲和列存儲

若數據須要常常更新或者插入，則運用行存儲。

若須要同時訪問一個表的許多字段，則運用行存儲。

對于通用或者混合型業務，建議運用行存儲。

若查詢訪問的字段數目較少，或者僅在少量字段上進行聚合操作，則運用

列存儲。

若僅常常修改表的某一字段而不修改其他字段，則運用列存儲。

詳見行存儲和列存儲（后續章節）

壓縮

對于大AO表和分區表運用壓縮，以提高系統I/O。

在字段級別配置壓縮。

考慮壓縮比和壓縮性能之間的平衡。

詳見壓縮（后續章節）

分布

為全部表定義分布策略：要么定義分布鍵，要么運用隨機分布。不要運用

缺省分布方式。

優先選擇可勻稱分布數據的單個字段做分布鍵。

不要選擇常常用于WHERE子句的字段做分布鍵。

不要運用日期或時間字段做分布鍵。

分布鍵和分區鍵不要運用同一字段。

對常常執行JOIN操作的大表，優先考慮運用關聯字段做分布鍵，盡量做

到本地關聯，以提高性能。

數據初始加載后或者每次增量加載后，檢查數據分布是否勻稱。

盡可能避開數據傾斜。

詳見分布（后續章節）

內存管理

設置vm.overcommit_memory為2

不要為操作系統的頁設置過大的值

運用gp_vmem_protectjimit設置單個節'點數據庫(Segment

Database)可以為全部查詢安排的最大內存量。

不要設置過高的gp_vmem_protect_limit<,也不要大于系統的物理內

存。

gp_vmem_protect_limit的建議值計算公式為：(SWAP+(RAM*

vm.overcommit_ratio))*0.9/number_Segments_per_server

運用statement.mem限制節點數據庫為單個查詢安排的內存量。

運用資源隊列設置隊列允許的當前最大查詢數(ACTIVE_STATEMENTS)

和允許運用的內存大小(MEMORY_LIMIT)。

不要運用默認的資源隊列，為全部用戶都安排資源隊列。

依據負載和時間段，設置和隊列實際需求相匹配的優先級(PRIORITY)o

保證資源隊列的內存配額不超過gp_vmem_protect_limito

動態更新資源隊列配置以適應日常工作須要。

詳見內存和負載管理(后續章節)

分區

只為大表設置分區，不要為小表設置分區。

僅在依據查詢條件可以實現分區裁剪時運用分區表。

建議優先運用范圍(Range)分區，否則運用列表(List)分區。

依據查詢特點合理設置分區。

不要運用相同的字段即做分區鍵又做分布鍵。

不要運用默認分區。

避開運用多級分區；盡量創建少量的分區，每個分區的數據更多些。

通過查詢安排的EXPLAIN結果來驗證查詢對分區表執行的是選擇性掃

描(分區裁剪)。

對于列存儲的表，不要創建過多的分區，否則會造成物理文件過多：

Physicalfiles=Segments*Columns*Partitionso

詳見分區(后續章節)

索引

一般來說GPDB中索引不是必需的。

對于高基數的列存儲表，假如須要遍歷且查詢選擇性較高，則創建單列索

引。

頻繁更新的列不要建立索弓I。

在加載大量數據之前刪除索引，加載結束后再重新創建索弓I。

優先運用B樹索引。

不要為須要頻繁更新的字段創建位圖索引。

不要為唯一性字段，基數特別高或者特別低的字段創建位圖索引。

不要為事務性負載創建位圖索引。

一般來說不要索引分區表。假如須要建立索引，則選擇與分區鍵不同的字

段。

詳見索引（后續章節）

資源隊列

運用資源隊列管理集群的負載。

為全部角色定義適當的資源隊列。

運用ACTIVE_STATEMENTS參數限制隊列成員可以并發運行的查詢

總數。

運用MEMORY.LIMIT參數限制隊列中查詢可以運用的內存總量。

不要設置全部隊列為MEDIUM,這樣起不到管理負載的作用。

依據負載和時間段動態調整資源隊列。

詳見配置資源隊列（后續章節）

監控和維護

依據《Greenplum數據庫管理員指南》實現該書舉薦的監控和管理任務。

安裝Greenplum數據庫前建議運行gpcheckperf,安裝后定期運行，保

存輸出結果，隨著時間推移對系統性能進行比較。

運用全部您可用的工具，以了解系統不同負載下的表現。

檢查任何不尋常的事務并確定緣由。

通過定期運行說明安排監控系統查詢活動，以確保查詢處于最佳運行狀態。

檢查查詢安排，以確定是否按預期運用了索引和進行了分區裁剪。

了解系統日志文件的位置和內容，定期監控日志文件，而不是在出現問題

時才查看。

詳見系統監控和維護以與監控GPDB日志文件。（后續章節）

ANALYZE

不要對整個數據庫運行ANALYZE,只對須要的表運行該吩咐。

建議數據加載后即刻運行ANALYZEo

假如INSERT、UPDATE和DELETE等操作修改大量數據，建議運行

ANALYZEo

執彳亍CREATEINDEX操作后建議運彳亍ANALYZE。

假如對大表ANALYZE耗時很久，則只對JOIN字段、WHERE、SORT、

GROUPBY或HAVING字句的字段運行ANALYZE。

詳見運用ANALYZE更新統計信息。（后續章節）

Vaccum

批量UPDATE和DELETE操作后建議執行VACUUM。

不建議運用VACUUMFULL。建議運用CTAS（CREATETABLE...AS）

操作，然后重命名表名，并刪除原來的表。

對系統表定期運行VACUUM,以避開系統表臃腫和在系統表上執行

VACUUMFULL操作。

禁止殺死系統表的VACUUM任務。

不建議運用VACUUMANALYZEo

詳見消退系統表臃腫。（后續章節）

加載

運用gpfdist進行數據的加載和導出。

隨著段數據庫個數的增加，并行性增加。

盡量將數據勻稱地分布到多個ETL節點上。

將特別大的數據文件切分成相同大小的塊，并放在盡量多的文件系統上。

一個文件系統運行兩個gpfdist實例。

在盡可能多的網絡接口上運行gpfdsito

運用gp_external_max_segs限制訪問每個gpfdist服務器的段數據庫

的個數。

建議gp_external_max_segs的值和gpfdist進程個數為偶數。

數據加載前刪除索引；加載完后重建索引。

數據加載完成后運行ANALYZE操作。

數據加載過程中，設置gp_autostats_mode為NONE,取消統計信息

的自動收集。

若數據加載失敗，運用VACUUM回收空間。

詳見加載數據。（后續章節）

gptransfer

為了更好的性能，建議運用gptransfer遷移數據到相同大小或者更大的

集群。

避開運用一色11或者-schema-only選項。建議運用其他方法拷貝數據

庫模式到目標數據庫，然后遷移數據。

遷移數據前刪除索引，遷移完成后重建索引。

運用SQLCOPY助咐遷移小表到目標數據庫。

運用gptransfer批量遷移大表。

在正式遷移生產環境前測試運行gptransfer。試

驗一batch-size和-sub-batch-size選項以獲得最大平行度。假如須要,

迭代運行多次gptransfer來確定每次要遷移的表的批次。

僅運用完全限定的表名。表名字中若含有點、空格、單引號和雙引號，可

能會導致問題。

假如運用一validation選項在遷移后驗證數據，則須要同時運用-x選項，

以在源表上加排它鎖。

確保在目標數據庫上創建了相應的角色、函數和資源隊列。gptransfer

-t不會遷移這些對象。

從源數據庫拷貝postgres.conf和pg_hba.conf到目標數據庫集群。

運用gppkg在目標數據庫上安裝須要的擴展。

詳見運用gptransfer遷移數據（后續章節）

平安

妥當愛護gpadmin賬號,只有在必要的時候才能允許系統管理員訪問它。

僅當執行系統維護任務（例如升級或擴容），管理員才能以gpadmin登

錄Greenplum集群。

限制具有SUPERUSER角色屬性的用戶數。GPDB中，身為超級用戶

的角色會跳過全部訪問權限檢查和資源隊列限制。僅有系統管理員具有數

據庫超級用戶權限。參考《Greenplum數據庫管理員指南》中的“修改

角色屬性”。

嚴禁數據庫用戶以gpadmin身份登錄，嚴禁以gpadmin身份執行ETL

或者生產任務。

為有登錄需求的每個用戶都安排一個不同的角色。

考慮為每個應用或者網絡服務安排一個不同的角色。

運用用戶組管理訪問權限。

愛護好ROOT的密碼。

對于操作系統密碼，強制運用強密碼策略。

確保愛護好操作系統的重要文件。

詳見平安。（后續章節）

加密

加密和解密數據會影響性能，僅加密須要加密的數據。

在生產系統中實現任何加密解決方案之前都要做性能測試。

GPDB生產系統運用的服務器證書應由證書簽名頒發機構（CA）簽名，

這樣客戶端可以驗證服務器。假如全部客戶端都是本地的，則可以運用本

地CA。

假如客戶端與GPDB的連接會經過擔心全的鏈路，則運用SSL加密。

加密和解密運用相同密鑰的對稱加密方式比非對稱加密具有更好的性能,

假如密鑰可以平安共享，則建議運用對稱加密方式。

運用pgcrypto包中的函數加密磁盤上的數據。數據的加密和解密都由數

據庫進程完成，為了避開傳輸明文數據，須要運用SSL加密客戶端和數

據庫間的連接。

數據加載和導出時，運用gpfdists協議愛護ETL數據平安。

詳見加密數據和數據庫連接。（后續章節）

高可用

運用8到24個磁盤的硬件RAID存儲解決方案。

運用RAID1、5或6,以使磁盤陣列可以容忍磁盤故障。

為磁盤陣列配備熱備磁盤，以便在檢測到磁盤故障時自動起先重建。

在重建時通過RAID卷鏡像防止整個磁盤陣列故障和性能下降。

定期監控磁盤利用率，并在須要時增加額外的空間。

定期監控段數據庫傾斜，以確保在全部段數據庫上數據勻稱分布，存儲空

間勻稱消耗。

配置備用主服務器，當主服務器發生故障時由備用主服務器接管。

規劃好當主服務器發生故障時如何切換客戶端連接到新的主服務器實例，

例如通過更新DNS中主服務器的地址。

建立監控系統，當主服務器發生故障時，可以通過系統監控應用或電子郵

件發送通知。

安排主段數據庫和其鏡像到不同的主機上，以防止主機故障。

建立監控系統，當主段數據庫發生故障時，可以通過系統監控應用或電子

郵件發送通知。

運用gprecoverseg工具與時復原故障段，并使系統返回最佳平衡狀態。

在主服務器上配置并運行gpsnmpd以發送SNMP通知給網絡監控器。

在$Master_DATA_DIRECTORY/postgresql.conf配置文件中設置郵

件通知，以便檢測到關鍵問題時，Greenplum系統可以通過電子郵件通

知管理員。

考慮雙集群配置，供應額外的冗余和查詢處理實力。

除非Greenplum數據庫的數據很簡潔從數據源復原，否則定期備份。

假如堆表相對較小,或者兩次備份之間僅有少量AO或列存儲分區有變更,

則運用增量備份。

假如備份保存在集群的本地存儲系統上，則備份結束后，將文件移到其他

的平安存儲系統上。

假如備份保存到NFS中，則建議運用像EMCIsilon這樣的可擴展

NFS方案以防止I/O瓶頸。

Greenplum集成了對EMC的DataDomain和Symantec的

NetBackup的支持，可以流式備份到DataDomain或NetBackup企

業備份平臺上。

詳見高可用性（后續章節）

其次章系統配置

本節描述了Greenplum數據庫集群關于主機配置的需求和最佳實踐。

。首選操作系統

紅帽企業級Linux(RHEL)是首選操作系統c應運用最新支持的主版本，

目前是RHEL6o

?文件系統

Greenplum數據庫的數據書目舉薦運用XFS文件系統。運用以下選項

掛載XFS：

rw,noatime,inode64,allocsize=16m

?端口配置

ip」ocal_port_range的設置不要和Greenplum數據庫的端口范圍有

沖突，例如：

net.ipv4.ip_local_port_range=3000

65535PORT_BASE=2GOOMIRROR_PORT_BASE=2100REPLICATI

ON_PORT_BASE=2200MIRROR_REPLICATION_PORT_BASE=230

0

?I/O配置

包含數據書目的設備的預讀大小應設為16384.

/sbin/blockdev—getra/dev/sdbl6384

包含數據書目的設備的I/O調度算法設置為deadlineo

#cat/sys/block/sdb/queue/schedulernoopanticipatory

[deadline]cfq

通過/etc/security/limits.conf增大操作系統文件數和進程數。

*softno*hardno*softnproc131072*hardnproc131072

啟用core文件轉儲，并保存到已知位置。確保limits.conf中允許的core

轉儲文件。

kernel.core_pattern=/var/core/core.%h.%t#grepcore

/etc/security/limits.conf*softcoreunlimited

?操作系統內存配置

Linuxsysctl

的vm.overcommit_memory和vm.overcommit_ratio變量會影響操

作系統對內存安排的管理。這些變量應當設置如下：

?vm.overcommit_memory限制操作系統運用什么方法確定安排給進程

的內存總數。對于Greenplum數據庫，唯一建議值是2.

?vm.overcommit_ratio限制安排給應用程序進程的內存百分比。建議運

用缺省值50.

不要啟用操作系統的大內存頁。

詳見內存和負載管理。（后續章節）

?共享內存設置

Greenplum數據庫中同一數據庫實例的不同postgres進程間通訊運用

共享內存。運用sysctl配置如卜共享內存參數，且不建議修改：

kernel.shmmax=500000000kernel.shmmni=4096kernel.shmall

=4000000000

?驗證操作系統

運用gpcheck驗證操作系統配置。參考《Greenplum數據庫工具指南》

中的gpchecko

?設置一個主機上段數據庫個數

確定每個段主機上段數據庫的個數對整體性能有著巨大影響。這些段數據

庫之間共享主機的CPU核、內存、網卡等，且和主機上的全部進程共享

這些資源。過高地估計每個服務器上運行的段數據庫個數，通常是達不到

最優性能的常見緣由之一。

以下因素確定了一個主機上可以運行多少個段數據庫:

?CPU核的個數

?物理內存容量

?網卡個數與速度

?存儲空間

?主段數據庫和鏡像共存

?主機是否運行ETL進程

?主機上運行的非Greenplum進程

?段服務器內存配置

服務器配置參數gp_vmem_protect_limit限制了每個段數據庫為全部

運行的查詢安排的內存總量。假如查詢須要的內存超過此值，則會失敗。

運用下面公式確定合適的值：

(swap+(RAM*vm.overcommit_ratio))*.9/

number_of_Segments_per_server

例如，具有下面配置的段服務器：

?8GB交換空間

?128GB內存

?vm.overcommit_ratio=50

?8個段數據庫

貝ij設置gp_vmem_protect_limit為8GB:

(8+(128*.5))*.9/8=8GB

參見內存和負載管理。(后續章節)

。SQL語句內存配置

服務器配置參數gp_statement_mem限制段數據庫上單個查詢可以運

用的內存總量。假如語句須要更多內存，則會溢出數據到磁盤。用下面公

式確定合適的值：

(gp_vmem_protect_limit*.9)/max_expected_concurrent_queries

例如，假如并發度為40,gp_vmeme_protect_limit為8GB,

則gp_statement_mem為：

(8192MB*⑼/40=184MB

每個查詢最多可以運用184MB內存，之后將溢出到磁盤。

若想平安的增大gp_statement_mem,要么增

大gp_vmem_protectJimit,要么降低并發。要增大

gp_vmem_protectJimit,必需增加物理內存和/或交換空間，或者降低

單個主機上運行的段數據庫個數。

請留意，為集群添加更多的段數據庫實例并不能解決內存不足的問題，除

非引入更多新主機來降低了單個主機上運行的段數據庫的個數。

了解什么是溢出文件。了解gp_work參數，其限制了單個查詢最多可以

創建多少個溢出文件。了解gp_work。

有關運用資源隊列管理內存的更多信息，請參考內存和負載管理。（后續

章節）

。溢出文件配置

假如為SQL查詢安排的內存不足,Greenplum數據庫會創建溢出文件（也

叫工作文件）。在默認狀況下，一個SQL查詢最多可以創建100000個

溢出文件，這足以滿意大多數查詢。

參數gp_work確定了一個查詢最多可以創建多少個溢出文件。。意味著

沒有限制。限制溢出文件數據可以防止失控查詢破壞整個系統。

假如安排內存不足或者出現數據傾斜，則一個SQL查詢可能產生大量溢

出文件。假如超過溢出文件上限，Greenplum數據庫報告如下錯誤：

ERROR:numberofworkfilesperquerylimitexceeded

在嘗試增大gp_work前，先嘗試通過修改SQL、數據分布策略或者內存

配置以降低溢出文件個數。

gp-toolkit模式包括一些視圖，通過這些視圖可以看到全部運用溢出文件

的查詢的信息。這些信息有助于故障解除和調優查詢：

?gp_work視圖的每一行表示一個正在運用溢出文件的操作符的信息。關于

操作符，參考如何理解查詢安排說明。（后續章節）

?gp_work視圖的每一行表示一個正在運用溢出文件的SQL查詢的信息。

?gp_work視圖的每一行對應一個段數據庫，包含了該段上運用的溢出文件

占用的磁盤空間總量。

關于這些視圖的字段涵義，請參考《Greenplum數據庫參考指南》。

參數gp_work指定溢出文件的壓縮算法：none或者zlibo

第三章數據庫模式設計

GPDB是一個基于大規模并行處理（MPP）和無共享架構的分析型數據

庫。這種數據庫的數據模式與高度規范化的事務性SMP數據庫顯著不同。

運用非規范化數據庫模式，例如具有大事實表和小維度表的星型或者雪花

模式，處理MPP分析型業務時，Greenplum數據庫表現優異。

?數據類型

類型一樣性

關聯列運用相同的數據類型。假如不同表中的關聯列數據類型不同，

GPDB必需動態的進行類型轉換以進行比較，考慮到這一點，你可能須

要增大數據類型的大小，以便關聯操作更高效。

類型最小化

建議選擇最高效的類型存儲數據，這可以提高數據庫的有效容量與查詢執

行性能。

建議運用TEXT或者VARCHAR而不是CHAR。不同的字符類型間沒

有明顯的性能差別，但是TEXT或者VARCHAR可以降低空間運用量。

建議運用滿意需求的最小數值類型。假如INT或SAMLLINT夠用，那

么選擇BIGINT會奢侈空間。

?存儲模型

在Greenplum數據庫中，創建表時可以選擇不同的存儲類型。須要清

晰什么時候該運用堆存儲、什么時候運用追加優化(AO)存儲、什么時候運

用行存儲、什么時候運用列存儲。對于大型事實表這尤為重要。相比而言，

對小的維度表就不那么重要了。

選擇合適存儲模型的常規最佳實踐為：

1.對于大型事實分區表，評估并優化不同分區的存儲選項。一種存儲模型可

能滿意不了整個分區表的不同分區的應用場景，例如某些分區運用行存儲

而其他分區運用列存儲。

2.運用列存儲時，段數據庫內每一列對應一個文件。對于有大量列的表，常

常訪問的數據運用列存儲，不常訪問的數據運用行存儲。

3.在分區級別或者在數據存儲級別上設置存儲類型。

4.假如集群須要更多空間，或者期望提高I/O性能，考慮運用壓縮。

堆存儲和AO存儲

堆存儲是默認存儲模型，也是PostgreSQL存儲全部數據庫表的模型。

假如表和分區常常執行UPDATE、DELETE操作或者單個INSERT操

作，則運用堆存儲模型。假如須要對表和分區執行并發UPDATE、

DELETE、INSERT操作，也運用堆存儲模型。

假如數據加載后很少更新，之后的插入也是以批處理方式執行，則運用追

加優化(AO)存儲模型。千萬不要對AO表執行單個

INSERT/UPDATE/DELETE操作。并發批量INSERT操作是可以的,

但是不要執行并發批量UPDATE或者DELETE操作。

AO表中執行刪除和更新操作后行所占空間的重用效率不如堆表，所以這

種存儲類型不適合頻繁更新的表。AO表主要用于分析型業務中加載后很

少更新的大表。

行存儲和列存儲

行存儲是存儲數據庫元組的傳統方式。一行的全部列在磁盤上連續存儲,

所以一次I/O可以從磁盤上讀取整個行。

列存儲在磁盤上將同一列的值保存在一塊。每一列對應一個單獨的文件。

假如表是分區表，那么每個分區的每個列對應一個單獨的文件。假如列存

儲表有許多列，而SQL查詢只訪問其中的少量列，那么I/O開銷與行存

儲表相比大大降低，因為不須要從磁盤上讀取不須要訪問的列。

交易型業務中更新和插入頻繁，建議運用行存儲。假如須要同時訪問寬表

的許多字段時，建議運用行存儲。假如大多數字段會出現在SELECT列

表中或者WHERE子句中，建議運用行存儲。對于通用的混合型負載，

建議運用行存儲。行存儲供應了敏捷性和性能的最佳組合。

列存儲是為讀操作而非寫操作優化的一種存儲方式，不同字段存儲在磁盤

上的不同位置。對于有許多字段的大型表，假如單個查詢只需訪問較少字

段，那么列存儲性能優異。

列存儲的另一個好處是相同類型的數據存儲在一起比混合類型數據占用

的空間少，因而列存儲表比行存儲表運用的磁盤空間小。列存儲的壓縮比

也高于行存儲。

數據倉庫的分析型業務中，假如SELECT訪問少量字段或者在少量字段

上執行聚合計算，則建議運用列存儲。假如只有單個字段須要頻繁更新而

不修改其他字段，則建議列存儲。從一個寬列存儲表中讀完整的行比從行

存儲表中讀同一行須要更多時間。特殊要留意的是，GPDB每個段數據庫

上每一列都是一個獨立的物理文件。

壓縮

Greenplum數據庫為AO表和分區供應多種壓縮選項。運用壓縮后，每

次磁盤讀操作可以讀入更多的數據，因而可以提高I/O性能。建議在實際

保存物理數據的那一層設置字段壓縮方式。

請留意，新添加的分區不會自動繼承父表的壓縮方式，必需在創建新分區

時明確指定壓縮選項。

Delta和RLE的壓縮比較高。高壓縮比運用的磁盤空間較少，但是在寫

入數據或者讀取數據時須要額外的時間和CPU周期進行壓縮和解壓縮。

壓縮和排序聯合運用，可以達到最好的壓縮比。

在壓縮文件系統上不耍再運用數據庫壓縮。

測試不同的壓縮類型和排序方法以確定最適合自己數據的壓縮方式。

?分布(DISTRIBUTIONS)

選擇能夠勻稱分布數據的分布鍵對Greenplum數據庫特別重要。在大

規模并行處理無共享環境中，查詢的總體響應時間取決于全部段數據庫的

完成時間。集群的最快速度與最慢的那個段數據庫一樣。假如存在嚴峻數

據傾斜現象，那么數據較多的段數據庫響應時間將更久。每個段數據庫最

好有數量接近的數據，處理時間也相像。假如一個段數據庫處理的數據顯

著比其他段多，那么性能會很差，并可能出現內存溢出錯誤。

確定分布策略時考慮以下最佳實踐：

?為全部表要么明確地指明其分布字段，要么運用隨機分布。不要運用默認

方式。

?志向狀況下，運用能夠將數據勻稱分布到全部段數據庫上的一個字段做分

布鍵C

?不要運用常出現在查詢的WHERE子句中的字段做分布鍵。

?不要運用日期或者時間字段做分布鍵。

?分布字段的數據要么是唯一值要么基數很大。

?假如單個字段不能實現數據勻稱分布，則考慮運用兩個字段做分布鍵。作

為分布鍵的字段最好不要超過兩個。GPDB運用哈希進行數據分布，運用

更多的字段通常不能得到更勻稱的分布，反而耗費更多的時間計算哈希值。

?假如兩個字段也不能實現數據的勻稱分布，則考慮運用隨機分布。大多數

狀況下，假如分布鍵字段超過兩個，那么執行表關聯時通常須要節點間的

數據移動操作（Motion）,如此一來和隨機分布相比，沒有明顯優勢。

Greenplum數據庫的隨機分布不是輪詢算法，不能保證每個節點的記錄

數相同，但是通常差別會小于10%o

關聯大表時最優分布至關重要。關聯操作須要匹配的記錄必需位于同一段

數據庫上。假如分布鍵和關聯字段不同，則數據須要動態重分發。某些狀

況下，廣播移動操作（Motion）比重分布移動操作效果好。

本地（Co-located）關聯

假如所用的哈希分布能勻稱分布數據，并導致本地關聯，那么性能會大幅

提升。本地關聯在段數據庫內部執行，和其他段數據庫沒有關系，避開了

網絡通訊開銷，避開或者降低了廣播移動操作和重分布移動操作。

為常常關聯的大表運用相同的字段做分布鍵可實現本地關聯。本地關聯須

要關聯的雙方運用相同的字段（且依次相同）做分布鍵，并且關聯時全部

的字段都被運用。分布鍵數據類型必需相同。假如數據類型不同，磁盤上

的存儲方式可能不同，那么即使值看起來相同，哈希值也可能不一樣。

數據傾斜

數據傾斜是許多性能問題和內存溢出問題的根本緣由。數據傾斜不僅影響

掃描/讀性能，也會影響許多其他查詢執行操作符，例如關聯操作、分組

操作等。

數據初始加載后，驗證并保證數據分布的勻稱性特別重要；每次增量加載

后，都要驗證并保證數據分布的勻稱性。

下面的查詢語句統計每個段數據庫上的記錄的條數，并依據最大和最小行

數計算方差：

SELECT'ExampleTable'AS"TableName",max(c)AS"MaxSeg

Rows",min(c)AS"MinSegRows",(max(c)-min(c))*100.0/max(c)

AS"PercentageDifferenceBetweenMax&Min"FROM(SELECT

count(*)c,gp_Segment_idFROMfactsGROUPBY2)ASa;

gp_tooklit模式中有兩個視圖可以幫助檢查傾斜狀況：

?視圖gp_toolkit.gp_skew_coefficients通過計算每個段數據庫所存儲數

據的變異系數(coefficientofvariation,CV)來顯示數據傾斜狀況。

skccoeff字段表示變異系數，通過標準偏差除以均值計算而來。它同時考

慮了數據的均值和可變性。這個值越小越好，值越高表示數據傾斜越嚴峻。

?視圖gp_toolkit.gp_skewjdle_fractions通過計算表掃描時系統空閑的

百分比顯示數據分布傾斜狀況，這是表示計算傾斜狀況的一個指標。

siffraction字段顯示了表掃描時處于空閑狀態的系統的百分比。這是數據

不勻稱分布或者查詢處理傾斜的一個指標。例如，。.1表示10%傾斜,

0.5表示50%傾斜，以此類推。假如傾斜超過10%,則需對其分布策

略進行評估。

計算傾斜(ProceddingSkew)

當不均衡的數據流向并被某個或者少數幾個段數據庫處理時將出現計算

傾斜。這常常是Greenplum數據庫性能和穩定性問題的罪魁禍首。關聯、

排序、聚合和各種OLAP操作中易發生計算傾斜。計算傾斜發生在查詢執

行時，不如數據傾斜那么簡潔檢測，通常是由于選擇了不當的分布鍵造成

數據分布不勻稱而引起的。數據傾斜體現在表級別，所以簡潔檢測，并通

過選擇更好的分布鍵避開。

假如單個段數據庫失敗(不是某個節點上的全部段實例)，那么可能是計

算傾斜造成的。識別計算傾斜目前主要靠手動。首先查看臨時溢出文件，

假如有計算傾斜，但是沒有造成臨時溢出文件，則不會影響性能。下面是

檢查的步驟和所用的吩咐：

1.找到懷疑發生計算傾斜的數據庫的OID：

SELECToid,datnameFROMpg_database;

例子輸出：

oid|datname+17088|gpadmin10899|postgres

1|template110898|templateO38817|pws39682|gpperfmon

(6rows)

2.運用gpssh檢查全部Segments上的溢出文件大小。運用上面結果

中的OID替換：

[gpadmin@mdwkend]$gpssh-f-/hosts-e\"du-b

/data[1-2]/primary/gpseg*/base/<OID>/pgsql_tmp/*"|\grep

-v"du-b"|sort|\awk-F""'{arr[$l]=arr[$l]+$2;tot=tot

+$2);\END{for|iinarr)print"Segmentnode"i,arri,\"bytes

(“am-t/(1024**3)"GB)H;\print"Total"，tot,“bytes("

tot/(1024**3)HGB)n}，-

例子輸出：

Segmentnode[sdwl]2443370457bytes(2.27557GB)Segment

node[sdw2]1766575328bytes(1.64525GB)Segmentnode[sdw3]

1761686551bytes(1.6407GB)Segmentnode[sdw4]1780301617

bytes(1.65804GB)Segmentnode[sdw5]1742543599bytes

(1.62287GB)Segmentnode[sdw6]1830073754bytes(1.70439

GB)Segmentnode[sdw7]1767310099bytes(1.64594

GB)Segmentnode[sdw8]1

假如不同段數據庫的磁盤運用量持續差別巨大，那么須要一進步查看當前

執行的查詢是否發生了計算傾斜(上面的例子可能不太恰當，因為沒有顯

示出明顯的傾斜）。在許多監控系統中，總是會發生某種程度的傾斜，

假如僅是臨時性的，則不必深究。

3.假如發生了嚴峻的長久性傾斜，接下來的任務是找到有問題的查詢。

上一步吩咐計算的是整個節點的磁盤運用量。現在我們要找到對應的段數

據庫（Segment）書目，可以從主節點（Master）上，也可以登錄到上一

步識別出的Segment上做本操作。下面例子演示從Master執行操作。

本例找的是排序生成的臨時文件。然而并不是全部狀況都是由排序引起的,

須要具體問題具體分析：

[gpadmin@mdwkend]$gpssh-f-/hosts-e\"Is-1

/data[1-2]/primary/gpseg*/base/19979/pgsql_tmp/*"|grep-i

sort|sort

下面是例子輸出：

[sdwl]-rw1gpadmingpadmin1002209280Jul2912:48

/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slic

el0_sort_19791_0001.0[sdwl]-rw1gpadmingpadmin

1003356160Jul29

12:48/data1/primary/gpseg1/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19789_0001.0[sdw1]-rw1gpadmin

gpadmin288718848Jul23

14:58/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tm

p_sliceO_sort_l7758_0001.0[sdw1]-rw1gpadmingpadmin

291176448Jul23

14:58/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tm

p_slice0_sort_17764_0001.0[sdwl]-rw1gpadmingpadmin

988446720Jul29

12:48/data1/primary/gpsegO/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19787_0001.0[sdw1]-rw1gpadmin

gpadmin995033088Jul29

12:48/data2/primary/gpseg3/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19793_0001.0[sdw1]-rw1gpadmin

gpadmin997097472Jul29

12:48/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19797_0001.0[sdw1]-rw1gpadmin

gpadmin997392384Jul29

12:48/data2/primary/gpseg4/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_19795_0001.0[sdw2]-rw1gpadmin

gpadmin1002340352Jul29

12:48/data2/primary/gpseg11/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_3973_0001.0[sdw2]-rw1gpadmin

gpadmin1004339200Jul29

12:48/data1/primary/gpseg8/base/19979/pgsql_tmp/pgsql_tm

p_slicel0_sort_3967_0001.0[sdw2]-rw1gpadmingpadmin

989036544Jul29

12:48/data2/primary/gpseglO/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_3971_0001.0[sdw2]-rw1gpadmin

gpadmin993722368Jul29

12:48/datal/primary/gpseg6/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_3963_0001.0[sdw2]-rw1gpadmingpadmin

998277120Jul29

12:48/data1/primary/gpseg7/base/19979/pgsql_tmp/pgsql_tm

p_slice10_sort_3965_0001.0[sdw2]-rw1gpadmingpadmin

999751680Jul29

12:48/data2/primary/gpseg9/base/19979/pgsql_tmp/pgsql.tm

p_slicel0_sort_3969_0001.0[sdw3]-rw1gpadmingpadmin

1000112128Jul29

12:48/datal/primary/gpsegl3/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24723_0001.0[sdw3]-rw1gpadmin

gpadmin1004797952Jul29

12:48/data2/primary/gpseg17/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24731_0001.0[sdw3]-rw1gpadmin

gpadmin1004994560Jul29

12:48/data2/primary/gpsegl5/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_24727_0001.0[sdw3]-rw1gpadmin

gpadmin1006108672Jul29

12:48/data1/primary/gpsegl4/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24725_0001.0[sdw3]-rw1gpadmin

gpadmin998244352Jul29

12:48/data1/primary/gpseg12/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24721_0001.0[sdw3]-rw1gpadmin

gpadmin998440960Jul29

12:48/data2/primary/gpseg16/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_24729_0001.0[sdw4]-rw1gpadmin

gpadmin1001029632Jul29

12:48/data2/primary/gpseg23/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29435_0001.0[sdw4]-rw1gpadmin

gpadmin1002504192Jul29

12:48/datal/primary/gpseg20/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29429_0001.0[sdw4]-rw1gpadmin

gpadmin1002504192Jul29

12:48/data2/primary/gpseg21/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29431_0001.0[sdw4]-rw1gpadmin

gpadmin1009451008Jul29

12:48/datal/primary/gpsegl9/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29427_0001.0[sdw4]-rw1gpadmin

gpadmin980582400Jul29

12:48/data1/primary/gpsegl8/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29425_0001.0[sdw4]-rw1gpadmin

gpadmin993230848Jul29

12:48/data2/primary/gpseg22/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29433_0001.0[sdw5]-rw1gpadmin

gpadmin1000898560Jul29

12:48/data2/primary/gpseg28/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28641_0001.0[sdw5]-rw1gpadmin

gpadmin1003388928Jul29

12:48/data2/primary/gpseg29/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28643_0001.0[sdw5]-rw1gpadmin

gpadmin1008566272Jul29

12:48/data1/primary/gpseg24/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28633_0001.0[sdw5]-rw1gpadmin

gpadmin987332608Jul29

12:48/data1/primary/gpseg25/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28635_0001.0[sdw5]-rw1gpadmin

gpadmin990543872Jul29

12:48/data2/primary/gpseg27/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28639_0001.0[sdw5]-rw1gpadmin

gpadmin999620608Jul29

12:48/datal/primary/gpseg26/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_28637_0001.0[sdw6]-rw1gpadmin

gpadmin1002242048Jul29

12:48/data2/primary/gpseg33/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29598_0001.0[sdw6]-rw1gpadmin

gpadmin1003683840Jul29

12:48/data1/primary/gpseg31/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29594_0001.0[sdw6]-rw1gpadmin

gpadmin1004732416Jul29

12:48/data2/primary/gpseg34/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29600_0001.0[sdw6]-rw1gpadmin

gpadmin986447872Jul29

12:48/data2/primary/gpseg35/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29602_0001.0[sdw6]-rw1gpadmin

gpadmin990543872Jul29

12:48/datal/primary/gpseg30/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_29592_0001.0[sdw6]-rw1gpadmin

gpadmin992870400Jul29

12:48/data1/primary/gpseg32/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_29596_0001.0[sdw7]-rw1gpadmin

gpadmin1007321088Jul29

12:48/data2/primary/gpseg39/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18530_0001.0[sdw7]-rw1gpadmin

gpadmin1011187712Jul29

12:48/data1/primary/gpseg37/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18526_0001.0[sdw7]-rw1gpadmin

gpadmin987332608Jul29

12:48/data2/primary/gpseg41/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18534_0001.0[sdw7]-rw1gpadmin

gpadmin994344960Jul29

12:48/datal/primary/gpseg38/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18528_0001.0[sdw7]-rw1gpadmin

gpadmin996114432Jul29

12:48/data2/primary/gpseg40/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_18532_0001.0[sdw7]-rw1gpadmin

gpadmin999194624Jul29

12:48/datal/primary/gpseg36/base/19979/pgsql_tmp/pgsql_t

mp_slicel0_sort_18524_0001.0[sdw8]-rw1gpadmin

gpadmin1002242048Jul29

12:48/data2/primary/gpseg46/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_l5675_0001.0[sdw8]-rw1gpadmin

gpadmin1003520000Jul29

12:48/datal/primary/gpseg43/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15669_0001.0[sdw8]-rw1gpadmin

gpadmin1008009216Jul29

12:48/data1/primary/gpseg44/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15671_0001.0[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:16/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0001.0[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:21/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0002.1[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:24/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0003.2[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:26/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0004.3[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:31/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0006.5[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:32/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0005.4[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:34/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0007.6[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:36/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0008.7[sdw8]-rw1gpadmin

gpadmin1073741824Jul29

12:43/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0009.8[sdw8]-rw1gpadmin

gpadmin924581888Jul29

12:48/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15673_0010.9[sdw8]-rw1gpadmin

gpadmin990085120Jul29

12:48/data1/primary/gpseg42/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_15667_0001.0[sdw8]-rw1gpadmin

gpadmin996933632Jul29

12:48/data2/primary/gpseg47/base/19979/pgsql_tmp/pgsql_t

mp_slice10_sort_l5677_0001.0

從結果可以發覺主機sdw8上的Segmentgpseg45是罪魁禍首。

4.運用SSH登錄到有問題的節點，并切換為root用戶，運用Isof找

到擁有排序臨時文件的進程PIDo

[root@sdw8?]#Isof

/data2/primary/gpseg45/base/19979/pgsql_tmp/

pgsql_tmp_slice10_sort_15673_0002.1COMMANDPIDUSERFD

TYPEDEVICESIZENODENAMEpostgres15673gpadminliu

REG8,481073741824

6442454675l/data2/primary/gpseg45/base/19979/pgsql_tmp

/pgsql_tmp_slice10_sort_l5673_0002.1

這個例子中PID15673也是文件名的一部分，然而并不是全部的臨時溢

出文件名都包含進程PID。

5.運用ps吩咐識別PID對應的數據庫和連接信息