| 導購 | 订阅 | 在线投稿
分享
 
 
 

了解SQL Server 2008的新壓縮特性

來源:互聯網  2008-06-01 00:00:57  評論

從SQL Server 2005開始,在企業版和開發版中增加了一種叫做vardecimal的新存儲格式,這個表級的選項會影響到decimal和numeric字段。當對值的精度要求低于字段可用精度,如在一個decimal(18,9)類型的字段中存儲1.5這個數值時,存儲上就需要有相應的壓縮。從效果上來看,它就是一個varchar類型的數字型版本。

無論從哪方面來看,SQL Server 2008的數據壓縮都與現在有著巨大的差異(盡管它依然支持或者說包括vardecimal類型)——引起這種差異的真相是,如果你對一個給定的table/index啓用壓縮功能,那麽底層的row/page格式將不再相同——是的,就是這樣,你聽得沒錯——如果你使用壓縮(ROW或者PAGE),那麽SQL 2008的row/page格式將不同于現有的格式(如果你只是在table/index上使用壓縮的話)。因此,在SQL 2008中,有兩種,沒錯,是兩種可選row/page數據格式。你現在可能會想知道「那麽,如果row/page格式改變了,那你們究竟是如何在這麽短的時間內,依然有足夠的時間去重新生成SQL Server所有需要識別這些格式的組件的呢?」答案就是我們不需要那樣做——因爲Storage Engine是SQL 2008中唯一一個需要知道新的row/page格式的組件。

行級壓縮將大幅減少元數據所需的變量長度,較以前每個字段需要花費2個字節來存儲,現在只要僅僅3個位。字段本身現在也變得更小,在整型字段中存儲像1這樣的數值,只需要一個字節,而大數值則最多只需要4個字節。

行級壓縮則允許在行間共享共有數據。Chad首先談到的兩種技術就是列前綴和頁字典:

假設你在一頁的數據行中有一列數據有這些值:『Chad』、『Chadwick』、『Chadly』、『Chad』、『Chadster』、『Chadwick』和『Chadly』(故意重複的數值)——正如你所見,有相當多的冗余『前綴』數據在這一頁的同一列的不同行中,是吧?因此,你最終可能會想到這樣的一個場景:將列的前綴『Chad』存儲在CI結構中,每一個列的最後都指向這個前綴值,最後出現在磁盤上的值會像這樣:『』,『1wick』,『1ly』,『1ster』,『1wick』和『1ly』。

所以,對于上述例子中的含有Chad的同列數值,在經過對「列前綴」值進行計算和存儲後,你可能得到一個會含有如『1ly』和『1wick』這些值的頁字典,而真正行內數值則極有可能看上去像這樣:『』、『2』、『3』、『』、『1ster』、『3』和『2』。通過這種方式,我們讓原本需要大約25個字節來存儲的行數據,減少到只要大約17個字節來存儲,節省30%以上。

每一個頁都是單獨壓縮的,前綴和字典也存儲在頁內。由于頁是存儲分配的原子單位,將半頁壓縮到四分之一頁是沒有任何意義的,所以,只有在頁的內容快滿的時候才會開始壓縮處理。

在使用行和頁壓縮時還有一個性能權衡問題,因爲CPU使用率會上升,但I/O使用率和內存占用會下降。

Backup Compression是2008的另一個特性,它是通過普通的文件系統型壓縮技術實現的,對于給定的數據庫,只有啓用或者禁用,沒有其它可調節選項。

雖然非企業版服務器可以恢複帶壓縮的備份,但這所有的壓縮選項極有可能成爲企業版專享選項。

從SQL Server 2005開始,在企業版和開發版中增加了一種叫做vardecimal的新存儲格式,這個表級的選項會影響到decimal和numeric字段。當對值的精度要求低于字段可用精度,如在一個decimal(18,9)類型的字段中存儲1.5這個數值時,存儲上就需要有相應的壓縮。從效果上來看,它就是一個varchar類型的數字型版本。 無論從哪方面來看,SQL Server 2008的數據壓縮都與現在有著巨大的差異(盡管它依然支持或者說包括vardecimal類型)——引起這種差異的真相是,如果你對一個給定的table/index啓用壓縮功能,那麽底層的row/page格式將不再相同——是的,就是這樣,你聽得沒錯——如果你使用壓縮(ROW或者PAGE),那麽SQL 2008的row/page格式將不同于現有的格式(如果你只是在table/index上使用壓縮的話)。因此,在SQL 2008中,有兩種,沒錯,是兩種可選row/page數據格式。你現在可能會想知道「那麽,如果row/page格式改變了,那你們究竟是如何在這麽短的時間內,依然有足夠的時間去重新生成SQL Server所有需要識別這些格式的組件的呢?」答案就是我們不需要那樣做——因爲Storage Engine是SQL 2008中唯一一個需要知道新的row/page格式的組件。 行級壓縮將大幅減少元數據所需的變量長度,較以前每個字段需要花費2個字節來存儲,現在只要僅僅3個位。字段本身現在也變得更小,在整型字段中存儲像1這樣的數值,只需要一個字節,而大數值則最多只需要4個字節。 行級壓縮則允許在行間共享共有數據。Chad首先談到的兩種技術就是列前綴和頁字典: 假設你在一頁的數據行中有一列數據有這些值:『Chad』、『Chadwick』、『Chadly』、『Chad』、『Chadster』、『Chadwick』和『Chadly』(故意重複的數值)——正如你所見,有相當多的冗余『前綴』數據在這一頁的同一列的不同行中,是吧?因此,你最終可能會想到這樣的一個場景:將列的前綴『Chad』存儲在CI結構中,每一個列的最後都指向這個前綴值,最後出現在磁盤上的值會像這樣:『』,『1wick』,『1ly』,『1ster』,『1wick』和『1ly』。 所以,對于上述例子中的含有Chad的同列數值,在經過對「列前綴」值進行計算和存儲後,你可能得到一個會含有如『1ly』和『1wick』這些值的頁字典,而真正行內數值則極有可能看上去像這樣:『』、『2』、『3』、『』、『1ster』、『3』和『2』。通過這種方式,我們讓原本需要大約25個字節來存儲的行數據,減少到只要大約17個字節來存儲,節省30%以上。 每一個頁都是單獨壓縮的,前綴和字典也存儲在頁內。由于頁是存儲分配的原子單位,將半頁壓縮到四分之一頁是沒有任何意義的,所以,只有在頁的內容快滿的時候才會開始壓縮處理。 在使用行和頁壓縮時還有一個性能權衡問題,因爲CPU使用率會上升,但I/O使用率和內存占用會下降。 Backup Compression是2008的另一個特性,它是通過普通的文件系統型壓縮技術實現的,對于給定的數據庫,只有啓用或者禁用,沒有其它可調節選項。 雖然非企業版服務器可以恢複帶壓縮的備份,但這所有的壓縮選項極有可能成爲企業版專享選項。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有