/?

介紹本文介紹PivotalGreenplumDatabase數據庫（以下簡稱：Greenplum數據庫，或GPDB）的最佳實踐。最佳實踐是指能持續產生比其他方法更好結果的方法或者技術，它來自于實戰經驗，并被證實了遵循這些方法可以獲得可靠的預期結果。本最佳實踐旨在通過利用所有可能的知識和技術為正確使用GPDB提供有效參考。本文不是在教您如何使用Greenplum數據庫的功能，而是幫助您在設計、實現和使用Greenplum數據庫時了解需要遵循哪些最佳實踐。關于如何使用和實現具體的Greenplum數據庫特性，請參考

上的Greenplum數據庫幫助文檔以與

上的Sandbox和實踐指南。本文目的不是要涵蓋整個產品或者產品特性，而是概述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_protect_limit

設置單個節點數據庫（SegmentDatabase）可以為所有查詢分配的最大內存量。不要設置過高的

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）。保證資源隊列的內存配額不超過

gp_vmem_protect_limit。動態更新資源隊列配置以適應日常工作需要。詳見內存和負載管理（后續章節)分區只為大表設置分區，不要為小表設置分區。僅在根據查詢條件可以實現分區裁剪時使用分區表。建議優先使用范圍(Range)分區，否則使用列表(List)分區。根據查詢特點合理設置分區。不要使用相同的字段即做分區鍵又做分布鍵。不要使用默認分區。避免使用多級分區；盡量創建少量的分區，每個分區的數據更多些。通過查詢計劃的EXPLAIN結果來驗證查詢對分區表執行的是選擇性掃描（分區裁剪）。對于列存儲的表，不要創建過多的分區，否則會造成物理文件過多：Physicalfiles=Segments*Columns*Partitions。詳見分區（后續章節)索引一般來說GPDB中索引不是必需的。對于高基數的列存儲表，如果需要遍歷且查詢選擇性較高，則創建單列索引。頻繁更新的列不要建立索引。在加載大量數據之前刪除索引，加載結束后再重新創建索引。優先使用B樹索引。不要為需要頻繁更新的字段創建位圖索引。不要為唯一性字段，基數非常高或者非常低的字段創建位圖索引。不要為事務性負載創建位圖索引。一般來說不要索引分區表。如果需要建立索引，則選擇與分區鍵不同的字段。詳見索引（后續章節)資源隊列使用資源隊列管理集群的負載。為所有角色定義適當的資源隊列。使用ACTIVE_STATEMENTS參數限制隊列成員可以并發運行的查詢總數。使用MEMORY_LIMIT參數限制隊列中查詢可以使用的內存總量。不要設置所有隊列為MEDIUM，這樣起不到管理負載的作用。根據負載和時間段動態調整資源隊列。詳見配置資源隊列（后續章節)監控和維護根據《Greenplum數據庫管理員指南》實現該書推薦的監控和管理任務。安裝Greenplum數據庫前建議運行

gpcheckperf，安裝后定期運行。保存輸出結果，隨著時間推移對系統性能進行比較。使用所有您可用的工具，以了解系統不同負載下的表現。檢查任何不尋常的事件并確定原因。通過定期運行解釋計劃監控系統查詢活動，以確保查詢處于最佳運行狀態。檢查查詢計劃，以確定是否按預期使用了索引和進行了分區裁剪。了解系統日志文件的位置和內容，定期監控日志文件，而不是在出現問題時才查看。詳見系統監控和維護以與監控GPDB日志文件。（后續章節)ANALYZE不要對整個數據庫運行ANALYZE，只對需要的表運行該命令。建議數據加載后即刻運行ANALYZE。如果INSERT、UPDATE和DELETE等操作修改大量數據，建議運行ANALYZE。執行CREATEINDEX操作后建議運行ANALYZE。如果對大表ANALYZE耗時很久，則只對JOIN字段、WHERE、SORT、GROUPBY或HAVING字句的字段運行ANALYZE。詳見使用ANALYZE更新統計信息。（后續章節)Vaccum批量UPDATE和DELETE操作后建議執行VACUUM。不建議使用VACUUMFULL。建議使用CTAS（CREATETABLE...AS）操作，然后重命名表名，并刪除原來的表。對系統表定期運行VACUUM，以避免系統表臃腫和在系統表上執行VACUUMFULL操作。禁止殺死系統表的VACUUM任務。不建議使用VACUUMANALYZE。詳見消除系統表臃腫。（后續章節)加載使用gpfdist進行數據的加載和導出。隨著段數據庫個數的增加，并行性增加。盡量將數據均勻地分布到多個ETL節點上。將非常大的數據文件切分成相同大小的塊，并放在盡量多的文件系統上。一個文件系統運行兩個gpfdist實例。在盡可能多的網絡接口上運行gpfdsit。使用

