Sybase 15.3橫向擴展查詢性能使用PlexQ分布式查詢平臺、全共享的MPP架構(gòu)（三）

（上接第9期）

4.1 DQP的可擴展性

一個查詢可能只有全面并行化并充分利用單個節(jié)點的CPU資源，才能從DQP獲益。另外，

Sybase IQ主存儲和共享臨時存儲必須不能受到I/O的限制。

DQP使用邏輯服務(wù)器上所有節(jié)點的可用的內(nèi)存和CPU資源。一般來講，可用的節(jié)點和資源越多，查詢性能越高?；谌蝿?wù)單元的數(shù)量，存在一個上限。如果沒有足夠的任務(wù)單元傳送到Mul t iplex中所有可用的CPU上，則只有一部分CPU被使用。邏輯服務(wù)器中節(jié)點的當前工作負載顯然將影響性能。

分配更多的內(nèi)存到臨時緩存將使基于哈希的算法更可能擴展。一個大的臨時緩存比一個大的主緩沖對DQP更重要。共享臨時存儲的I/O帶寬—用于分配任務(wù)和傳遞即時結(jié)果—對分布式查詢的性能非常關(guān)鍵，因此如果你的存儲層提供了分層性能特性，將IQ_SHARED_TEMP置于快速的存儲將產(chǎn)生更好的結(jié)果。

這看起來似乎顯而易見，但是所有的分布式碎片必須在最終的結(jié)果集被生成以及返回給請求的應(yīng)用之前全部處理完畢。因此，應(yīng)該注意“最慢的碎片執(zhí)行”將限制查詢的整體性能。另外，盡管查詢在Sybase IQ 15.3的DQP層之內(nèi)自動進行分布和負載均衡，但是將負載均衡跨Mul t iplex連接以將更多密集型的Leader節(jié)點任務(wù)分散到Mul t iplex中的所有節(jié)點上，這仍是一個好主意。

4.2 最有可能從DQP獲益的查詢

DQP用于報表高度密集的Mul t iplex環(huán)境。加載性能不受DQP選項的影響，盡管加載可通過配置多個Mul t iplex寫節(jié)點而并行化。同時，當內(nèi)存和CPU在Mul t iplex間被平衡時，DQP將獲得更好的執(zhí)行。

某些類型的查詢將比其他查詢更具擴展性。更可能被很好分布的查詢具有以下屬性：

（1）計算密集型的列掃描，比如LIKE條件。

（2）包含匯總、繁多的表達、數(shù)值型數(shù)據(jù)類型的復(fù)雜查詢。

（3）由可減小中間和最終結(jié)果的查詢碎片組成的查詢。一個例子就是，一系列在頂部帶有“group by hash”的hash joins。

（4）經(jīng)常使用基于哈希處理的低基數(shù)數(shù)據(jù)，更可能擴展。這常常出現(xiàn)在星型模型中，其特征是一個大的事實表和一些擁有低基數(shù)維度的表。

（5）如果你有中等基數(shù)的表，你可以對數(shù)據(jù)庫選項進行調(diào)優(yōu)，分配更多的內(nèi)存到臨時緩沖，偏置查詢優(yōu)化器去選擇更多基于哈希的算法。

4.3 通常有可能從DQP獲益的查詢

正如前面所述，有些類型的查詢天然的不能被很好擴展，查詢優(yōu)化器也決定不對這些查詢進行分布，因為它們在單個節(jié)點上可能執(zhí)行得更好。這些類型的查詢具有的特征包括：

（1）返回大量行的查詢，因此返回行占用了查詢執(zhí)行時間的大部分。注意，從一個查詢的“頂部”生成行是一個系列操作，不能被分布。

（2）小查詢：用時不超過2 s的查詢不可能從DQP中獲益。2 s～10 s的查詢也不太可能獲益。超過10秒的查詢更可能從中獲益。

（3）有大量碎片的查詢。如果有大量碎片，這通常意味著包含排序。這可能導致無法擴展，因為對大量數(shù)據(jù)排序，要使用IQ_SHARED_TEMP DBSpace中的磁盤存儲執(zhí)行這個排序。這也是為什么共享臨時DBSpace應(yīng)該盡可能被放置到快速的存儲上的原因。

