2.3 Sybase IQ15中對Intra-Operator的增強

Sybase IQ 15.0版本顯著的增強了Intra-operator并行化。許多查詢操作現(xiàn)在可以使用多個線程并行執(zhí)行。

多數(shù)的表Join操作

（1）Group By操作。

（2）排序（Oder By 與 Merge Joins）。

（3）表中的謂詞執(zhí)行：例如：“WHERE last_name like “%som%”，范圍謂詞，IN條件，“Top N”操作，以及更多。

在Sybase IQ 15.3之前，一個單獨的查詢的節(jié)點間（Inter-nodes）和節(jié)點內(nèi)（Intra-Nodes）并行化僅能使用一個單一服務(wù)器上的CPU資源。當(dāng)時，Multiplex配置在擴展支持越來越多的并發(fā)用戶或者查詢上非常有效，但是對于利用跨Multiplex的所有計算帶寬而減少查詢執(zhí)行時間上無所作為。新的Sybase IQ 15.3 PlexQ分布式查詢處理功能消除了這種限制，允許一個查詢使用Sybase IQ Multiplex中所有機器上的可能的CPU資源。

現(xiàn)在，讓我們詳細(xì)探索Sybase IQ 15.3 PlexQ全共享MPP架構(gòu)中的DQP如何工作？

3 理解分布式查詢處理

3.1 什么是DQP？

分布式查詢處理（DQP）將查詢處理分散到Sybase IQ Multiplex中的多個服務(wù)器上。一個Sybase Multiplex是一組服務(wù)器，每個都運行Sybase IQ。Multiplex中的服務(wù)器連接到一個中心存儲，比如一個共享的磁盤陣列，永久共享數(shù)據(jù)。Sybase IQ Multiplex有一個混合的集群架構(gòu)，包含永久的IQ數(shù)據(jù)的共享存儲、存儲目錄元數(shù)據(jù)的獨立的節(jié)點存儲、私有的臨時數(shù)據(jù)、事務(wù)日志。

當(dāng)Sybase IQ查詢優(yōu)化器認(rèn)為一個查詢可能需要利用多個節(jié)點上更多的可用CPU資源的時候，它會將查詢分為并行的“碎片”，這些“碎片”可以在Multiplex中的其他服務(wù)器上并行執(zhí)行。DQP是這樣一個過程：將查詢分解為多個獨立的任務(wù)部分，將這些任務(wù)分布到Multiplex中的其他節(jié)點上，將結(jié)果及時的收集和組織并生成最終的查詢結(jié)果集。

需要重點強調(diào)的是，如果一個查詢不能完全利用一個單一機器上的CPU資源的話，它通常不會被分布。例如，如果優(yōu)化器將把一個查詢并行化為7條（保持7個線程），而CPU有8個核，則它不會分布這個查詢。分布要求網(wǎng)絡(luò)和存儲的開銷以分配任務(wù)，以及存儲和傳輸即時的結(jié)果。在一個DBMS內(nèi)的目標(biāo)就是盡可能快速的執(zhí)行查詢。一個簡單的查詢在單一的機器上執(zhí)行是快速的。然而，大的、復(fù)雜的查詢，超出了一個機器的CPU能力，可能更好的方式就是利用分布式并承擔(dān)因此帶來的開銷。如果性能提高了，那么分布式就是勝利。

3.2 DQP如何工作？

DQP對任何在Multiplex網(wǎng)格配置中部署了Sybase IQ 15.3的客戶都是可用的。當(dāng)你安裝了Sybase IQ，DQP缺省的是打開的，所有Multiplex中的服務(wù)器均可被分布式處理所利用。

DQP引入了“Leader”和“Worker”節(jié)點的概念。Leader節(jié)點是查詢發(fā)起的節(jié)點，Worker節(jié)點可以是Multiplex中的任何有能力接受分布式查詢處理工作的節(jié)點。所有的Multiplex節(jié)點類型(讀節(jié)點、寫節(jié)點、協(xié)調(diào)節(jié)點)都可以作為Leader或Worker節(jié)點。

圖3 一個運行中的分布式查詢

在上圖中，查詢1和查詢2的執(zhí)行被分布到Multiplex中的節(jié)點中。這兩個查詢由不同的Leader節(jié)點和一組Worker節(jié)點來完成。這是一個可能的運行場景。你可以非常靈活的配置節(jié)點集（參見：下面的“邏輯服務(wù)器”部分）參與一個分布式的查詢。

