Greenplum 數(shù)據(jù)庫最佳實踐

/?

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

上的Greenplum數(shù)據(jù)庫幫助文檔以與

上的Sandbox和實踐指南。本文目的不是要涵蓋整個產(chǎn)品或者產(chǎn)品特性，而是概述GPDB實踐中最重要的因素。本文不涉與依賴于GPDB具體特性的邊緣用例，后者需要精通數(shù)據(jù)庫特性和您的環(huán)境，包括SQL訪問、查詢執(zhí)行、并發(fā)、負(fù)載和其他因素。通過掌握這些最佳實踐知識，會增加GPDB集群在維護、支持、性能和可擴展性等方面的成功率。第一章

最佳實踐概述本部分概述了Greenplum數(shù)據(jù)庫最佳實踐所涉與的概念與要點。數(shù)據(jù)模型GPDB是一個基于大規(guī)模并行處理(MPP)和無共享架構(gòu)的分析型數(shù)據(jù)庫。這種數(shù)據(jù)庫的數(shù)據(jù)模式與高度規(guī)范化的事務(wù)性SMP數(shù)據(jù)庫顯著不同。通過使用非規(guī)范化數(shù)據(jù)庫模式，例如具有大事實表和小維度表的星型或者雪花模式，GPDB在處理MPP分析型業(yè)務(wù)時表現(xiàn)優(yōu)異?？绫黻P(guān)聯(lián)(JOIN)時字段使用相同的數(shù)據(jù)類型。詳見數(shù)據(jù)庫模式設(shè)計（后續(xù)章節(jié))堆存儲和追加優(yōu)化存儲(Append-Optimized，下稱AO)若表和分區(qū)表需要進行迭代式的批處理或者頻繁執(zhí)行單個UPDATE、DELETE或INSERT操作，使用堆存儲。若表和分區(qū)表需要并發(fā)執(zhí)行UPDATE、DELETE或INSERT操作，使用堆存儲。若表和分區(qū)表在數(shù)據(jù)初始加載后更新不頻繁，且僅以批處理方式插入數(shù)據(jù)，則使用AO存儲。不要對AO表執(zhí)行單個INSERT、UPDATE或DELETE操作。不要對AO表執(zhí)行并發(fā)批量UPDATE或DELETE操作，但可以并發(fā)執(zhí)行批量INSERT操作。詳見堆存儲和AO存儲（后續(xù)章節(jié))行存儲和列存儲若數(shù)據(jù)需要經(jīng)常更新或者插入，則使用行存儲。若需要同時訪問一個表的很多字段，則使用行存儲。對于通用或者混合型業(yè)務(wù)，建議使用行存儲。若查詢訪問的字段數(shù)目較少，或者僅在少量字段上進行聚合操作，則使用列存儲。若僅常常修改表的某一字段而不修改其他字段，則使用列存儲。詳見行存儲和列存儲（后續(xù)章節(jié))壓縮對于大AO表和分區(qū)表使用壓縮，以提高系統(tǒng)I/O。在字段級別配置壓縮。考慮壓縮比和壓縮性能之間的平衡。詳見壓縮（后續(xù)章節(jié))分布為所有表定義分布策略：要么定義分布鍵，要么使用隨機分布。不要使用缺省分布方式。優(yōu)先選擇可均勻分布數(shù)據(jù)的單個字段做分布鍵。不要選擇經(jīng)常用于WHERE子句的字段做分布鍵。不要使用日期或時間字段做分布鍵。分布鍵和分區(qū)鍵不要使用同一字段。對經(jīng)常執(zhí)行JOIN操作的大表，優(yōu)先考慮使用關(guān)聯(lián)字段做分布鍵，盡量做到本地關(guān)聯(lián)，以提高性能。數(shù)據(jù)初始加載后或者每次增量加載后，檢查數(shù)據(jù)分布是否均勻。盡可能避免數(shù)據(jù)傾斜。詳見分布（后續(xù)章節(jié))內(nèi)存管理設(shè)置

vm.overcommit_memory

為2不要為操作系統(tǒng)的頁設(shè)置過大的值使用

gp_vmem_protect_limit

設(shè)置單個節(jié)點數(shù)據(jù)庫（SegmentDatabase）可以為所有查詢分配的最大內(nèi)存量。不要設(shè)置過高的