（4）join高基數(shù)、大表，將導致合并joins。這不能像hash joins一樣擴展。

4.4 你可以做什么影響DQP的可擴展性

有多種服務(wù)器和數(shù)據(jù)操作可影響查詢的并行化和性能。

（1）Max_Query_Paral lel ism：這個數(shù)據(jù)庫選項設(shè)定了一個上限，限制了優(yōu)化器將如何允許查詢操作并行，比如Joins，Group By以及Order By。缺省的值是64。有超過64顆CPU核的系統(tǒng)通?？梢詮母蟮闹抵蝎@益—直到系統(tǒng)中的全部CPU數(shù)，最大值為512。

（2） Minimize_Storage：在向表中加載數(shù)據(jù)前設(shè)置該數(shù)據(jù)庫選項為“o n”，或者在列定義上使用IQ_UNIQUE。使用了參照表的FP（1），F(xiàn)P（2），F(xiàn)P（3）索引將代替f lat FP 索引而被創(chuàng)建。這占用更少的空間并減少I/O（盡管FP(3)索引消耗大量內(nèi)存，因此應(yīng)審慎的使用它們）。

（3） Force_No_Scrol l_Cursors：如果你不需要向后回滾游標，將該數(shù)據(jù)庫選項設(shè)置為“on”以減少臨時存儲需求。

（4）Max_IQ_Threads_Per_Connect ion：控制每個連接的線程數(shù)。對大的系統(tǒng)，你會發(fā)現(xiàn)通過提高該值所帶來的性能優(yōu)勢。

（5）Max_IQ_Threads_Per_Team：控制分配給單個操作（比如一個列上的LIKE謂詞）執(zhí)行的線程數(shù)。對于大的系統(tǒng)，你會發(fā)現(xiàn)通過提高該值所帶來的性能優(yōu)勢。

（6）Max_Hash_Rows：將該數(shù)據(jù)庫選項設(shè)置為主機上的每4 GB RAM 250萬。例如，在一個64 GB的系統(tǒng)上設(shè)置為4 000萬。 這會鼓勵查詢優(yōu)化器使用更好擴展的基于哈希的join和group by算法。然而，在此有個警告：對于超大的哈希表，分布可能會帶來性能的倒退，由于將哈希表從一個節(jié)點取出并在另一個節(jié)點重組它們所需的時間。DQP將試圖彌補這種情況，當哈希表變得非常大時，即使內(nèi)存可以滿足，也不去分布基于哈希的操作。

（7）-iqgovern：這個服務(wù)器選項設(shè)定了一個特定服務(wù)器上并發(fā)查詢的量。通過設(shè)定-iqgovern開關(guān)，你可以幫助IQ維持吞吐量，給查詢充足的資源快速完成。缺省的值是2倍的CPU數(shù)+10。對于有大量活動連接的點，你可能需要將這個值設(shè)得更低。

（8）-iqtc：這個數(shù)據(jù)庫選項設(shè)置臨時緩沖大小。臨時緩沖既被本地臨時存儲也被共享臨時存儲使用。DQP必須利用IQ_SHARED_TEMP來執(zhí)行處理，因此要求充足的臨時緩沖。你可能需要分配比DQP負載主緩沖更多的內(nèi)存給它。

（9）同時，有兩個特別為DQP提供的數(shù)據(jù)庫選項：

a.MPX_Work_Uni t_Timeout：當一個Worker節(jié)點無法在mpx_work_uni t_t imeout時間內(nèi)完成查詢碎片的處理，該任務(wù)將返回到Leader節(jié)點重試。如果你發(fā)現(xiàn)t imeout出現(xiàn)并對DQP 的性能產(chǎn)生負面影響，你可以增大t imeout的值允許Worker完成任務(wù)。盡管一般而言，你不可能遇到t imeout問題，除非你有一些其他的底層問題。

b.DQP_Enabled：這是一個讓你為數(shù)據(jù)庫連接設(shè)置的選項。如果DQP出現(xiàn)，但是你沒有看到它帶來的好處，你可以關(guān)掉它。

4.5 設(shè)置共享臨時存儲的大小

一個位于高速存儲硬件上的充足的共享臨時空間對分布式查詢的性能至關(guān)重要。盡管很難提前計算分布式查詢需要多大的共享臨時存儲，但是也有一些已經(jīng)被發(fā)現(xiàn)的趨勢：