Sybase IQ 15.3 也啟用了一個新的共享DBSpace（數(shù)據(jù)庫空間）以支持DQP，叫作共享臨時存儲（Shared Temporary Store）。這個DBSpace被命名為IQ_SHARED_TEMP，必須存放于可被Multiplex中所有節(jié)點訪問和寫入的共享磁盤存儲上。這也是對IQ_SYSTEM_MAIN和用戶自定義的DBSpace的共同要求。IQ_SHARED_TEMP的目的是允許即時數(shù)據(jù)在分布式查詢所覆蓋的服務(wù)器間雙向傳遞。IQ_SHARED_TEMP與本地臨時存儲IQ_SYSTEM_TEMP都使用臨時緩沖作為數(shù)據(jù)的內(nèi)存緩沖區(qū)。

當(dāng)一個客戶端向Sybase IQ服務(wù)器提交一個查詢，查詢優(yōu)化器使用成本分析選擇是否并行化與分布查詢的執(zhí)行。一個可并行化的查詢被分解為查詢碎片—謂詞和數(shù)據(jù)流動的子樹。只有Sybase IQ引擎支持碎片中包含的所有查詢操作的并行和分布式執(zhí)行時，一個查詢才被認(rèn)為是適合分布的。

當(dāng)一個查詢被分布，Leader節(jié)點將查詢碎片分派給Worker節(jié)點，并從Worker服務(wù)器收集即時的結(jié)果。Worker服務(wù)器不決定查詢分布，他們只是簡單的執(zhí)行分派給自己的任務(wù)并返回結(jié)果。

如果一個查詢優(yōu)化器作出這樣一個決定：一個分布式查詢不適合分發(fā)，甚者可能會降低性能，那么這個查詢將不會被分布，而是會在Multiplex中的單個節(jié)點上執(zhí)行。查詢可以被分為如下幾類：

（1）不分布的：沒有碎片在Multiplex的其他節(jié)點上執(zhí)行。該查詢僅在Leader節(jié)點上完成。

（2）部分分布的：一個或多個碎片在Multiplex的其他節(jié)點上執(zhí)行，包含“Leader”節(jié)點。

（3）完全分布的：所有碎片在Multiplex的多個節(jié)點上執(zhí)行。

3.3 邏輯服務(wù)器（Logical Server）

你可能不總是希望使用Multiplex中的所有服務(wù)器執(zhí)行分布式查詢，而且可能希望用戶使用一個資源的子集。為了這個目的，Sybase IQ引入了邏輯服務(wù)器的概念。一個邏輯服務(wù)器允許一個Multiplex的一個或多個服務(wù)器組合在一起作為一個邏輯實體。用戶基于登錄政策授權(quán)訪問邏輯服務(wù)器。

有一些內(nèi)建的邏輯服務(wù)器。特別是，內(nèi)建的OPEN邏輯服務(wù)器包含所有不屬于任何用戶自定義的邏輯服務(wù)器的成員的服務(wù)器。如果你不建立任何邏輯服務(wù)器，Multiplex中的所有節(jié)點可能會參與到DQP中，因為他們都是OPEN服務(wù)器的一部分。

用戶登錄政策可能允許訪問一個或多個邏輯服務(wù)器。一個用戶將會連接到一個物理服務(wù)器上運行一個查詢。Sybase IQ查看用戶登錄政策，決定物理服務(wù)器屬于哪個邏輯服務(wù)器。然后將查詢執(zhí)行分布到邏輯服務(wù)器的那些成員節(jié)點上。盡管一個物理服務(wù)器可能屬于不止一個邏輯服務(wù)器，但是它不可能屬于分配了相同登錄政策的多個邏輯服務(wù)器。例如，一個用戶連接到邏輯服務(wù)器A和B，物理服務(wù)器C不屬于邏輯服務(wù)A,B的成員。這確保如果用戶X連接到物理服務(wù)器C，在選擇執(zhí)行查詢的邏輯服務(wù)器時不會發(fā)生歧義。你可以動態(tài)增加或減少邏輯服務(wù)器的成員服務(wù)器以適應(yīng)不斷變化的應(yīng)用的資源需求。

3.4 Multiplex節(jié)點間通訊

為了支持參與查詢分布的節(jié)點間的流線式通訊，IQ 15.3引入了Multiplex節(jié)點間通訊（MIPC）框架。MIPC網(wǎng)是一個點到點的節(jié)點間通訊基礎(chǔ)架構(gòu)，是對IQ15.0中增加的節(jié)點間通訊(INC)協(xié)議的補充。INC用于雙向的心跳監(jiān)測、版本數(shù)據(jù)同步、以及Multiplex中要求的其他類型的消息和數(shù)據(jù)的傳播。INC允許節(jié)點間通過協(xié)調(diào)節(jié)點互相對話，對當(dāng)個節(jié)點查詢的相當(dāng)有限的通訊需求來講已經(jīng)足夠。MIPC允許Multiplex節(jié)點間彼此直接對話，支持更強健的DQP的通訊需求。