gp_vmem_protect_limit

值，也不要大于系統(tǒng)的物理內(nèi)存。gp_vmem_protect_limit

的建議值計算公式為：(SWAP+(RAM*vm.overcommit_ratio))*0.9/number_Segments_per_server使用

statement_mem

控制節(jié)點數(shù)據(jù)庫為單個查詢分配的內(nèi)存量。使用資源隊列設(shè)置隊列允許的當(dāng)前最大查詢數(shù)（ACTIVE_STATEMENTS）和允許使用的內(nèi)存大?。∕EMORY_LIMIT）。不要使用默認(rèn)的資源隊列，為所有用戶都分配資源隊列。根據(jù)負(fù)載和時間段，設(shè)置和隊列實際需求相匹配的優(yōu)先級（PRIORITY）。保證資源隊列的內(nèi)存配額不超過

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

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

gp_external_max_segs

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

gp_autostats_mode

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

gptransfer

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

--full

或者

--schema-only

選項。建議使用其他方法拷貝數(shù)據(jù)庫模式到目標(biāo)數(shù)據(jù)庫，然后遷移數(shù)據(jù)。遷移數(shù)據(jù)前刪除索引，遷移完成后重建索引。使用SQLCOPY命令遷移小表到目標(biāo)數(shù)據(jù)庫。使用gptransfer批量遷移大表。在正式遷移生產(chǎn)環(huán)境前測試運行

gptransfer。試驗

--batch-size

和

--sub-batch-size

選項以獲得最大平行度。如果需要，迭代運行多次

gptransfer

來確定每次要遷移的表的批次。僅使用完全限定的表名。表名字中若含有點、空格、單引號和雙引號，可能會導(dǎo)致問題。如果使用

--validation

選項在遷移后驗證數(shù)據(jù)，則需要同時使用

-x

選項，以在源表上加排它鎖。確保在目標(biāo)數(shù)據(jù)庫上創(chuàng)建了相應(yīng)的角色、函數(shù)和資源隊列。gptransfer-t

不會遷移這些對象。從源數(shù)據(jù)庫拷貝

postgres.conf

和

pg_hba.conf

到目標(biāo)數(shù)據(jù)庫集群。使用

gppkg

在目標(biāo)數(shù)據(jù)庫上安裝需要的擴展。詳見使用gptransfer遷移數(shù)據(jù)（后續(xù)章節(jié))安全妥善保護

gpadmin

賬號，只有在必要的時候才能允許系統(tǒng)管理員訪問它。僅當(dāng)執(zhí)行系統(tǒng)維護任務(wù)（例如升級或擴容），管理員才能以

gpadmin

登錄Greenplum集群。限制具有SUPERUSER角色屬性的用戶數(shù)。GPDB中，身為超級用戶的角色會跳過所有訪問權(quán)限檢查和資源隊列限制。僅有系統(tǒng)管理員具有數(shù)據(jù)庫超級用戶權(quán)限。參考《Greenplum數(shù)據(jù)庫管理員指南》中的“修改角色屬性”。嚴(yán)禁數(shù)據(jù)庫用戶以

gpadmin

身份登錄，嚴(yán)禁以

gpadmin