gp_external_max_segs

控制訪問每個gpfdist服務器的段數據庫的個數。建議gp_external_max_segs的值和gpfdist進程個數為偶數。數據加載前刪除索引；加載完后重建索引。數據加載完成后運行ANALYZE操作。數據加載過程中，設置

gp_autostats_mode

為NONE，取消統計信息的自動收集。若數據加載失敗，使用VACUUM回收空間。詳見加載數據。（后續章節)gptransfer為了更好的性能，建議使用

gptransfer

遷移數據到相同大小或者更大的集群。避免使用

--full

或者

--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）是首選操作系統。應使用最新支持的主版本，目前是RHEL6。?

文件系統Greenplum數據庫的數據目錄推薦使用XFS文件系統。使用以下選項掛載XFS：rw,noatime,inode64,allocsize=16m?

端口配置ip_local_port_range

的設置不要和Greenplum數據庫的端口范圍有沖突，例如：net.ipv4.ip_local_port_range=300065535PORT_BASE=2000MIRROR_PORT_BASE=2100REPLICATION_PORT_BASE=2200MIRROR_REPLICATION_PORT_BASE=2300?

I/O配置包含數據目錄的設備的預讀大小應設為16384./sbin/blockdev--getra/dev/sdb16384

包含數據目錄的設備的I/O調度算法設置為deadline。#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數據庫工具指南》中的

gpcheck。?

設置一個主機上段數據庫個數確定每個段主機上段數據庫的個數對整體性能有著巨大影響。這些段數據庫之間共享主機的CPU核、內存、網卡等，且和主機上的所有進程共享這些資源。過高地估計每個服務器上運行的段數據庫個數，通常是達不到最優性能的常見原因之一。以下因素確定了一個主機上可以運行多少個段數據庫：CPU核的個數物理內存容量網卡個數與速度存儲空間主段數據庫和鏡像共存主機是否運行ETL進程主機上運行的非Greenplum進程?

段服務器內存配置服務器配置參數gp_vmem_protect_limit控制了每個段數據庫為所有運行的查詢分配的內存總量。如果查詢需要的內存超過此值，則會失敗。使用下面公式確定合適的值：(swap+(RAM*vm.overcommit_ratio))*.9/number_of_Segments_per_server例如，具有下面配置的段服務器：8GB交換空間128GB內存vm.overcommit_ratio=508個段數據庫則設置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*.9)/40=184MB每個查詢最多可以使用184MB內存，之后將溢出到磁盤。若想安全的增大

gp_statement_mem，要么增大

gp_vmem_protect_limit，要么降低并發。要增大gp_vmem_protect_limit，必須增加物理內存和/或交換空間，或者降低單個主機上運行的段數據庫個數。請注意，為集群添加更多的段數據庫實例并不能解決內存不足的問題，除非引入更多新主機來降低了單個主機上運行的段數據庫的個數。了解什么是溢出文件。了解gp_work

參數，其控制了單個查詢最多可以創建多少個溢出文件。了解gp_work。有關使用資源隊列管理內存的更多信息，請參考

內存和負載管理。（后續章節)?

溢出文件配置如果為SQL查詢分配的內存不足，Greenplum數據庫會創建溢出文件（也叫工作文件）。在默認情況下，一個SQL查詢最多可以創建100000個溢出文件，這足以滿足大多數查詢。參數gp_work

決定了一個查詢最多可以創建多少個溢出文件。0意味著沒有限制。限制溢出文件數據可以防止失控查詢破壞整個系統。如果分配內存不足或者出現數據傾斜，則一個SQL查詢可能產生大量溢出文件。如果超過溢出文件上限，Greenplum數據庫報告如下錯誤：ERROR:numberofworkfilesperquerylimitexceeded在嘗試增大gp_work前，先嘗試通過修改SQL、數據分布策略或者內存配置以降低溢出文件個數。gp_toolkit模式包括一些視圖，通過這些視圖可以看到所有使用溢出文件的查詢的信息。這些信息有助于故障排除和調優查詢：gp_work視圖的每一行表示一個正在使用溢出文件的操作符的信息。關于操作符，參考

如何理解查詢計劃解釋。（后續章節)gp_work視圖的每一行表示一個正在使用溢出文件的SQL查詢的信息。gp_work視圖的每一行對應一個段數據庫，包含了該段上使用的溢出文件占用的磁盤空間總量。關于這些視圖的字段涵義，請參考《Greenplum數據庫參考指南》。參數