MIPC既有公共的也有私有的配置選項。私有選項允許你指定主機端口配對（此時僅限于TCP/IP協(xié)議），Multiplex服務(wù)器將僅對DQP相關(guān)的通訊使用該配對。如果沒有提供私有的互聯(lián)配置，MIPC使用為其他類型通訊所設(shè)定的主機端口配對：外部用戶連接和INC連接。

在內(nèi)部測試階段，一個私有的MIPC網(wǎng)絡(luò)比一個共享的MIPC網(wǎng)絡(luò)提供了明顯的性能優(yōu)勢—在一個特定的實例中，一個分布式查詢，運行于私有MIPC網(wǎng)絡(luò)中的2個節(jié)點上，和使用共享MIPC網(wǎng)絡(luò)的3個節(jié)點配置的執(zhí)行速度一樣快。

3.5 DQP的先決條件

你無須為激活分布式查詢處理而進行任何配置。除非你通過關(guān)閉dqp_enabled登錄政策選項或dqp_enabled臨時數(shù)據(jù)庫選項禁止了DQP，DQP對合格的查詢自動啟用，當(dāng)：

（1）該服務(wù)器是Multiplex的一部分。

（2）有一個邏輯服務(wù)器允許登錄，而且至少一個節(jié)點可用。缺省的，有一個叫做OPEN邏輯服務(wù)器的內(nèi)建的邏輯服務(wù)器，所以這個需求出廠時即已滿足。

（3）共享臨時DBSpace有可寫的文件。最初，共享臨時DBSpace中沒有DBFiles，Multiplex管理員必須增加至少一個原始設(shè)備DBFile，以激活分布式查詢處理。

3.6 哪種類型的查詢可以在Multiplex中分布

一個查詢操作能被分布，首先必須能夠被并行執(zhí)行。當(dāng)一個操作并行執(zhí)行的時候，多個線程可用于并行執(zhí)行這個過程。在IQ15.3中，多數(shù)查詢操作可以被并行化，但不是所有的查詢都可以被分布。

下表顯示了哪些查詢操作可以被分布：

表1 查詢操作分布

具有如下行為的查詢碎片將不會被分布：

（1）寫入數(shù)據(jù)庫（包括 DDL，INSERT，LOAD，UPDATE和DELETE）

（2）引用臨時表。

（3）引用存于SYSTEM DBSpace中的表。

（4）引用代理表。

（5）使用不確定的函數(shù)，例如NEWID。

需要注意的是，LOAD操作仍然可以被“分布”，通過使用Multiplex中的多個節(jié)點并行加載單獨的表。

3.7 你如何知道一個查詢是否被分布？

Sybase IQ查詢計劃讓你可以看到查詢是否被分布。查詢計劃提供了詳細(xì)的信息，指出哪些服務(wù)器參與了查詢處理，評估任務(wù)如何被分布，以及顯示時間信息。

當(dāng)一個客戶端連接到一個物理服務(wù)器并啟動一個查詢的時候，DQP開始運行。這個服務(wù)器查詢的是Leader節(jié)點。該Leader節(jié)點調(diào)用查詢優(yōu)化器，建立查詢執(zhí)行計劃。查詢優(yōu)化器建立一個查詢樹，將查詢分解為碎片。一個碎片是下列其中之一：

（1）一個葉條件（一個謂詞）。

（2）一個數(shù)據(jù)流動的子樹，有特定的分區(qū)：范圍分區(qū)或關(guān)鍵詞分區(qū)碎片是查詢樹的一部分，可以被單獨執(zhí)行。當(dāng)兩個碎片可以無所謂前后順序執(zhí)行時，它們可能被并行執(zhí)行。如果一個碎片依賴于另一個碎片的即時結(jié)果，那么兩個碎片必須按照適當(dāng)?shù)捻樞驁?zhí)行。如果碎片中所有的查詢操作都是可并行化和可分布的，那么這個碎片就可以跨所有Worker節(jié)點分布。不能被分布的碎片將完全在Leader節(jié)點上執(zhí)行。這個優(yōu)化器將每個查詢操作分解為碎片，作為一組“任務(wù)單元”。一個任務(wù)單元是一組數(shù)據(jù)集，一個處理線程基于該數(shù)據(jù)集進行工作。

這是一個查詢計劃分解查詢碎片的例子。你實際上不會在現(xiàn)實的查詢計劃中看到下圖中的虛線部分。這僅僅是給你一個認(rèn)識，一個查詢可能如何被優(yōu)化器分解。在這個例子中，碎片1、2、3將會被并行執(zhí)行：

圖4 描述分布式處理碎片的查詢計劃樣板

當(dāng)你打開創(chuàng)建查詢計劃文件的數(shù)據(jù)庫選項，整個查詢的查詢計劃將在Leader節(jié)點上被創(chuàng)建。

