10.3.1 分區(qū)和插入性能

考慮插入的性能。Sybase最早對(duì)于分區(qū)的努力將能追溯至版本11.0，它旨在幫助查詢性能。盡管如此，真正的驅(qū)動(dòng)原因是降低或消除堆表最后一頁的競(jìng)爭(zhēng)。那時(shí)，Sybase僅支持全頁鎖定（APL），因此，并發(fā)的表插入常常被序列化到表的最后一頁上。但是，它充其量只是些許的幫助，因?yàn)閷?duì)于不斷增加的數(shù)據(jù)元素，索引競(jìng)爭(zhēng)依然存在（例如順序列或當(dāng)前時(shí)間）。隨著11.9版本中數(shù)據(jù)行鎖定的發(fā)布，通過分區(qū)來解除競(jìng)爭(zhēng)的需求不再。但是，11.x/12.x中的輪循分區(qū)模式對(duì)插入性能幫助很大，因?yàn)樗褂糜脩舻腟PID來決定用戶數(shù)據(jù)將插入哪個(gè)分片中。不幸的是，在ASE 12.5及之前的版本，沒有辦法分別將特定的分區(qū)分片放置于與其他分片不同的指定段上—因此，沒有達(dá)到完整的IO并發(fā)效果。ASE 15.0改進(jìn)了輪循分區(qū)，支持不同分區(qū)放置于不同段，映射至不同設(shè)備上，從而支持IO并發(fā)。

使用分區(qū)需要考慮的一個(gè)方面就是使用全局索引或本地索引。全局索引—缺省項(xiàng)—通過單獨(dú)的b-樹結(jié)構(gòu)實(shí)現(xiàn)如圖23。

圖23 分區(qū)表上的全局索引

圖24 分區(qū)表上的本地（分區(qū)）索引

正如所展示的，索引作為一個(gè)整體未分區(qū)的結(jié)構(gòu)存儲(chǔ)。另一方面，本地（分區(qū)）索引使用了與附表相同的分區(qū)模式和分區(qū)鍵進(jìn)行分區(qū)。本地索引的結(jié)果類似，如圖24。

注意索引本身是分區(qū)的。每種方法各有優(yōu)劣，如表18。

表18 全局、本地（分區(qū)）索引優(yōu)劣

在本地索引中（2），（3）部分的優(yōu)勢(shì)需要進(jìn)一步解釋為何其優(yōu)勢(shì)不如期望的那么大。根據(jù)每個(gè)分區(qū)的行數(shù)和索引鍵大小，本地分區(qū)可能中間級(jí)別的節(jié)點(diǎn)較少—即“較小”的索引高度。正如上面所顯示的，原先的索引高度為4，而分區(qū)索引二的高度為三，分區(qū)三的高度為2。

10.3.2 分區(qū)與插入性能

這將能稍微改善每個(gè)插入的性能，因?yàn)樾枰俚腎O索引樹遍歷來插入每個(gè)索引鍵值。例如，假設(shè)在上表上有5個(gè)索引。在未分區(qū)的表中，將遍歷主鍵/聚集索引以尋找行的插入點(diǎn)（讀取索引樹需要4個(gè)IO，1個(gè)用于讀取數(shù)據(jù)頁，加上寫入數(shù)據(jù)頁和寫入索引頁節(jié)點(diǎn)）。所以不得不遍歷其他4個(gè)索引來尋找索引插入點(diǎn)（4個(gè)IO用于讀取每個(gè)索引樹加上對(duì)每個(gè)葉頁面的寫入）。假設(shè)不會(huì)發(fā)生頁面分列、溢出頁面等，一個(gè)對(duì)表的插入成本（只考慮讀?。┤绫?9。

表19 插入成本讀取

作為對(duì)比，可考慮在范圍分區(qū)的最末端分區(qū)上的插入。最常見的范圍分區(qū)實(shí)現(xiàn)是“翻滾分區(qū)”，最后一個(gè)分區(qū)就是當(dāng)前的插入點(diǎn)。結(jié)果，最初的分區(qū)插入可能只會(huì)有一個(gè)索引級(jí)別。假設(shè)如上面展示的，它達(dá)到了最大值2，則讀取的IO成本應(yīng)如表20。