gp_work指定溢出文件的壓縮算法：none或者zlib。第三章數據庫模式設計GPDB是一個基于大規模并行處理（MPP）和無共享架構的分析型數據庫。這種數據庫的數據模式與高度規范化的事務性SMP數據庫顯著不同。使用非規范化數據庫模式，例如具有大事實表和小維度表的星型或者雪花模式，處理MPP分析型業務時，Greenplum數據庫表現優異。?

數據類型類型一致性關聯列使用相同的數據類型。如果不同表中的關聯列數據類型不同，GPDB必須動態的進行類型轉換以進行比較。考慮到這一點，你可能需要增大數據類型的大小，以便關聯操作更高效。類型最小化建議選擇最高效的類型存儲數據，這可以提高數據庫的有效容量與查詢執行性能。建議使用TEXT或者VARCHAR而不是CHAR。不同的字符類型間沒有明顯的性能差別，但是TEXT或者VARCHAR可以降低空間使用量。建議使用滿足需求的最小數值類型。如果INT或SAMLLINT夠用，那么選擇BIGINT會浪費空間。?

存儲模型在Greenplum數據庫中，創建表時可以選擇不同的存儲類型。需要清楚什么時候該使用堆存儲、什么時候使用追加優化(AO)存儲、什么時候使用行存儲、什么時候使用列存儲。對于大型事實表這尤為重要。相比而言，對小的維度表就不那么重要了。選擇合適存儲模型的常規最佳實踐為：對于大型事實分區表，評估并優化不同分區的存儲選項。一種存儲模型可能滿足不了整個分區表的不同分區的應用場景，例如某些分區使用行存儲而其他分區使用列存儲。使用列存儲時，段數據庫內每一列對應一個文件。對于有大量列的表，經常訪問的數據使用列存儲，不常訪問的數據使用行存儲。在分區級別或者在數據存儲級別上設置存儲類型。如果集群需要更多空間，或者期望提高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數據庫非常重要。在大規模并行處理無共享環境中，查詢的總體響應時間取決于所有段數據庫的完成時間。集群的最快速度與最慢的那個段數據庫一樣。如果存在嚴重數據傾斜現象，那么數據較多的段數據庫響應時間將更久。每個段數據庫最好有數量接近的數據，處理時間也相似。如果一個段數據庫處理的數據顯著比其他段多，那么性能會很差，并可能出現內存溢出錯誤。確定分布策略時考慮以下最佳實踐：為所有表要么明確地指明其分布字段，要么使用隨機分布。不要使用默認方式。理想情況下，使用能夠將數據均勻分布到所有段數據庫上的一個字段做分布鍵。不要使用常出現在查詢的WHERE子句中的字段做分布鍵。不要使用日期或者時間字段做分布鍵。分布字段的數據要么是唯一值要么基數很大。如果單個字段不能實現數據均勻分布，則考慮使用兩個字段做分布鍵。作為分布鍵的字段最好不要超過兩個。GPDB使用哈希進行數據分布，使用更多的字段通常不能得到更均勻的分布，反而耗費更多的時間計算哈希值。如果兩個字段也不能實現數據的均勻分布，則考慮使用隨機分布。大多數情況下，如果分布鍵字段超過兩個，那么執行表關聯時通常需要節點間的數據移動操作（Motion），如此一來和隨機分布相比，沒有明顯優勢。Greenplum數據庫的隨機分布不是輪詢算法，不能保證每個節點的記錄數相同，但是通常差別會小于10%。關聯大表時最優分布至關重要。關聯操作需要匹配的記錄必須位于同一段數據庫上。如果分布鍵和關聯字段不同，則數據需要動態重分發。某些情況下，廣播移動操作（Motion）比重分布移動操作效果好。本地（Co-located）關聯如果所用的哈希分布能均勻分布數據，并導致本地關聯，那么性能會大幅提升。本地關聯在段數據庫內部執行，和其他段數據庫沒有關系，避免了網絡通訊開銷，避免或者降低了廣播移動操作和重分布移動操作。為經常關聯的大表使用相同的字段做分布鍵可實現本地關聯。本地關聯需要關聯的雙方使用相同的字段（且順序相同）做分布鍵，并且關聯時所有的字段都被使用。分布鍵數據類型必須相同。如果數據類型不同，磁盤上的存儲方式可能不同，那么即使值看起來相同，哈希值也可能不一樣。數據傾斜數據傾斜是很多性能問題和內存溢出問題的根本原因。數據傾斜不僅影響掃描/讀性能，也會影響很多其他查詢執行操作符，例如關聯操作、分組操作等。數據初始加載后，驗證并保證數據分布的均勻性非常重要；每次增量加載后，都要驗證并保證數據分布的均勻性。下面的查詢語句統計每個段數據庫上的記錄的條數，并根據最大和最小行數計算方差：SELECT'ExampleTable'AS"TableName",max(c)AS"MaxSegRows",min(c)AS"MinSegRows",(max(c)-min(c))*100.0/max(c)AS"PercentageDifferenceBetweenMax&Min"FROM(SELECTcount(*)c,gp_Segment_idFROMfactsGROUPBY2)ASa;gp_tooklit