當(dāng)一個查詢碎片是一個數(shù)據(jù)流動子樹，而且它被分布，參與執(zhí)行該碎片的每個Worker節(jié)點將為這個碎片生成一個本地的查詢計劃。（注意：你僅需在Leader節(jié)點打開查詢計劃數(shù)據(jù)庫選項，不需要為在Worker節(jié)點上創(chuàng)建查詢碎片計劃而在Worker節(jié)點上打開該選項。）一個碎片最頂端的查詢操作器管理該碎片的任務(wù)單元并將任務(wù)單元分配到跨所有Worker的線程。

任務(wù)單元的線程分配是一個高度動態(tài)的過程，允許線程在查詢執(zhí)行時增加或刪除。線程根據(jù)機器負(fù)載和資源可用性縱向或回溯擴展。臨時緩沖和CPU時間的可用性是決定增加或刪除線程的決定性因素。在Sybase IQ DQP中，物理服務(wù)器可以動態(tài)地添加到邏輯服務(wù)器上，并且在經(jīng)過一些初始化之后，一旦新的查詢碎片被安排分布即可開始執(zhí)行DQP工作。

圖5 描述分布式處理碎片的查詢計劃樣板

如果一個查詢僅有部分被分布，你將會看到在被分布的節(jié)點之間有一個三條的黑色豎線。當(dāng)你將鼠標(biāo)移動到緊鄰這個并行線的行計數(shù)上時，將會顯示遠(yuǎn)程的行數(shù)（有多少被分布）。最右端的豎線的寬度由遠(yuǎn)程行數(shù)來決定。

在查詢樹下，是時間圖表。最上端，對每一個查詢樹中的節(jié)點，你將會看到執(zhí)行的每個階段的用時?，F(xiàn)在這包括了Multiplex中所有服務(wù)器的用時。時間圖表上關(guān)于CPU使用的部分將顯示所有服務(wù)器的匯總用時。

在節(jié)點的階段用時下面是線程顯示。它顯示了在特定的時間，哪個服務(wù)器的哪個線程在執(zhí)行任務(wù)。線程分配以堆棧條圖形顯示：

圖6 查詢計劃部分顯示Multiplex中的線程和分布

如果你將鼠標(biāo)移動到線程條上，你會看到各種統(tǒng)計，比如：

（1）#53：在正在執(zhí)行的查詢碎片根部的節(jié)點號。

（2）S∶2：服務(wù)器ID（2），擁有正在執(zhí)行的線程。

（3）T：0-3：正在執(zhí)行的線程的范圍。

（4） A∶2：在那個時間段內(nèi)執(zhí)行的線程的平均數(shù)。

（5）N∶3：在那個時間段內(nèi)用于計算線程統(tǒng)計的樣本數(shù)。

（6）23∶25∶13...— 23∶25∶14：時間段的起始和結(jié)束時間。

如果一個查詢碎片同時在多個服務(wù)器上執(zhí)行，你會發(fā)現(xiàn)線程被碎片堆棧中彼此相鄰且位于上方的碎片的相同的根節(jié)點而阻斷。

下圖的時間表是特定節(jié)點的詳細(xì)信息：

圖7 查詢計劃詳細(xì)的特定節(jié)點的信息

對于一個特定的節(jié)點，你會發(fā)現(xiàn)任務(wù)是如何被分布到服務(wù)器和線程的。在上面的“碎片1”中，服務(wù)器“kwd_nc1615”的任務(wù)單元的值是“25(2,6,4,4,3,2,3,1)”。這意味著有25個任務(wù)單元分配到這個服務(wù)器，而且任務(wù)單元2,6,4,4,3,2,3和1分別被分配到8個不同的線程。你也會發(fā)現(xiàn)有多少私有和共享臨時空間被用于執(zhí)行這個碎片。

“碎片2”顯示了首先分配到Worker節(jié)點的任 務(wù)單元數(shù)量。大于1意味著Leader節(jié)點在Worker節(jié)點開始處理之前首先執(zhí)行了某些任務(wù)。這可能是由于需要開始執(zhí)行任務(wù)的Worker產(chǎn)生了一個延遲。

“碎片3”顯示了“并行下池任務(wù)單元”，即整個碎片任務(wù)單元的總數(shù)。

4 錯誤是如何被處理的？

DQP可容忍Worker節(jié)點/網(wǎng)絡(luò)的失敗以及Worker節(jié)點的緩慢。如果一個Worker節(jié)點由于一個錯誤或者超時沒能完成任務(wù)單元，這個任務(wù)單元會重新回到Leader節(jié)點。如果發(fā)生這種現(xiàn)象，該Worker節(jié)點在碎片執(zhí)行期間將不會再分配給任務(wù)單元。

盡管一個Worker節(jié)點可能在執(zhí)行某個查詢碎片時發(fā)生失敗，它仍然可以在稍后被分配給不同查詢碎片的任務(wù)單元。