身份執(zhí)行ETL或者生產(chǎn)任務(wù)。為有登錄需求的每個用戶都分配一個不同的角色。考慮為每個應(yīng)用或者網(wǎng)絡(luò)服務(wù)分配一個不同的角色。使用用戶組管理訪問權(quán)限。保護好ROOT的密碼。對于操作系統(tǒng)密碼，強制使用強密碼策略。確保保護好操作系統(tǒng)的重要文件。詳見安全。（后續(xù)章節(jié))加密加密和解密數(shù)據(jù)會影響性能，僅加密需要加密的數(shù)據(jù)。在生產(chǎn)系統(tǒng)中實現(xiàn)任何加密解決方案之前都要做性能測試。GPDB生產(chǎn)系統(tǒng)使用的服務(wù)器證書應(yīng)由證書簽名頒發(fā)機構(gòu)（CA）簽名，這樣客戶端可以驗證服務(wù)器。如果所有客戶端都是本地的，則可以使用本地CA。如果客戶端與GPDB的連接會經(jīng)過不安全的鏈路，則使用SSL加密。加密和解密使用相同密鑰的對稱加密方式比非對稱加密具有更好的性能，如果密鑰可以安全共享，則建議使用對稱加密方式。使用pgcrypto包中的函數(shù)加密磁盤上的數(shù)據(jù)。數(shù)據(jù)的加密和解密都由數(shù)據(jù)庫進程完成，為了避免傳輸明文數(shù)據(jù)，需要使用SSL加密客戶端和數(shù)據(jù)庫間的連接。數(shù)據(jù)加載和導(dǎo)出時，使用gpfdists協(xié)議保護ETL數(shù)據(jù)安全。詳見加密數(shù)據(jù)和數(shù)據(jù)庫連接。（后續(xù)章節(jié))高可用使用8到24個磁盤的硬件RAID存儲解決方案。使用RAID1、5或6，以使磁盤陣列可以容忍磁盤故障。為磁盤陣列配備熱備磁盤，以便在檢測到磁盤故障時自動開始重建。在重建時通過RAID卷鏡像防止整個磁盤陣列故障和性能下降。定期監(jiān)控磁盤利用率，并在需要時增加額外的空間。定期監(jiān)控段數(shù)據(jù)庫傾斜，以確保在所有段數(shù)據(jù)庫上數(shù)據(jù)均勻分布，存儲空間均勻消耗。配置備用主服務(wù)器，當(dāng)主服務(wù)器發(fā)生故障時由備用主服務(wù)器接管。規(guī)劃好當(dāng)主服務(wù)器發(fā)生故障時如何切換客戶端連接到新的主服務(wù)器實例，例如通過更新DNS中主服務(wù)器的地址。建立監(jiān)控系統(tǒng)，當(dāng)主服務(wù)器發(fā)生故障時，可以通過系統(tǒng)監(jiān)控應(yīng)用或電子郵件發(fā)送通知。分配主段數(shù)據(jù)庫和其鏡像到不同的主機上，以防止主機故障。建立監(jiān)控系統(tǒng)，當(dāng)主段數(shù)據(jù)庫發(fā)生故障時，可以通過系統(tǒng)監(jiān)控應(yīng)用或電子郵件發(fā)送通知。使用

gprecoverseg

工具與時恢復(fù)故障段，并使系統(tǒng)返回最佳平衡狀態(tài)。在主服務(wù)器上配置并運行

gpsnmpd

以發(fā)送SNMP通知給網(wǎng)絡(luò)監(jiān)控器。在

$Master_DATA_DIRECTORY/postgresql.conf

配置文件中設(shè)置郵件通知，以便檢測到關(guān)鍵問題時，Greenplum系統(tǒng)可以通過電子郵件通知管理員?？紤]雙集群配置，提供額外的冗余和查詢處理能力。除非Greenplum數(shù)據(jù)庫的數(shù)據(jù)很容易從數(shù)據(jù)源恢復(fù)，否則定期備份。如果堆表相對較小，或者兩次備份之間僅有少量AO或列存儲分區(qū)有變化，則使用增量備份。如果備份保存在集群的本地存儲系統(tǒng)上，則備份結(jié)束后，將文件移到其他的安全存儲系統(tǒng)上。如果備份保存到NFS中，則建議使用像EMCIsilon這樣的可擴展NFS方案以防止I/O瓶頸。Greenplum集成了對EMC的DataDomain和Symantec的NetBackup的支持，可以流式備份到DataDomain或NetBackup企業(yè)備份平臺上。詳見高可用性（后續(xù)章節(jié))第二章系統(tǒng)配置本節(jié)描述了Greenplum數(shù)據(jù)庫集群關(guān)于主機配置的需求和最佳實踐。?

首選操作系統(tǒng)紅帽企業(yè)級Linux（RHEL）是首選操作系統(tǒng)。應(yīng)使用最新支持的主版本，目前是RHEL6。?

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

端口配置ip_local_port_range

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

I/O配置包含數(shù)據(jù)目錄的設(shè)備的預(yù)讀大小應(yīng)設(shè)為16384./sbin/blockdev--getra/dev/sdb16384