模式中有兩個視圖可以幫助檢查傾斜情況：視圖gp_toolkit.gp_skew_coefficients

通過計算每個段數據庫所存儲數據的變異系數（coefficientofvariation,CV）來顯示數據傾斜情況。skccoeff

字段表示變異系數，通過標準偏差除以均值計算而來。它同時考慮了數據的均值和可變性。這個值越小越好，值越高表示數據傾斜越嚴重。視圖gp_toolkit.gp_skew_idle_fractions

通過計算表掃描時系統空閑的百分比顯示數據分布傾斜情況，這是表示計算傾斜情況的一個指標。siffraction

字段顯示了表掃描時處于空閑狀態的系統的百分比。這是數據不均勻分布或者查詢處理傾斜的一個指標。例如，0.1表示10%傾斜，0.5表示50%傾斜，以此類推。如果傾斜超過10%，則需對其分布策略進行評估。計算傾斜（ProceddingSkew）當不均衡的數據流向并被某個或者少數幾個段數據庫處理時將出現計算傾斜。這常常是Greenplum數據庫性能和穩定性問題的罪魁禍首。關聯、排序、聚合和各種OLAP操作中易發生計算傾斜。計算傾斜發生在查詢執行時，不如數據傾斜那么容易檢測，通常是由于選擇了不當的分布鍵造成數據分布不均勻而引起的。數據傾斜體現在表級別，所以容易檢測，并通過選擇更好的分布鍵避免。如果單個段數據庫失敗（不是某個節點上的所有段實例），那么可能是計算傾斜造成的。識別計算傾斜目前主要靠手動。首先查看臨時溢出文件，如果有計算傾斜，但是沒有造成臨時溢出文件，則不會影響性能。下面是檢查的步驟和所用的命令：1.找到懷疑發生計算傾斜的數據庫的OID：SELECToid,datnameFROMpg_database;例子輸出:oid|datname+17088|gpadmin10899|postgres1|template110898|template038817|pws39682|gpperfmon(6rows)2.使用gpssh檢查所有Segments上的溢出文件大小。使用上面結果中的OID替換:[gpadmin@mdw

kend]$gpssh-f~/hosts-e\"du-b/data[1-2]/primary/gpseg*/base/<OID>/pgsql_tmp/*"|\grep-v"du-b"|sort|\awk-F""'{arr[$1]=arr[$1]+$2;tot=tot+

$2};\END{for(iinarr)print"Segmentnode"i,arr,\"bytes("arr/(1024**3)"GB)";\print"Total",tot,"bytes("tot/(1024**3)"GB)"}'-例子輸出:Segmentnode[sdw1]2443370457bytes(2.27557GB)Segmentnode[sdw2]1766575328bytes(1.64525GB)Segmentnode[sdw3]1761686551bytes(1.6407GB)Segmentnode[sdw4]1780301617bytes(1.65804GB)Segmentnode[sdw5]1742543599bytes(1.62287GB)Segmentnode[sdw6]1830073754bytes(1.70439GB)Segmentnode[sdw7]1767310099bytes(1.64594GB)Segmentnode[sdw8]1765105802bytes(1.64388GB)Totaytes(13.8366GB)如果不同段數據庫的磁盤使用量持續差別巨大，那么需要一進步查看當前執行的查詢是否發生了計算傾斜（上面的例子可能不太恰當，因為沒有顯示出明顯的傾斜）。在很多監控系統中，總是會發生某種程度的傾斜，如果僅是臨時性的，則不必深究。3.如果發生了嚴重的持久性傾斜，接下來的任務是找到有問題的查詢。上一步命令計算的是整個節點的磁盤使用量。現在我們要找到對應的段數據庫(Segment)目錄。可以從主節點（Master）上，也可以登錄到上一步識別出的Segment上做本操作。下面例子演示從Master執行操作。本例找的是排序生成的臨時文件。然而并不是所有情況都是由排序引起的，需要具體問題具體分析：[gpadmin@mdw

kend]$gpssh-f~/hosts-e\"ls-l/data[1-2]/primary/gpseg*/base/19979/pgsql_tmp/*"|grep-isort|sort下面是例子輸出：