（1）當一個分布式查詢被執(zhí)行的時候，共享臨時空間的使用在Mul t iplex中的節(jié)點間變化很大。

（2）共享臨時空間的使用并不與查詢的可擴展性相關(guān)。那些不能很好擴展的查詢相比于可以很好擴展的查詢，可能會使用相同或更多的共享臨時空間。

（3）那些在單個節(jié)點上使用更多臨時緩沖/空間的查詢，當運行分布式時一般也會使用更多的共享臨時空間，但是并沒有明顯的倍數(shù)關(guān)系。

（4）跨Mul t iplex使用的共享臨時空間的最大值固定不變，不管執(zhí)行一個特定的分布式查詢的節(jié)點數(shù)是多少。

（5）一個節(jié)點上所要求的共享臨時空間的大小隨著執(zhí)行同一個分布式查詢的并發(fā)用戶數(shù)而增加。換句話說，更高的工作負載要求更多的共享臨時存儲。

確保你有可用的存儲添加到共享臨時存儲，如果你發(fā)現(xiàn)它的分配不是很適合。你可以動態(tài)的添加空間，無需停止IQ 服務(wù)器。

4.6 DQP 單一的查詢負載測試結(jié)果

一個分布式查詢的性能變化顯著的依賴于這個查詢本身、以及執(zhí)行它的Sybase IQ Mul t iplex的配置和工作負載。下面的結(jié)果是到目前為止在可控制的、內(nèi)部測試環(huán)境中所取得的結(jié)果。

這些測試（由單一客戶端發(fā)起的單一的大的查詢）運行于Sybase IQ Mul t iplex之上，配置如下：

（1） Del l Blade M1000E,Power Edge Enclosure-16 X M610 Blade 服務(wù)器；56XX 處理器（224-8593）

（2） 2 x quad-core （Intel Xeon E5620 2.4 Ghz）

（3）48 GB內(nèi)存

（4）2 x 300 GB SAS Drives (Raid)

（5）Dual-Channel 8 Gbps Fibre HBA

（6）Dual-Port 10GbE Network Card

（7）2 x Fiber Swi tch-Brocade M5424 FC8 Switch+AG，24 por ts

（8）10 GB Private Network NFS Server-Del R710

（9）quad-core

（10）24 GB 內(nèi)存

（11）8x1TB Near-Line SAS Drives

（12）存儲

- 6 x PAC Storage 12-Bay 4 GB Dual Raid Control ers w/12 x 300GB 15K SAS Drives

- 6 x PAC Storage 12-Bay EBOD(Expansion Shelves)w/12 x 300 GB 15 K SAS Drives

- RAID-o striping with LUN stripe size = 64 KB

下面的每個測試都顯示了Leader 節(jié)點對特點查詢的查詢計劃，一個柱狀圖顯示了從1個到8個服務(wù)器的性能擴展。查詢的名字沒有特別的意義，僅僅是唯一的標識它。在查詢計劃中，注意“3條豎線”的注解說明了查詢處理的分布，如圖8、圖9、圖 10。

圖8 Query_A從1個到8個Mul tiplex節(jié)點擴展

圖9 —Query_B從1個到8個Mul tiplex節(jié)點擴展

5 結(jié)束語

圖10 —Query_C從1個到8個Mul tiplex節(jié)點擴展

本文已經(jīng)給了你一個關(guān)于PlexQ —Sybase IQ 15.3中新引入的一組令人激動的功能概覽，包含了旨在提供一個高性能、資源效率、以及簡化操作的平臺的分布式查詢處理。DQP的設(shè)計是為了充分利用Sybase IQ Mul t iplex的CPU資源以擴展大的、復(fù)雜的、與CPU綁定的查詢的性能。DQP可以通過分解查詢并將查詢碎片在多個Sybase IQ服務(wù)器上進行分布以并行化執(zhí)行，從而大幅提升查詢性能。這個新的功能推動了 Sybase IQ平臺邁向一個可以進一步利用分布式資源獲得更好的查詢性能和資源效率的“全共享的MPP”架構(gòu)。在今天不斷變化的、復(fù)雜的、高度競爭的世界里，快速回答時間關(guān)鍵型問題是企業(yè)成功的法寶。