Greenplum企業應用實戰（筆記）：第八章 Greenplum 線上環境部署
第八章 Greenplum 線上環境部署
[TOC]
本章開始講解如何搭建一個高效能、安全可靠、可擴充套件、可管理的 Greenplum 叢集。
8.1 伺服器硬體選型
資料庫伺服器硬體選型應該遵循以下幾個原則：
（1）高效能原則
保證所選購的伺服器，不僅能夠滿足現有應用的需要，而且能夠滿足一定時期內業務量增長的需要。對於資料庫而言，資料庫效能依賴於硬體的效能和各種硬體資源的均衡，CPU、記憶體、磁碟、網路這幾個關鍵元件在系統中都很關鍵，如果過分突出某一方面硬體資源則會造成大量的資源浪費，而任何一個硬體效能差都會成為系統的瓶頸，故在硬體選擇的時候，需要根據應用需求在預算中做到平衡。
（2）可靠性原則
不僅要考慮伺服器單個節點的可靠性或穩定性，而且要考慮伺服器與相關輔助系統之間連線的整體可靠性。
（3）可擴充套件性原則
需要伺服器能夠在相應時間根據業務發展的需要對其自身進行相應的升級，如 CPU 型號升級、記憶體擴大、硬碟擴大、更換網絡卡等。
（4）可管理型原則
需要伺服器的軟硬體對標準的管理系統提供支援。
8.1.1 CPU
CPU 選擇主要考慮以下兩個方面：
- Interl 還是 AMD
- 更快的處理器還是更多的處理器
Intel 作為單核運算速度方面的領導者，其 CPU 及相關元件相對較貴，而 AMD 在多核處理技術方面表現優異，仍不失為一個較好的選擇。
如果僅有較少程序執行在單個處理器上，則可以考慮配置更快的 CPU。相反，如果大量併發程序執行在所有處理器上，則考慮配備更多的核。
一臺伺服器上 CPU 的數量決定部署到機器上的 gp 資料庫 Segment 例項的數量，比如一個 CPU 配置一個主 Segment。
8.1.2 記憶體
記憶體是計算機中重要的部件之一，它是與 CPU 進行溝通的橋樑。計算機中所有程式執行都是在記憶體中進行的，因此記憶體的效能對計算機的影響非常大。記憶體的選擇總體上來說是越大越好。
對於處理像資料庫這樣的海量資料，並且記憶體遠小於資料儲存的情況，如歌記憶體已經夠用，通過增加記憶體來獲取效能的提升則非常細微。 對於 gp ，磁碟的吞吐量決定 gp 的效能，磁碟吞吐量越高效能越好 。
8.1.3 磁碟及硬碟介面
硬碟分為固態硬碟（SSD）和機械硬碟（HDD），SSD 採用快閃記憶體顆粒來儲存，HDD 採用磁性碟片來儲存。
硬碟介面主要有如下幾類：
（1）ATA（Advanced Technology Attachment）
是用傳統的 40-pin 並口資料線連線主機板與硬碟的。外部介面速度最大為 133MB/s。因為並口線的抗干擾性太差，且排線佔空間，不利計算機散熱，將逐漸被 SATA 所取代。
（2）IDE（Integrated Drive Electonices）
即電子整合驅動器，是把“硬碟控制器”與“盤體”整合在一起的硬碟驅動器。
（3）SCSI 小型計算機系統介面
同 IDE 和 ATA 完全不同的介面，IDE 介面是普通 PC的標準介面，而 SCSI 並不是專門為硬碟設計的介面，是一種廣泛應用於小型機上的高速資料上傳輸技術。 SCSI 介面具有應用範圍廣、任務多、頻寬大、CPU 佔用率低，以及熱插拔等優點，但較高的價格
（4）SATA（Serial Advanced Technology Attachment）
序列高階技術附件，一種基於行業標準的序列硬體驅動器介面，是由Intel、IBM、Dell、APT、Maxtor 和 Seagate 公司共同提出的硬碟介面規範。
（5）SAS（Serial Attached SCSI，序列連線SCSI）
是新一代的 SCSI 技術。同 SATA 都採用序列技術以獲得更高的傳輸速度，並通過縮短連線線改善內部空間等。
（6）SSD（Solid State Disk）
即固態硬碟。
表8-1
在選擇硬碟和硬碟控制器時，確認選擇的硬碟控制器能夠包括硬碟頻寬之和。假如有20個 70Mb/s 內部頻寬的硬碟，為了獲得硬碟最佳效能，需要最少支援 1.4Gb/s 的硬碟控制器。
要提升伺服器 I/O 吞吐量、可用性及儲存容量，常見的方法是做 RAID，即獨立冗餘磁碟陣列（Redundant Array of Independent Disk，RAID）。
幾種常見的 RAID 技術如下：
（1）RAID 0
從嚴格意義上說，RAID 0 不是 RAID，因為它沒有資料冗餘和校驗。 RAID0 技術只是實現了條帶化，具有很高的資料傳輸率，最高的儲存利用率，但是 RAID中硬碟數越多，安全性越低。
（2）RAID 1
通常稱為 RAID 映象。RAID 1 主要是通過資料映象實現資料冗餘，在兩對分離的磁碟上產生互為備份的資料，因此 RAID 1 具有很高的安全性。但是 RAID空間利用率低，磁碟控制器負載大，因此只有當系統需要極高的可靠性時，才選擇 RAID 1 。
（3）RAID 1+0
RAID 0+1 至少需要 4 塊硬碟才可以實現，不過它綜合 RAID 0 和 RAID 1 的特點，獨立磁碟配置成 RAID 0，兩套完整的 RAID 0 互相映象。 它的讀寫效能出色，安全性也較高。但是構建 RAID 0+1 陣列的成本投入大，資料空間利用率只有 50%，因此還不能稱為經濟高效的方案 。
（4）RAID 5
RAID 5 是目前應用最廣泛的 RAID 技術。各塊獨立硬碟進行條帶化分隔，相同的條帶區進行奇偶校驗（異或運算），校驗資料平均分佈在每塊硬碟上。 RAID 5 具有資料安全、讀寫速度快、空間利用率高等優點，應用非常廣泛。但是不足之處是，如果1塊硬碟出現故障，整個系統的效能將大大降低。
8.1.4 網路
gp 資料庫互聯的效能與 Segment 上網絡卡的網路負載有關，所以 gp 伺服器一般由一組多個網絡卡的硬體組成。為了達到最好效能，gp 建議為 Segment 機器上的每一個機器上的每一個主 Segment 配置一個千兆網絡卡，或者配置每臺機器都有萬兆網絡卡。
如果 gp 資料庫網路叢集中有多個網路交換機，那麼交換機之間均衡地分配子網較為理想，比如每個機器上的網絡卡1和2用其中一個交換機，網絡卡3和4使用另一個交換機。
8.2 伺服器系統引數調整
對於不同的應用場景，每一種硬體都有不同的引數配置，通過引數調整，可以極大地提高讀寫效能。對於 OLTP 資料庫而言，關注的是磁碟的隨機讀寫，提高單次讀寫的效能；而對於 OLAP 資料庫而言，最關注的是磁碟的順序讀寫，重點在於提高每次磁碟讀寫的吞吐量。
GP 目前支援的作業系統有以下幾種：
- SUSE Linux SLES 10.2 or higher
- CentOS 5.0 or higher
- RedHat Enterprise Linux 5.0 or higher
- Oracle Unbreakable Linux 5.5
- Solaris x86 v10 update 7
一般情況下，需要在作業系統中修改以下三種類型的引數：
（1）共享記憶體
gp 只有在作業系統中記憶體大小配置適當的時候才能正常工作。大部分作業系統的共享記憶體設定太小，不適合 gp 的場景，因為這樣可以避免程序因為記憶體佔用過高被作業系統停止。
（2）網路
gp 的資料分佈在各個節點上，因此在計算過程中經常需要將資料移動到其他節點上進行計算，這是，合理的網路配置就顯得格外的重要。
（3）系統對使用者的限制
作業系統在預設情況下會對使用者進行一下資源的限制，以避免某個使用者佔用太多資源導致其他使用者資源不可用。對於資料庫來說，只會有一個作業系統使用者，這些限制都必須取消掉，例如 gp 會同時開啟很多檔案控制代碼，而作業系統預設的檔案控制代碼一般很小。
8.2.1 Solaris 引數修改
8.2.2 Linux 引數修改
在 Linux，對應共享記憶體，網路、使用者限制的引數修改如下。
- /etc/sysctl.conf，修改共享記憶體及網路 ipv4 的配置：
kernel.sem = 250 64000 100 512 kernel.shmmax = 5000000000 kernel.shmmni = 4096 kernel.shmall = 4000000000 kernel.sem = 250 64000 100 512 kernel.sysrq = 1 kernel.core_uses_pid = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 net.ipv4.tcp_syncookies = 1 net.ipv4.ip_forward = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_max_syn_backlog=4096 net.ipv4.conf.all.arp_filter = 1 net.ipv4.conf.default.arp_filter = 1 nete.core.net.netdev_max_backlog=10000 vm.overcommit_memory=2
- 修改檔案數，程序數的限制
* soft nofile 65536 * hard nofile 65536 * soft nproc 131072 * hard nproc 131072
8.2.3 系統引數及效能驗證
gp 中提供了 gpcheck 指令碼對系統引數進行校驗，確保配置合理，同時還提高了 gpcheckperf 對機器進行效能測試，包括網路效能測試、磁碟 I/O 吞吐測試、記憶體頻寬測試等。
（1）使用 gpcheck 指令碼對系統引數進行驗證，命令如下：
[root@test /] # gpcheck -h dw-greenplum-l
gpcheck
這個指令碼會配置一些需要校驗的引數，在 $GPHOME/etc/gpcheck.cnf 檔案中，如如果引數配置與 gpcheck.cnf 中的不一致，則會報出一條 ERROR。例如在上面這個例子中，錯誤顯示在 /etc/project 中沒有誒之相應的引數。
（2）網路測試
利用 gp 自帶的 gpcheckperf 工具可以很方便地測試各節點間網路連通情況。
網路測試的機器名列表如下（host.1 檔案中）
host.1
執行 gpcheckperf 進行測試：
[gpadmin@dw-greenplum-3 /export/home/gpadmin]# gpcheckperf -d /storagepool/upload -r N -f host.1 /opt/greenplum/greenplum-db-4.1.1.1/bin/gpcheckperf -d /storagepool/upload -r N -f host.1
gpcheckperf
（3）檔案系統性能驗證
利用 gp 自帶的 gpcheckperf 工具可以很方便地測試檔案系統的讀寫效能，示例程式碼如下：
[gpadmin@greenplum-3 /export/home/gpadmin]# gpcheckperf -d /storagepool/gptempp1 -d /storagepool/gptempp2 -d /storagepool/gptempp3 -d /storagepool/gptempp4 -d /storagepool/gptempm1 -d /storagepool/gptempm2 -d /storagepool/gptempm3 -d /storagepool/gptempm4 -r ds -D -f host.1 /opt/greenplum/greenplum-db-4.1.1.1/bin/gpcheckperf -d /storagepool/gptempp1 -d /storagepool/gptempp2 -d /storagepool/gptempp3 -d /storagepool/gptempp4 -d /storagepool/gptempm1 -d /storagepool/gptempm2 -d /storagepool/gptempm3 -d /storagepool/gptempm4 -r ds -D -f host.1
8.3 計算節點分配技巧
如果配置了 mirror 節點，其會分佈在所有 Segment 節點上，在預設情況下同一伺服器上主節點對應的所有備節點會分配在一臺伺服器上（這種方式稱為 Grouped Mirror），這樣一旦某一臺計算節點宕機，所有備節點會在同一臺伺服器上，致使效能降低 50%，且不利於資料恢復。在初始化資料庫時，可以指定 -S 引數，將同一伺服器上主節點對應的備節點打散至叢集不同伺服器上（這種方式稱為 Spread Mirror）
8.4 資料庫引數介紹
資料庫優化主要從兩個方面著手：
- 提升 CPU、記憶體、磁碟、網路等叢集伺服器的硬體配置
- 優化提交到資料庫的語句
簡單介紹一下影響資料庫效能的引數及其他常用的配置引數：
（1）shared_buffers
資料距離 CPU 越近效率就越高，而離 CPU 由近到遠的主要裝置有暫存器、CPU cache、RAM、Disk Drives 等。CPU 的暫存器和 cache 是沒辦法直接優化的。為了避免磁碟訪問，只能儘可能將更多有用資訊存放在 RAM 中。gp 資料庫的 RAM 主要用於存放如下資訊：
- 執行程式
- 程式資料和堆疊
- postgreSQL shared buffer cache
- kernel disk buffer cache
- kernel
因此最大化地保持資料庫資訊在記憶體中而不影響其他區域才是最佳的調優方式。
pgsql 並非直接在磁碟上進行資料修改，而是將資料讀入 shared buffercache，進而 pgsql 後臺程序修改 cache 中的資料塊，最終再寫回磁碟。後臺程序如果在 cache 中找到相關資料，則直接進行操作，如果沒找到，則需要從 kernel disk buffer cache 或者磁碟中讀入。pgsql 預設的 shared buffer 較小，將此 cache 調大則可降低昂貴的磁碟訪問。但前面提到，修改此引數時一定要避免 swap 發生，因為記憶體不僅僅用於 shared buffer cache。剛開始可以設定一個較小的值，比如總記憶體的15%，然後逐漸增加，過程中監控效能提升和swap 的情況。
（2）effective_cache_size
設定優化器假設磁碟快取記憶體的大小用於查詢語句的執行計劃判斷，主要用於判斷使用索引的成本，此引數越大越有機會選擇索引掃描，越小越傾向於選擇順序掃描，此引數只會影響執行計劃的選擇。
（3）work_mem
當 pgsql 對大表進行排序時，資料庫會按照此引數指定大小進行分片排序，將中間結果存放在臨時檔案中，這些中間結果的臨時檔案最終會再次合併排序，所以增加此引數可以減少臨時檔案個數進而提升排序效率。如果設定過大，會導致 swap 的發生，所以設定此引數是仍然需要謹慎。同樣剛開始仍可設定為總記憶體的5%。
（4）temp_buffers
temp_buffers 即臨時緩衝區，用於資料庫訪問臨時表資料，gp 預設值為 1M。可以在單獨的 session 中對該引數進行設定，在訪問比較大的臨時表時，對效能提升有很大幫助。
（5）client_encoding
設定客戶端字符集，預設和資料庫 encoding 相同
（6）client_min_messages
控制傳送至客戶端的資訊級別，每個級別包括更低級別的訊息，越是低的訊息級別傳送至客戶端的資訊越少。此引數主要用於錯誤除錯。
（7）cpu_index_tuple_cost
設定執行計劃評估每一個索引行掃描的 CPU 成本。同類引數還包括 cpu_operator_cost、cpu_tuple_cost、cursor_tuple_fraction。
（8）debug_assertions
開啟各種斷言檢查，這是除錯助手。如果遇到了奇怪的問題或資料庫崩潰，那麼可以將這個引數開啟，便於分析錯誤原因。
（9）debug_print_parse
當需要檢視查詢語句是分析樹時，可以設定開啟此引數，預設off
（10）debug_print_plan
當需要檢視查詢語句的執行計劃時，可以設定開啟此引數，預設為 off。同類引數包括 debug_print_prelim_plan、debug_print_rewritten、debug_print_slice_table。
（11）default_tablespace
指定建立物件時的預設表空間
（12）dynamic_library_path
在建立函式或者載入命令時，如果未指定目錄，將會從這個路徑搜尋需要的檔案。
（13）enable_bitmapscan
表示是否允許點陣圖索引掃描，類似的引數還有 enable_groupagg、enable_hashagg、enable_hashjoin、enable_indexscan、enable_mergejoin、enable_nestloop、enable_seqscan、enable_sort、enable_tidscan。這些引數主要用於控制執行計劃。
（14）gp_autostats_mode
指定觸發自動蒐集統計資訊的條件。當此值為 on_no_stats 時，create table as select 會自動蒐集統計資訊，如果 insert 和 copy 操作的表沒有統計資訊，也會自動觸發統計資訊蒐集。當此值為 on_change 時，如果變化量超過 gp_autostats_on_threshold 引數設定的值，會自動觸發統計資訊蒐集。此引數還可設為 none 值，即不自動觸發統計資訊蒐集。
（15）gp_enable_gpperfmon
要使用 Greenplum Performance Monitor 工具，必須開啟此引數。
（16）gp_enable_max_segs
設定外部表資料掃描可用 Segment 數目
（17）gp_fts_probe_interval
設定 ftsprobe 程序對 Segment failure 檢查的間隔時間
（18）gp_fts_probe_threadcount
設定 ftsprobe 執行緒數，此引數建議大於等於每臺伺服器 Segments 的數目
（19）gp_fts_probe_timeout
設定 ftsprobe 程序用於標識 Segment down 的連線 Segment 的超時時間。
（20）gp_hashjoin_tuples_per_bucket
此引數越小，hash tables 越大，可提升 join 效能，相關引數還有 gp_interconnect_hash_multiplier、gp_interconnect_hash_multiplier、gp_interconnect_depth。
（21）gp_interconnect_setup_timeout
此引數在負載較大的叢集中，應該設定較大的值。
（22）gp_interconnect_type
可選值為 TCP、UDP，用於設定連線協議。TCP 最大隻允許 1000 個節點例項。
（23）gp_log_format
設定伺服器日誌檔案格式。可選值為 csv 和 text。
（24）gp_max_database
設定伺服器允許的最大資料庫數，相關引數還有gp_max_filespaces、gp_max_packet_size、gp_maxa_tablespaces
（25）gp_resqueue_memory_policy
此引數允許 none 和 auto 這兩個值，當設定 none 時，gp 4.1 版本以前的策略一致；設定 auto 時，查詢記憶體使用受 statement_mem 和資源佇列的記憶體限制，而 work_mem、max_work_mem 和 maintenance_work_mem 這三個引數將失效。
（26）gp_resqueue_priority_cpucores_per_segment
指定每個 Segment 可用的 CPU 單元
（27）gp_segment_connect_timeout
設定網路連線超時時間
（28）gp_set_proc_affinity
設定程序是否繫結到 CPU
（29）gp_set_read_only
設定資料庫是否允許寫
（30）gp_vmem_idle_resource_timeout
設定資料庫會話超時時間，超過此引數值會話將釋放系統資源。此引數越小，叢集併發度支援越高
（31）gp_vmem_protect_limit
設定伺服器中 postgres 程序可用的總記憶體，建議設定為 (X * physical_memory ) / primary_segments，其中 X 可設定為 1.0 和 1.5 之間的數字，當 X=1.5 時容易引發 swap，但是會減少因記憶體不足而失敗的查詢數。
（32）log_min_duration_statement
當查詢語句執行時間超過此值時，將會記錄日誌，相關引數參考 log_開頭的所有引數。
（33）maintenance_work_mem
設定用於維護的操作可用的記憶體數，比如 vacuum、create index 等操作將受到這個引數的影響。
（34）max_appendonly_tables
最大可併發處理的 appendonly 表的數目
（35）max_connections
最大連線數，Segment 建議設定 Master 的5-10倍。
（36）max_statement_mem
設定單個查詢語句的最大記憶體限制，相關引數是 max_work_mem
（37）random_page_cost
設定隨機掃描的執行計劃評估成本，此值越大越傾向於選擇順序掃描，越小越傾向於選擇索引掃描
（38）search_path
設定未指定 schema 時，按照這個順序選擇物件的 schema
（39）statement_timeout
設定語句終止執行的超時時間，0表示永不終止
8.5 資料庫叢集基準測試
在叢集搭建完成正式應用上線之前，對叢集整體效能做一個基準測試是很有必要的，比如驗證資料庫引數設定是否恰當、叢集穩定性如何等。
TPC-H（商業智慧計算測試），主要用於 ad-hoc、決策支援等系統的基準測試。
（1）TPC_H 下載即安裝
ofollow,noindex">http://www.tpc.org/tpch/default.asp 下載 tpch-queries.tgz 包，解壓後準備 Makefile 檔案（可以將資料夾中的 makefile.suite 作為模板），Makefile 檔案的第 109 行左右有項要適當的修改，如 CC=gcc、DATABASE=TDAT、MACHINE=LINUX、WORKLOAD=TPCH，修改完成之後，執行 make 命令進行編譯即可
（2）測試資料生成
（以下略）
（3）測試表建立
（4）測試資料匯入
（5）測試指令碼準備
（6）執行基準測試指令碼