[sdw1]-rw1gpadmingpadmin1002209280Jul2912:48/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19791_0001.0[sdw1]-rw1gpadmingpadmin1003356160Jul2912:48/data1/primary/gpseg1/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19789_0001.0[sdw1]-rw1gpadmingpadmin288718848Jul2314:58/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice0_sort_17758_0001.0[sdw1]-rw1gpadmingpadmin291176448Jul2314:58/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tmp_slice0_sort_17764_0001.0[sdw1]-rw1gpadmingpadmin988446720Jul2912:48/data1/primary/gpseg0/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19787_0001.0[sdw1]-rw1gpadmingpadmin995033088Jul2912:48/data2/primary/gpseg3/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19793_0001.0[sdw1]-rw1gpadmingpadmin997097472Jul2912:48/data2/primary/gpseg5/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19797_0001.0[sdw1]-rw1gpadmingpadmin997392384Jul2912:48/data2/primary/gpseg4/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19795_0001.0[sdw2]-rw1gpadmingpadmin1002340352Jul2912:48/data2/primary/gpseg11/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3973_0001.0[sdw2]-rw1gpadmingpadmin1004339200Jul2912:48/data1/primary/gpseg8/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3967_0001.0[sdw2]-rw1gpadmingpadmin989036544Jul2912:48/data2/primary/gpseg10/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3971_0001.0[sdw2]-rw1gpadmingpadmin993722368Jul2912:48/data1/primary/gpseg6/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3963_0001.0[sdw2]-rw1gpadmingpadmin998277120Jul2912:48/data1/primary/gpseg7/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3965_0001.0[sdw2]-rw1gpadmingpadmin999751680Jul2912:48/data2/primary/gpseg9/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_3969_0001.0[sdw3]-rw1gpadmingpadmin1000112128Jul2912:48/data1/primary/gpseg13/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24723_0001.0[sdw3]-rw1gpadmingpadmin1004797952Jul2912:48/data2/primary/gpseg17/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24731_0001.0[sdw3]-rw1gpadmingpadmin1004994560Jul2912:48/data2/primary/gpseg15/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24727_0001.0[sdw3]-rw1gpadmingpadmin1006108672Jul2912:48/data1/primary/gpseg14/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24725_0001.0[sdw3]-rw1gpadmingpadmin998244352Jul2912:48/data1/primary/gpseg12/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24721_0001.0[sdw3]-rw1gpadmingpadmin998440960Jul2912:48/data2/primary/gpseg16/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_24729_0001.0[sdw4]-rw1gpadmingpadmin1001029632Jul2912:48/data2/primary/gpseg23/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29435_0001.0[sdw4]-rw1gpadmingpadmin1002504192Jul2912:48/data1/primary/gpseg20/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29429_0001.0[sdw4]-rw1gpadmingpadmin1002504192Jul2912:48/data2/primary/gpseg21/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29431_0001.0[sdw4]-rw1gpadmingpadmin1009451008Jul2912:48/data1/primary/gpseg19/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29427_0001.0[sdw4]-rw1gpadmingpadmin980582400Jul2912:48/data1/primary/gpseg18/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29425_0001.0[sdw4]-rw1gpadmingpadmin993230848Jul2912:48/data2/primary/gpseg22/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29433_0001.0[sdw5]-rw1gpadmingpadmin1000898560Jul2912:48/data2/primary/gpseg28/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28641_0001.0[sdw5]-rw1gpadmingpadmin1003388928Jul2912:48/data2/primary/gpseg29/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28643_0001.0[sdw5]-rw1gpadmingpadmin1008566272Jul2912:48/data1/primary/gpseg24/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28633_0001.0[sdw5]-rw1gpadmingpadmin987332608Jul2912:48/data1/primary/gpseg25/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28635_0001.0[sdw5]-rw1gpadmingpadmin990543872Jul2912:48/data2/primary/gpseg27/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28639_0001.0[sdw5]-rw1gpadmingpadmin999620608Jul2912:48/data1/primary/gpseg26/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_28637_0001.0[sdw6]-rw1gpadmingpadmin1002242048Jul2912:48/data2/primary/gpseg33/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29598_0001.0[sdw6]-rw1gpadmingpadmin1003683840Jul2912:48/data1/primary/gpseg31/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29594_0001.0[sdw6]-rw1gpadmingpadmin1004732416Jul2912:48/data2/primary/gpseg34/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29600_0001.0[sdw6]-rw1gpadmingpadmin986447872Jul2912:48/data2/primary/gpseg35/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29602_0001.0[sdw6]-rw1gpadmingpadmin990543872Jul2912:48/data1/primary/gpseg30/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29592_0001.0[sdw6]-rw1gpadmingpadmin992870400Jul2912:48/data1/primary/gpseg32/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29596_0001.0[sdw7]-rw1gpadmingpadmin1007321088Jul2912:48/data2/primary/gpseg39/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18530_0001.0[sdw7]-rw1gpadmingpadmin1011187712Jul2912:48/data1/primary/gpseg37/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18526_0001.0[sdw7]-rw1gpadmingpadmin987332608Jul2912:48/data2/primary/gpseg41/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18534_0001.0[sdw7]-rw1gpadmingpadmin994344960Jul2912:48/data1/primary/gpseg38/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18528_0001.0[sdw7]-rw1gpadmingpadmin996114432Jul2912:48/data2/primary/gpseg40/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18532_0001.0[sdw7]-rw1gpadmingpadmin999194624Jul2912:48/data1/primary/gpseg36/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18524_0001.0[sdw8]-rw1gpadmingpadmin1002242048Jul2912:48/data2/primary/gpseg46/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15675_0001.0[sdw8]-rw1gpadmingpadmin1003520000Jul2912:48/data1/primary/gpseg43/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15669_0001.0[sdw8]-rw1gpadmingpadmin1008009216Jul2912:48/data1/primary/gpseg44/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15671_0001.0[sdw8]-rw1gpadmingpadmin1073741824Jul2912:16/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0001.0[sdw8]-rw1gpadmingpadmin1073741824Jul2912:21/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1[sdw8]-rw1gpadmingpadmin1073741824Jul2912:24/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0003.2[sdw8]-rw1gpadmingpadmin1073741824Jul2912:26/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0004.3[sdw8]-rw1gpadmingpadmin1073741824Jul2912:31/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0006.5[sdw8]-rw1gpadmingpadmin1073741824Jul2912:32/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0005.4[sdw8]-rw1gpadmingpadmin1073741824Jul2912:34/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0007.6[sdw8]-rw1gpadmingpadmin1073741824Jul2912:36/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0008.7[sdw8]-rw1gpadmingpadmin1073741824Jul2912:43/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0009.8[sdw8]-rw1gpadmingpadmin924581888Jul2912:48/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0010.9[sdw8]-rw1gpadmingpadmin990085120Jul2912:48/data1/primary/gpseg42/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15667_0001.0[sdw8]-rw1gpadmingpadmin996933632Jul2912:48/data2/primary/gpseg47/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15677_0001.0從結果可以發現主機sdw8上的Segmentgpseg45是罪魁禍首。4.使用SSH登錄到有問題的節點，并切換為root用戶，使用lsof