包含數(shù)據(jù)目錄的設(shè)備的I/O調(diào)度算法設(shè)置為deadline。#cat/sys/block/sdb/queue/schedulernoopanticipatory[deadline]cfq通過/etc/security/limits.conf增大操作系統(tǒng)文件數(shù)和進程數(shù)。*softno*hardno*softnproc131072*hardnproc131072啟用core文件轉(zhuǎn)儲，并保存到已知位置。確保limits.conf中允許的core轉(zhuǎn)儲文件。kernel.core_pattern=/var/core/core.%h.%t#grepcore/etc/security/limits.conf*softcoreunlimited?

操作系統(tǒng)內(nèi)存配置Linuxsysctl的

vm.overcommit_memory

和

vm.overcommit_ratio

變量會影響操作系統(tǒng)對內(nèi)存分配的管理。這些變量應(yīng)該設(shè)置如下：vm.overcommit_memory控制操作系統(tǒng)使用什么方法確定分配給進程的內(nèi)存總數(shù)。對于Greenplum數(shù)據(jù)庫，唯一建議值是2.vm.overcommit_ratio

控制分配給應(yīng)用程序進程的內(nèi)存百分比。建議使用缺省值50.不要啟用操作系統(tǒng)的大內(nèi)存頁。詳見內(nèi)存和負(fù)載管理。（后續(xù)章節(jié))?

共享內(nèi)存設(shè)置Greenplum數(shù)據(jù)庫中同一數(shù)據(jù)庫實例的不同

postgres

進程間通訊使用共享內(nèi)存。使用

sysctl

配置如下共享內(nèi)存參數(shù)，且不建議修改：kernel.shmmax=500000000kernel.shmmni=4096kernel.shmall=4000000000?

驗證操作系統(tǒng)使用

gpcheck

驗證操作系統(tǒng)配置。參考《Greenplum數(shù)據(jù)庫工具指南》中的

gpcheck。?

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

段服務(wù)器內(nèi)存配置服務(wù)器配置參數(shù)gp_vmem_protect_limit控制了每個段數(shù)據(jù)庫為所有運行的查詢分配的內(nèi)存總量。如果查詢需要的內(nèi)存超過此值，則會失敗。使用下面公式確定合適的值：(swap+(RAM*vm.overcommit_ratio))*.9/number_of_Segments_per_server例如，具有下面配置的段服務(wù)器：8GB交換空間128GB內(nèi)存vm.overcommit_ratio=508個段數(shù)據(jù)庫則設(shè)置gp_vmem_protect_limit為8GB：(8+(128*.5))*.9/8=8GB參見

內(nèi)存和負(fù)載管理。（后續(xù)章節(jié))?

SQL語句內(nèi)存配置服務(wù)器配置參數(shù)

gp_statement_mem

控制段數(shù)據(jù)庫上單個查詢可以使用的內(nèi)存總量。如果語句需要更多內(nèi)存，則會溢出數(shù)據(jù)到磁盤。用下面公式確定合適的值：(gp_vmem_protect_limit*.9)/max_expected_concurrent_queries例如，如果并發(fā)度為40，gp_vmeme_protect_limit為8GB，則

gp_statement_mem

為：(8192MB*.9)/40=184MB每個查詢最多可以使用184MB內(nèi)存，之后將溢出到磁盤。若想安全的增大

gp_statement_mem，要么增大

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

參數(shù)，其控制了單個查詢最多可以創(chuàng)建多少個溢出文件。了解gp_work。有關(guān)使用資源隊列管理內(nèi)存的更多信息，請參考

內(nèi)存和負(fù)載管理。（后續(xù)章節(jié))?

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

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

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

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

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

