瞭解SQL Server 2008的新壓縮特性

iSQlServer發表於2008-12-17
從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的另一個特性,它是通過普通的檔案系統型壓縮技術實現的,對於給定的資料庫,只有啟用或者禁用,沒有其它可調節選項。
  雖然非企業版伺服器可以恢復帶壓縮的備份,但這所有的壓縮選項極有可能成為企業版專享選項。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/16436858/viewspace-512209/,如需轉載,請註明出處,否則將追究法律責任。

相關文章