找到擁有排序臨時文件的進程PID。[root@sdw8

~]#lsof/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1COMMANDPIDUSERFDTYPEDEVICESIZENODENAMEpostgres15673gpadmin11uREG8,48107374182464424546751/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1這個例子中PID15673也是文件名的一部分，然而并不是所有的臨時溢出文件名都包含進程PID。5.使用

ps

命令識別PID對應的數據庫和連接信息。[root@sdw8

~]#ps-eaf|grep15673gpadmin15673274712812:05?00:12:59postgres:port40003,sbaskinbdw50(21813)con699238seg45cmd32slice10MPPEXECSELECTroot2962229566012:50pts/1600:00:00grep156736.最后，我們可以找到造成傾斜的查詢語句。到主節點（Master）上，根據用戶名(sbaskin)、連接信息(con699238)和命令信息(cmd32)查找pg_log下面的日志文件。找到對應的日志行，該行應該包含出問題的查詢語句。有時候cmd數字可能不一致。例如ps輸出中postgres進程顯示的是cmd32，而日志中可能會是cmd34。如果分析的是正在運行的查詢語句，則該用戶在對應連接上運行的最后一條語句就是出問題的查詢語句。大多數情況下解決這種問題是重寫查詢語句。創建臨時表可以避免傾斜。設置臨時表使用隨機分布，這樣會強制執行兩階段聚合(two-stageaggregation)。?