存儲模型在Greenplum數(shù)據(jù)庫中，創(chuàng)建表時可以選擇不同的存儲類型。需要清楚什么時候該使用堆存儲、什么時候使用追加優(yōu)化(AO)存儲、什么時候使用行存儲、什么時候使用列存儲。對于大型事實表這尤為重要。相比而言，對小的維度表就不那么重要了。選擇合適存儲模型的常規(guī)最佳實踐為：對于大型事實分區(qū)表，評估并優(yōu)化不同分區(qū)的存儲選項。一種存儲模型可能滿足不了整個分區(qū)表的不同分區(qū)的應(yīng)用場景，例如某些分區(qū)使用行存儲而其他分區(qū)使用列存儲。使用列存儲時，段數(shù)據(jù)庫內(nèi)每一列對應(yīng)一個文件。對于有大量列的表，經(jīng)常訪問的數(shù)據(jù)使用列存儲，不常訪問的數(shù)據(jù)使用行存儲。在分區(qū)級別或者在數(shù)據(jù)存儲級別上設(shè)置存儲類型。如果集群需要更多空間，或者期望提高I/O性能，考慮使用壓縮。堆存儲和AO存儲堆存儲是默認(rèn)存儲模型，也是PostgreSQL存儲所有數(shù)據(jù)庫表的模型。如果表和分區(qū)經(jīng)常執(zhí)行UPDATE、DELETE操作或者單個INSERT操作，則使用堆存儲模型。如果需要對表和分區(qū)執(zhí)行并發(fā)UPDATE、DELETE、INSERT操作，也使用堆存儲模型。如果數(shù)據(jù)加載后很少更新，之后的插入也是以批處理方式執(zhí)行，則使用追加優(yōu)化(AO)存儲模型。千萬不要對AO表執(zhí)行單個INSERT/UPDATE/DELETE操作。并發(fā)批量INSERT操作是可以的，但是不要執(zhí)行并發(fā)批量UPDATE或者DELETE操作。AO表中執(zhí)行刪除和更新操作后行所占空間的重用效率不如堆表，所以這種存儲類型不適合頻繁更新的表。AO表主要用于分析型業(yè)務(wù)中加載后很少更新的大表。行存儲和列存儲行存儲是存儲數(shù)據(jù)庫元組的傳統(tǒng)方式。一行的所有列在磁盤上連續(xù)存儲，所以一次I/O可以從磁盤上讀取整個行。列存儲在磁盤上將同一列的值保存在一塊。每一列對應(yīng)一個單獨的文件。如果表是分區(qū)表，那么每個分區(qū)的每個列對應(yīng)一個單獨的文件。如果列存儲表有很多列，而SQL查詢只訪問其中的少量列，那么I/O開銷與行存儲表相比大大降低，因為不需要從磁盤上讀取不需要訪問的列。交易型業(yè)務(wù)中更新和插入頻繁，建議使用行存儲。如果需要同時訪問寬表的很多字段時，建議使用行存儲。如果大多數(shù)字段會出現(xiàn)在SELECT列表中或者WHERE子句中，建議使用行存儲。對于通用的混合型負(fù)載，建議使用行存儲。行存儲提供了靈活性和性能的最佳組合。列存儲是為讀操作而非寫操作優(yōu)化的一種存儲方式，不同字段存儲在磁盤上的不同位置。對于有很多字段的大型表，如果單個查詢只需訪問較少字段，那么列存儲性能優(yōu)異。列存儲的另一個好處是相同類型的數(shù)據(jù)存儲在一起比混合類型數(shù)據(jù)占用的空間少，因而列存儲表比行存儲表使用的磁盤空間小。列存儲的壓縮比也高于行存儲。數(shù)據(jù)倉庫的分析型業(yè)務(wù)中，如果SELECT訪問少量字段或者在少量字段上執(zhí)行聚合計算，則建議使用列存儲。如果只有單個字段需要頻繁更新而不修改其他字段，則建議列存儲。從一個寬列存儲表中讀完整的行比從行存儲表中讀同一行需要更多時間。特別要注意的是，GPDB每個段數(shù)據(jù)庫上每一列都是一個獨立的物理文件。?

壓縮Greenplum數(shù)據(jù)庫為AO表和分區(qū)提供多種壓縮選項。使用壓縮后，每次磁盤讀操作可以讀入更多的數(shù)據(jù)，因而可以提高I/O性能。建議在實際保存物理數(shù)據(jù)的那一層設(shè)置字段壓縮方式。請注意，新添加的分區(qū)不會自動繼承父表的壓縮方式，必須在創(chuàng)建新分區(qū)時明確指定壓縮選項。Delta和RLE的壓縮比較高。高壓縮比使用的磁盤空間較少，但是在寫入數(shù)據(jù)或者讀取數(shù)據(jù)時需要額外的時間和CPU周期進行壓縮和解壓縮。壓縮和排序聯(lián)合使用，可以達到最好的壓縮比。在壓縮文件系統(tǒng)上不要再使用數(shù)據(jù)庫壓縮。測試不同的壓縮類型和排序方法以確定最適合自己數(shù)據(jù)的壓縮方式。?