表20 IO成本讀取

也不是太驚人—一半。該問題可以很快地被引申至查詢的執(zhí)行也只需要一半的時(shí)間。這并非必須。從一個(gè)獨(dú)立用戶的角度，這可能不明顯。例如，很可能索引樹的最近部分都在數(shù)據(jù)緩存中—因此，所有的讀取都是邏輯讀取?？紤]到邏輯讀取的速度(內(nèi)存訪問)，節(jié)省的時(shí)間可能只是幾毫秒?？刹捎靡韵聹y(cè)試來證明：

（1）創(chuàng)建了一張有5個(gè)索引的數(shù)據(jù)行鎖定表(未分區(qū))。該表預(yù)裝了約3千萬行數(shù)據(jù)。然后在單獨(dú)的主機(jī)上有20個(gè)客戶端線程使用延遲提交和完整的準(zhǔn)備語句執(zhí)行1百萬個(gè)原子插入?？蛻舳司€程也可放在相同的主機(jī)上—或者就簡(jiǎn)單地在ASE中進(jìn)行處理，目的只是要模仿更為真實(shí)的配置。

（2）該表被刪除，隨后重建，使用基于date列上的30個(gè)分區(qū)。該表仍有5個(gè)索引—但是其中之一被創(chuàng)建為全局索引。最初的3千萬行數(shù)據(jù)被插入前面的29個(gè)分區(qū)中。相同的20個(gè)客戶端線程將1百萬行數(shù)據(jù)插入最后（第30個(gè)）分區(qū)中。

（3）使用基于date列的30個(gè)哈希分區(qū)重復(fù)第二項(xiàng)測(cè)試。結(jié)果將使30個(gè)分區(qū)中值分布均衡。

（4）使用輪循分區(qū)（30個(gè)分區(qū)）重復(fù)測(cè)試。由于輪循分區(qū)不支持本地索引，5個(gè)索引都被創(chuàng)建為全局索引。

（5）用30個(gè)范圍分區(qū)重復(fù)同樣的測(cè)試—單本次都使用本地索引。

（6）同樣的測(cè)試在全部本地索引的哈希分區(qū)上重復(fù)。

結(jié)果如表21。

表21 表分區(qū)索引數(shù)據(jù)

正如可以看到的，將全局索引改變?yōu)楸镜厮饕龑⒅荒芄?jié)省在大約160 s中5 s~6 s—或大約4%的時(shí)間。其次，范圍和輪循分區(qū)也只僅僅比基表插入快一點(diǎn)—除非范圍分區(qū)表僅包含本地索引。另一方面，哈希分區(qū)落后于未分區(qū)表，除非將全局索引改變?yōu)楸镜厮饕?。哈希值?0個(gè)分區(qū)中的分布被驗(yàn)證有2%的中間數(shù)值，因此并非是非平衡的模式造成的。值得注意的是，如果僅有20個(gè)客戶端，輪循模式僅使用30個(gè)分區(qū)中的20個(gè)—因此它是非平衡的。這對(duì)輪循分區(qū)是正常的。以上部分的結(jié)論是什么呢？

（1）如果因插入性能而分區(qū)，在全頁鎖定下將得到最佳效果，因?yàn)閲?yán)格分區(qū)是降低競(jìng)爭(zhēng)的手段。另一替代方法是僅使用數(shù)據(jù)行鎖定。比數(shù)據(jù)行鎖定還好的的是基于哈希的分區(qū)（以降低競(jìng)爭(zhēng)），因?yàn)楸镜厮饕龑⒛茉谒饕?jí)別幫助緩解競(jìng)爭(zhēng)（與輪循分區(qū)比較）。

（2）單獨(dú)插入在分區(qū)上提升最小，因?yàn)樗饕母叨葘⒂稍诰彺嬷械倪壿婭O彌補(bǔ)，因?yàn)樗鼈円呀?jīng)夠快了而額外的索引級(jí)別并不會(huì)太顯眼。

（3）可能能在真正小且持續(xù)小分區(qū)上獲得提升，因?yàn)榕c未分區(qū)表相比，索引高度可能有幾個(gè)或更多級(jí)別的巨大差別。