分區（PARTITIONING)好的分區策略可以讓查詢只掃描需要訪問的分區，以降低掃描的數據量。在每個段數據庫上的每個分區都是一個物理文件。讀取分區表的所有分區比讀取相同數據量的非分區表需要更多時間。以下是分區最佳實踐：只為大表設置分區，不要為小表設置分區。僅在根據查詢條件可以實現分區裁剪時對大表使用分區。建議優先使用范圍(Range)分區，否則使用列表(List)分區。僅當SQL查詢包含使用不變操作符（例如=，<,<=,>=,<>）的簡單直接的約束時，查詢優化器才會執行分區裁剪。選擇性掃描可以識別查詢中的STABLE和IMMUTABLE函數，但是不能識別VOLATILE函數。例如查詢優化器對下面的WHERE子句date>CURRENT_DATE可以啟用分區裁剪，但是如果WHERE子句如下則不會啟用分區裁剪。time>TIMEOFDAY通過檢查查詢的EXPLAIN計劃驗證是否執行分區裁剪非常重要。不要使用默認分區。默認分區總是會被掃描，更重要的是很多情況下會導致溢出而造成性能不佳。切勿使用相同的字段既做分區鍵又做分布鍵避免使用多級分區。雖然支持子分區但不推薦，因為通常子分區包含數據不多甚至沒有。隨著分區或者子分區增多性能可能會提高，然而維護這些分區和子分區的代價將超過性能的提升。基于性能、擴展性和可管理性，在掃描性能和分區總數間取得平衡。對于列存儲的表，慎用過多的分區。考慮好并發量和所有并發查詢打開和掃描的分區均值。分區數目和列存儲文件Greenplum數據庫對于文件數目的唯一硬性限制是操作系統的打開文件限制。然而也需要考慮到集群的文件總數、每個段數據庫(Segment)上的文件數和每個主機上的文件總數。在MPP無共享環境中，節點獨立運行。每個節點受其磁盤、CPU和內存的約束。Greenplum數據庫中CPU和I/O較少成為瓶頸，而內存卻比較常見，因為查詢執行器需要使用內存優化查詢的性能。Segment的最佳文件數與每個主機節點上Segment個數、集群大小、SQL訪問模式、并發度、負載和傾斜等都有關系。通常一個主機上配置六到八個Segments，對于大集群建議為每個主機配置更少的Segment。使用分區和列存儲時平衡集群中的文件總數很重要，但是更重要的是考慮好每個Segment的文件數和每個主機上的文件數。例如EMCDCAV2每個節點64GB內存：節點數：16每個節點Segment數：8每個Segment的文件均數：10000一個節點的文件總數是：8*10000=80000，集群的文件總數是：8*16*10000=1280000.隨著分區增加和列字段的增加，文件數目增長很快。做為一個最佳實踐，單個節點的文件總數上限為100000。如前面例子所示，Segment的最佳文件數和節點的文件總數和節點的硬件配置（主要是內存）、集群大小、SQL訪問、并發度、負載和數據傾斜等相關。?

索引Greenplum數據庫通常不用索引，因為大多數的分析型查詢都需要處理大量數據，而順序掃描時數據讀取效率較高，因為每個段數據庫(Segment)含有數量相當的數據，且所有Segment并行讀取數據。對于具有高選擇性的查詢，索引可以提高查詢性能。即使明確需要索引，也不要索引經常更新的字段。對頻繁更新的字段建立索引會增加數據更新時寫操作的代價。僅當表達式常在查詢中使用時才建立基于表達式的索引。謂詞索引會創建局部索引，可用于從大表中選擇少量行的情況。避免重復索引。具有相同前綴字段的索引是冗余的。對于壓縮AO表，索引可以提高那些指返回少量匹配行的查詢的性能。對于壓縮數據，索引可以降低需要解壓縮的頁面數。創建選擇性高的B樹索引。索引選擇性是指：表的索引字段的不同值總數除以總行數。例如，如果一個表有1000行，索引列具有800個不同的值，那么該索引的選擇性為0.8，這是一個良好的選擇性值。如果創建索引后查詢性能沒有顯著地提升，則刪除該索引。確保創建的每個索引都被優化器采用。加載數據前務必刪除索引。加載速度比帶索引快一個數量級。加載完成后，重建索引。位圖索引適合查詢而不適合更新業務。當列的基數較低（譬如100到100000個不同值）時位圖索引性能最好。不要對唯一列、基數很高的列或者基數很低的列建立位圖索引。不要為業務性負載使用位圖索引。一般來說，不要索引分區表。如果需要，索引字段不要和分區字段相同。分區表索引的一個優勢在于：隨著B樹的增大，B樹的性能呈指數下降，因而分區表上創建的索引對應的B樹比較小，性能比非分區表好。?