分布(DISTRIBUTIONS)選擇能夠均勻分布數(shù)據(jù)的分布鍵對Greenplum數(shù)據(jù)庫非常重要。在大規(guī)模并行處理無共享環(huán)境中，查詢的總體響應(yīng)時間取決于所有段數(shù)據(jù)庫的完成時間。集群的最快速度與最慢的那個段數(shù)據(jù)庫一樣。如果存在嚴(yán)重數(shù)據(jù)傾斜現(xiàn)象，那么數(shù)據(jù)較多的段數(shù)據(jù)庫響應(yīng)時間將更久。每個段數(shù)據(jù)庫最好有數(shù)量接近的數(shù)據(jù)，處理時間也相似。如果一個段數(shù)據(jù)庫處理的數(shù)據(jù)顯著比其他段多，那么性能會很差，并可能出現(xiàn)內(nèi)存溢出錯誤。確定分布策略時考慮以下最佳實踐：為所有表要么明確地指明其分布字段，要么使用隨機分布。不要使用默認(rèn)方式。理想情況下，使用能夠?qū)?shù)據(jù)均勻分布到所有段數(shù)據(jù)庫上的一個字段做分布鍵。不要使用常出現(xiàn)在查詢的WHERE子句中的字段做分布鍵。不要使用日期或者時間字段做分布鍵。分布字段的數(shù)據(jù)要么是唯一值要么基數(shù)很大。如果單個字段不能實現(xiàn)數(shù)據(jù)均勻分布，則考慮使用兩個字段做分布鍵。作為分布鍵的字段最好不要超過兩個。GPDB使用哈希進行數(shù)據(jù)分布，使用更多的字段通常不能得到更均勻的分布，反而耗費更多的時間計算哈希值。如果兩個字段也不能實現(xiàn)數(shù)據(jù)的均勻分布，則考慮使用隨機分布。大多數(shù)情況下，如果分布鍵字段超過兩個，那么執(zhí)行表關(guān)聯(lián)時通常需要節(jié)點間的數(shù)據(jù)移動操作（Motion），如此一來和隨機分布相比，沒有明顯優(yōu)勢。Greenplum數(shù)據(jù)庫的隨機分布不是輪詢算法，不能保證每個節(jié)點的記錄數(shù)相同，但是通常差別會小于10%。關(guān)聯(lián)大表時最優(yōu)分布至關(guān)重要。關(guān)聯(lián)操作需要匹配的記錄必須位于同一段數(shù)據(jù)庫上。如果分布鍵和關(guān)聯(lián)字段不同，則數(shù)據(jù)需要動態(tài)重分發(fā)。某些情況下，廣播移動操作（Motion）比重分布移動操作效果好。本地（Co-located）關(guān)聯(lián)如果所用的哈希分布能均勻分布數(shù)據(jù)，并導(dǎo)致本地關(guān)聯(lián)，那么性能會大幅提升。本地關(guān)聯(lián)在段數(shù)據(jù)庫內(nèi)部執(zhí)行，和其他段數(shù)據(jù)庫沒有關(guān)系，避免了網(wǎng)絡(luò)通訊開銷，避免或者降低了廣播移動操作和重分布移動操作。為經(jīng)常關(guān)聯(lián)的大表使用相同的字段做分布鍵可實現(xiàn)本地關(guān)聯(lián)。本地關(guān)聯(lián)需要關(guān)聯(lián)的雙方使用相同的字段（且順序相同）做分布鍵，并且關(guān)聯(lián)時所有的字段都被使用。分布鍵數(shù)據(jù)類型必須相同。如果數(shù)據(jù)類型不同，磁盤上的存儲方式可能不同，那么即使值看起來相同，哈希值也可能不一樣。數(shù)據(jù)傾斜數(shù)據(jù)傾斜是很多性能問題和內(nèi)存溢出問題的根本原因。數(shù)據(jù)傾斜不僅影響掃描/讀性能，也會影響很多其他查詢執(zhí)行操作符，例如關(guān)聯(lián)操作、分組操作等。數(shù)據(jù)初始加載后，驗證并保證數(shù)據(jù)分布的均勻性非常重要；每次增量加載后，都要驗證并保證數(shù)據(jù)分布的均勻性。下面的查詢語句統(tǒng)計每個段數(shù)據(jù)庫上的記錄的條數(shù)，并根據(jù)最大和最小行數(shù)計算方差：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

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