實(shí)際上，均衡分區(qū)對(duì)插入的優(yōu)勢(shì)可忽略不計(jì)，而對(duì)至少兩個(gè)有序較小分區(qū)的插入可能優(yōu)勢(shì)更大。

10.3.3 分區(qū)和查詢性能

如果分區(qū)對(duì)插入性能沒有太大幫助的話—那么減少的索引高度何時(shí)才能起作用呢？答案是在包含了連接的查詢中…當(dāng)然也有可能有傷害。先來看看它的優(yōu)勢(shì)。在上例中，對(duì)表新增了一百萬行。我們假設(shè)在夜里會(huì)運(yùn)行一些批處理任務(wù)，用于鑒別需要進(jìn)一步處理的特殊記錄。典型的批處理任務(wù)看起來像：

select row _id=identity(20),

into #rowsToBeProcessed

from trans _detail

where

and tran_date between and -- only need to check recent trans

update trans_detail

set

from #rowsToBeProcessed r, trans_detail t

where r. = t.

普通得就像電燈開關(guān)一樣。不同之處是通常只影響一小部分子集的更新被嵌入循環(huán)中以避免競(jìng)爭(zhēng)。

繼續(xù)假設(shè)該批處理將在最近的行中鑒別出10%的行—本例中是10萬行?；? 100萬行的不同分區(qū)模式的統(tǒng)計(jì)結(jié)果見表22。

表22 分區(qū)模式統(tǒng)計(jì)結(jié)果

在本例中，再次顯示出只節(jié)省了10萬次邏輯IO– 它意味著更少的物理IO因?yàn)椴惶赡芩行枰男卸荚趦?nèi)存中—它能從根本上減少執(zhí)行時(shí)間。注意，即使是全部緩存的情況下，10萬個(gè)邏輯IO也不足以彌補(bǔ)額外的查詢編譯和開銷復(fù)雜度—但是也僅討論了3 000萬行數(shù)據(jù)。包含了1億條數(shù)據(jù)的分區(qū)表可能會(huì)有優(yōu)勢(shì)。和原來一樣，可能區(qū)別很大。

區(qū)別一方面可能依賴于查詢的類型。例如，考慮以下典型的范圍查詢：

-- list all the transactions for a customer in last 10 days

-- (local) index on customer_id, tran_date

select *

from trans_detail

where customer_id =

and tran_date between dateadd (dd,-10, getdate ()) and getdate ()

現(xiàn)在，假設(shè)DBA成功說服了用每天一個(gè)分區(qū)的范圍分區(qū)來簡(jiǎn)化維護(hù)需求。在該情況下，查詢比未分區(qū)表需要更長(zhǎng)時(shí)間，使用更多IO！

未分區(qū)表—查詢將遍歷索引尋找第一行(10天前的)然后執(zhí)行表或索引范圍掃描直至當(dāng)前行。

范圍分區(qū)表（每天一個(gè)分區(qū)）—查詢將遍歷10個(gè)分區(qū)中的每個(gè)本地索引，然后在每個(gè)分區(qū)中執(zhí)行表/索引范圍掃描來找到前10天的數(shù)據(jù)。

假設(shè)在高度為8的索引上每天100個(gè)事務(wù)，且5個(gè)事務(wù)一頁，則未分區(qū)表將使用總計(jì)8（索引） + 200（掃描）=208個(gè)邏輯IO。范圍分區(qū)表將需要8*10=80（索引遍歷） + 10*20 = 200 （掃描），總IO成本為280。雖然區(qū)別頗小，但請(qǐng)考慮如果查詢跨越一年的問題—它將會(huì)有365個(gè)分區(qū)。不僅如此—并非所有的數(shù)據(jù)都在內(nèi)存中—使用未分區(qū)表，服務(wù)器將選擇異步預(yù)取(APF)和大IO來從磁盤中快速讀取數(shù)據(jù)，而在較小的分區(qū)中可能需要對(duì)每個(gè)掃描選擇開啟APF和大IO。這將造成總體成本偏高—可能到達(dá)優(yōu)化器選擇另一低成本索引的程度（或甚至是分區(qū)掃描），如果統(tǒng)計(jì)值陳舊。