字段順序和字節對齊為了獲得最佳性能，建議對表的字段順序進行調整以實現數據類型的字節對齊。對堆表使用下面的順序：分布鍵和分區鍵固定長度的數值類型可變長度的數據類型從大到小布局數據類型，BIGINT和TIMESTAMP在INT和DATE類型之前，TEXT，VARCHAR和NUMERIC(x,y)位于后面。例如首先定義8字節的類型（BIGINT，TIMESTAMP）字段，然后是4字節類型（INT，DATE），隨后是2字節類型（SMALLINT），最后是可變長度數據類型（VARCHAR）。如果你的字段定義如下：Int,Bigint,Timestamp,Bigint,Timestamp,Int(分布鍵),Date(分區鍵),Bigint,Smallint則建議調整為：Int(分布鍵),Date(分區鍵),Bigint,Bigint,Bigint,Timestamp,Timestamp,Int,Smallint第四章內存和負載管理內存管理對GPDB集群性能有顯著影響。默認設置可以滿足大多數環境需求。不要修改默認設置，除非你理解系統的內存特性和使用情況。如果精心設計內存管理，大多數內存溢出問題可以避免。下面是GPDB內存溢出的常見原因：集群的系統內存不足內存參數設置不當段數據庫(Segment)級別的數據傾斜查詢級別的計算傾斜有時不僅可以通過增加系統內存解決問題，還可以通過正確的配置內存和設置恰當的資源隊列管理負載，以避免很多內存溢出問題。建議使用如下參數來配置操作系統和數據庫的內存：vm.overcommit_memory這是/etc/sysctl.conf中設置的一個Linux內核參數。總是設置其值為2。它控制操作系統使用什么方法確定分配給進程的內存總數。對于Greenplum數據庫，唯一建議值是2。vm.overcommit_ratio這是/etc/sysctl.conf中設置的一個Linux內核參數。它控制分配給應用程序進程的內存百分比。建議使用缺省值50.不要啟用操作系統的大內存頁gp_vmem_protect_limit使用

gp_vmem_protect_limit

設置段數據庫(Segment)能為所有任務分配的最大內存。切勿設置此值超過系統物理內存。如果

gp_vmem_protect_limit

太大，可能造成系統內存不足，引起正常操作失敗，進而造成段數據庫故障。如果gp_vmem_protect_limit設置為較低的安全值，可以防止系統內存真正耗盡；打到內存上限的查詢可能失敗，但是避免了系統中斷和Segment故障，這是所期望的行為。

gp_vmem_protect_limit

的計算公式為：(SWAP+(RAM*vm.overcommit_ratio))*.9/number_Segments_per_serverrunaway_detector_activation_percentGreenplum數據庫4.3.4引入了失控查詢終止（RunawayQueryTermination）機制避免內存溢出。系統參數runaway_detector_activation_percent控制內存使用達到

gp_vmem_protect_limit的多少百分比時會終止查詢，默認值是90%。如果某個Segment使用的內存超過了gp_vmem_protect_limit的90%（或者其他設置的值），Greenplum數據庫會根據內存使用情況終止那些消耗內存最多的SQL查詢，直到低于期望的閾值。statement_mem使用

statement_mem

控制Segment數據庫分配給單個查詢的內存。如果需要更多內存完成操作，則會溢出到磁盤（溢出文件，spillfiles）。statement_mem

的計算公式為：(vmprotect*.9)/max_expected_concurrent_queriesstatement_mem

的默認值是125MB。例如使用這個默認值，EMCDCAV2的一個查詢在每個Segment服務器上需要1GB內存（8Segments*125MB）。對于需要更多內存才能執行的查詢，可以設置回話級別的

statement_mem。對于并發度比較低的集群，這個設置可以較好的管理查詢內存使用量。并發度高的集群也可以使用資源隊列對系統運行什么任務和怎么運行提供額外的控制。gp_workgp_work

限制一個查詢可用的臨時溢出文件數。當查詢需要比分配給它的內存更多的內存時將創建溢出文件。當溢出文件超出限額時查詢被終止。默認值是0，表示溢出文件數目沒有限制，可能會用光文件系統空間。gp_work如果有大量溢出文件，則設置gp_work對溢出文件壓縮。壓縮溢出文件也有助于避免磁盤子系統I/O操作超載。?

配置資源隊列Greenplum數據庫的資源隊列提供了強大的機制來管理集群的負載。隊列可以限制同時運行的查詢的數量和內存使用量。當Greenplum數據庫收到查詢時，將其加入到對應的資源隊列，隊列確定是否接受該查詢以與何時執行它。不要使用默認的資源隊列，為所有用戶都分配資源隊列。每個登錄用戶（角色）都關聯到一個資源隊列；用戶提交的所有查詢都由相關的資源隊列處理。如果沒有明確關聯到某個隊列，則使用默認的隊列

pg_default。避免使用gpadmin角色或其他超級用戶角色運行查詢超級用戶不受資源隊列的限制，因為超級用戶提交的查詢始終運行，完全無視相關聯的資源隊列的限制。使用資源隊列參數ACTIVE_STATEMENTS限制某個隊列的成員可以同時運行的查詢的數量。使用MEMORY_LIMIT參數控制隊列中當前運行查詢的可用內存總量。聯合使用ACTIVE_STATEMENTS和MEMORY_LIMIT屬性可以完全控制資源隊列的活動。隊列工作機制