字段表示變異系數(shù)，通過標(biāo)準(zhǔn)偏差除以均值計算而來。它同時考慮了數(shù)據(jù)的均值和可變性。這個值越小越好，值越高表示數(shù)據(jù)傾斜越嚴(yán)重。視圖gp_toolkit.gp_skew_idle_fractions

通過計算表掃描時系統(tǒng)空閑的百分比顯示數(shù)據(jù)分布傾斜情況，這是表示計算傾斜情況的一個指標(biāo)。siffraction

字段顯示了表掃描時處于空閑狀態(tài)的系統(tǒng)的百分比。這是數(shù)據(jù)不均勻分布或者查詢處理傾斜的一個指標(biāo)。例如，0.1表示10%傾斜，0.5表示50%傾斜，以此類推。如果傾斜超過10%，則需對其分布策略進行評估。計算傾斜（ProceddingSkew）當(dāng)不均衡的數(shù)據(jù)流向并被某個或者少數(shù)幾個段數(shù)據(jù)庫處理時將出現(xiàn)計算傾斜。這常常是Greenplum數(shù)據(jù)庫性能和穩(wěn)定性問題的罪魁禍?zhǔn)?。關(guān)聯(lián)、排序、聚合和各種OLAP操作中易發(fā)生計算傾斜。計算傾斜發(fā)生在查詢執(zhí)行時，不如數(shù)據(jù)傾斜那么容易檢測，通常是由于選擇了不當(dāng)?shù)姆植兼I造成數(shù)據(jù)分布不均勻而引起的。數(shù)據(jù)傾斜體現(xiàn)在表級別，所以容易檢測，并通過選擇更好的分布鍵避免。如果單個段數(shù)據(jù)庫失?。ú皇悄硞€節(jié)點上的所有段實例），那么可能是計算傾斜造成的。識別計算傾斜目前主要靠手動。首先查看臨時溢出文件，如果有計算傾斜，但是沒有造成臨時溢出文件，則不會影響性能。下面是檢查的步驟和所用的命令：1.找到懷疑發(fā)生計算傾斜的數(shù)據(jù)庫的OID：SELECToid,datnameFROMpg_database;例子輸出:oid|datname+17088|gpadmin10899|postgres1|template110898|template038817|pws39682|gpperfmon(6rows)2.使用gpssh檢查所有Segments上的溢出文件大小。使用上面結(jié)果中的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)如果不同段數(shù)據(jù)庫的磁盤使用量持續(xù)差別巨大，那么需要一進步查看當(dāng)前執(zhí)行的查詢是否發(fā)生了計算傾斜（上面的例子可能不太恰當(dāng)，因為沒有顯示出明顯的傾斜）。在很多監(jiān)控系統(tǒng)中，總是會發(fā)生某種程度的傾斜，如果僅是臨時性的，則不必深究。3.如果發(fā)生了嚴(yán)重的持久性傾斜，接下來的任務(wù)是找到有問題的查詢。上一步命令計算的是整個節(jié)點的磁盤使用量?，F(xiàn)在我們要找到對應(yīng)的段數(shù)據(jù)庫(Segment)目錄?？梢詮闹鞴?jié)點（Master）上，也可以登錄到上一步識別出的Segment上做本操作。下面例子演示從Master執(zhí)行操作。本例找的是排序生成的臨時文件。然而并不是所有情況都是由排序引起的，需要具體問題具體分析：[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從結(jié)果可以發(fā)現(xiàn)主機sdw8上的Segmentgpseg45是罪魁禍?zhǔn)住?.使用SSH登錄到有問題的節(jié)點，并切換為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對應(yīng)的數(shù)據(jù)庫和連接信息。[root@sdw8

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

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

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

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

gp_vmem_protect_limit

設(shè)置段數(shù)據(jù)庫(Segment)能為所有任務(wù)分配的最大內(nèi)存。切勿設(shè)置此值超過系統(tǒng)物理內(nèi)存。如果

gp_vmem_protect_limit

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

gp_vmem_protect_limit

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

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

statement_mem

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

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

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

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

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

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

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