關(guān)鍵要考慮的因素是要確保分區(qū)范圍與業(yè)務(wù)需求一致。例如，大部分商業(yè)操作是基于季度的—因此按照完整的季度范圍的日期分區(qū)將能滿足大部分查詢(諸如典型的季度銷售、季度的語句和季度與季度間的分析)能完全利用APF和大IO。而DBA可能感到維護(hù)影響，考慮以下內(nèi)容：

（1）大部分大型維護(hù)操作都被安排在周末—通?？赡芤粋€(gè)季度只有一次。因此，像歸檔這樣的大型操作可能每個(gè)季度只發(fā)生一次—粒度更小的分區(qū)沒有幫助。

（2）在某天發(fā)生的銷售將可能在后續(xù)幾天有諸如遞送、計(jì)費(fèi)等銷售后的活動(dòng)影響事務(wù)。因此，統(tǒng)計(jì)更新(可能)需要在分區(qū)上每周執(zhí)行一次。

（3）在一些業(yè)務(wù)中，大部分銷售都是季度的最后幾個(gè)星期中完成的—因此許多分區(qū)可能會(huì)是空的—或接近于空。

再次強(qiáng)調(diào)，需求可能是不同的—但重要的是更了解業(yè)務(wù)需求的開發(fā)人員，而不是DBA，需要與DBA一起確保分區(qū)的粒度能滿足大部分的查詢范圍。顯然是不利的方面。

但是，也有一個(gè)有利的方面。還記得前面作為分區(qū)實(shí)現(xiàn)，跨越多張物理表（用于積極聚合）的聯(lián)合視圖？語義分區(qū)對(duì)其有很大的優(yōu)勢(shì)。在原來的討論中，我們注意到在allrows_mix情況下，優(yōu)化器選擇使用將所有數(shù)據(jù)聯(lián)合至工作表中，對(duì)工作表排序然后再對(duì)銷售數(shù)據(jù)使用和并連接。使用工作表來做聯(lián)合是因?yàn)閮?yōu)化器不清楚哪些數(shù)據(jù)在哪些“分區(qū)”（或表）中。例如，除了應(yīng)用程序邏輯外—沒有別的辦法能阻止2008數(shù)據(jù)出現(xiàn)在2007“分區(qū)”中。使用語義分區(qū)，優(yōu)化器了解哪些數(shù)據(jù)在哪些分區(qū)中并能避免不必要的union all/合并排序。它列出了每種方法的優(yōu)劣，如表23。

表23 語義分區(qū)各種方法的優(yōu)劣

需要記住的是—不是二者必須選一—通過在一個(gè)或多個(gè)可能使用了語義分區(qū)的物理表上使用聯(lián)合視圖“分區(qū)表”，兩者可以結(jié)合使用。

11 結(jié)束語

ASE 15.0.x為應(yīng)用程序開發(fā)人員提供了一些有趣的功能以及必須從較早版本升級(jí)的理由。從新的較大數(shù)據(jù)類型—到可讀性較強(qiáng)的#temp表名—到函數(shù)索引和計(jì)算列—SQL用戶定義函數(shù)和替代觸發(fā)器—到查詢優(yōu)化的改善—對(duì)開發(fā)人員友好的新工具的功能—到XTP一覽—到表分區(qū)。

正如展示的，通常當(dāng)這些功能結(jié)合使用時(shí)，他們的威力才能被真正認(rèn)識(shí)。不論是為“自動(dòng)解析”關(guān)鍵元素而在XML上建立的函數(shù)索引和計(jì)算列—還是在聯(lián)合視圖上的替代觸發(fā)器和DSS優(yōu)化，諸如跨OLTP和歸檔系統(tǒng)的積極聚合。結(jié)果證明了Sybase ASE的新發(fā)布不僅是對(duì)DBA需求的另一個(gè)升級(jí)平臺(tái)—而且為開發(fā)人員提供了滿足當(dāng)今對(duì)高容量/高速度業(yè)務(wù)環(huán)境中涌現(xiàn)出的應(yīng)用程序開發(fā)需求。