簡(jiǎn)介

列存儲(chǔ)索引其實(shí)在在SQL Server 2012中就已經(jīng)存在，但SQL Server 2012中只允許建立非聚集列索引，這意味著列索引是在原有的行存儲(chǔ)索引之上的引用了底層的數(shù)據(jù)，因此會(huì)消耗更多的存儲(chǔ)空間，但2012中的限制最大的還是一旦將非聚集列存儲(chǔ)索引建立在某個(gè)表上時(shí)，該表將變?yōu)橹蛔x，這使得即使在數(shù)據(jù)倉(cāng)庫(kù)中使用列索引，每次更新數(shù)據(jù)都變成非常痛苦的事。SQL Server 2014中的可更新聚集列索引則解決了該問(wèn)題。

可更新聚集列存儲(chǔ)索引？

聚集列存儲(chǔ)索引的概念可以類(lèi)比于傳統(tǒng)的行存儲(chǔ)，聚集索引既是數(shù)據(jù)本身，列存儲(chǔ)的概念也是同樣。將數(shù)據(jù)按照列存儲(chǔ)而不是行存儲(chǔ)則提供了諸多好處，

首先對(duì)于大量聚合、掃描、分組等數(shù)據(jù)倉(cāng)庫(kù)類(lèi)查詢僅僅需要讀取選擇的列，對(duì)于需要Join多個(gè)表的星型結(jié)構(gòu)等場(chǎng)景性能提升尤其明顯 其次是列索引可以更新，并且每個(gè)表中只需要一個(gè)（這是優(yōu)點(diǎn)也是缺點(diǎn)，因?yàn)闊o(wú)法再建非聚集索引）聚集列索引即可，大大節(jié)省了空間 列索引由于是按列存儲(chǔ)，同一列中數(shù)據(jù)類(lèi)型是一樣的，因此可以更加容易的實(shí)現(xiàn)更高的壓縮比率 列存儲(chǔ)的表會(huì)占用更少的存儲(chǔ)空間，因此存在更少的IO

那么列存儲(chǔ)索引有什么弊端呢？

行存儲(chǔ)對(duì)于OLTP操作十分適合，因?yàn)槊總€(gè)聚集索引鍵可以標(biāo)識(shí)某一行，該行存儲(chǔ)在物理磁盤(pán)上也連續(xù)，因此可以利用Seek操作完成大量選擇性非常高的查詢，而列存儲(chǔ)索引同一行的每一列并不在物理上聯(lián)系，并且列存儲(chǔ)聚集索引中并沒(méi)有“主鍵”的概念，因此并不存在SEEK操作，如果大量OLTP類(lèi)的查詢，性能將會(huì)出現(xiàn)問(wèn)題。

列存儲(chǔ)索引只支持Scan操作，如圖1所示。

圖1.列存儲(chǔ)索引只支持Scan操作

那么列索引是如何存儲(chǔ)呢？

列索引存儲(chǔ)可以望文生義，就是按列存儲(chǔ)。這個(gè)過(guò)程可以分為3個(gè)階段，首先將一堆行分組，這就是所謂的“行組”，分組完成后，再按列切分，最后將列壓縮，如圖2所示。

圖2.列存儲(chǔ)的過(guò)程

我們注意到其中有一部分不夠分組的，那么就直接讓這部分?jǐn)?shù)據(jù)以傳統(tǒng)行存儲(chǔ)的形式老實(shí)呆著吧，這就是所謂的Deltastore，等數(shù)據(jù)增長(zhǎng)到可以分組時(shí)再進(jìn)行分組，目前SQL Server 2014認(rèn)為10W以下的數(shù)據(jù)都不夠分組。

上述列存儲(chǔ)的兩部分我們可以通過(guò)2014新引入的DMV進(jìn)行觀測(cè)，如圖3所示。在圖3中，我們隊(duì)目前已經(jīng)存在31465行的聚集列索引插入了1000行新的數(shù)據(jù)，則SQL Server認(rèn)為這部分?jǐn)?shù)據(jù)不滿10W行，因此以Deltastore的方式存在。

圖3.壓縮后的列和Deltastore

當(dāng)我們?cè)俨迦?000數(shù)據(jù)時(shí)，可以觀察到DeltaStore中的數(shù)據(jù)又增加了1000，達(dá)到2000，但依然存在DeltaStore中。如圖4所示。

圖4.再次插入的數(shù)據(jù)依然在DeltaStore中

那么我插入大量的行進(jìn)行觀測(cè)，會(huì)發(fā)現(xiàn)，大批量的數(shù)據(jù)依然以DeltaStore的方式存儲(chǔ)，如圖5。

圖5.插入大量數(shù)據(jù)后也無(wú)法將數(shù)據(jù)壓縮

那么究竟何時(shí)會(huì)壓縮這些數(shù)據(jù)呢，根據(jù)BOL的說(shuō)法：http://msdn.microsoft.com/en-us/library/dn223749(v=sql.120).aspx，會(huì)有一個(gè)后臺(tái)的線程定期檢測(cè)，此外當(dāng)重建或整理索引時(shí)也可以自動(dòng)歸檔，如圖6所示。

圖6.重建索引后歸檔列存儲(chǔ)索引

空間占用比較

可更新列存儲(chǔ)聚集索引的壓縮比率是最高的，因?yàn)橥涣型峭活?lèi)數(shù)據(jù)，因此這類(lèi)數(shù)據(jù)有更好的壓縮比?，F(xiàn)在我純粹的從傳統(tǒng)聚集索引、頁(yè)壓縮、行壓縮、列存儲(chǔ)索引所占用的空間進(jìn)行比較，當(dāng)然，如果我們把傳統(tǒng)表的非聚集索引算上，那么行存儲(chǔ)表將會(huì)需要更多的空間。我們用3W多條數(shù)據(jù)進(jìn)行簡(jiǎn)單比對(duì)，如圖7所示。

圖7.不同存儲(chǔ)占用空間

圖7的示例數(shù)據(jù)很少，但依然可以看到，列存儲(chǔ)比即使沒(méi)有非聚集索引的行存儲(chǔ)，占用空間也幾乎少了2/3，提升不可謂不巨大。

性能簡(jiǎn)單比較

首先，先按照列存儲(chǔ)，我們選擇所有的列，對(duì)于行存儲(chǔ)來(lái)說(shuō)需要選擇整個(gè)表才能把一列數(shù)據(jù)全部讀取出來(lái)，但列存儲(chǔ)則只需要讀取被選擇的列，因此如果只選擇特定的列的話，列存儲(chǔ)性能提升巨大，如圖8所示。

圖8.可更新列存儲(chǔ)聚集索引性能提升巨大

但反之，我們嘗試一個(gè)典型的OLTP操作，只選擇一行的所有列，則會(huì)和圖8的結(jié)果大相庭徑了。如圖9所示。

圖9.對(duì)于OLTP操作來(lái)說(shuō)，列存儲(chǔ)索引非常乏力

小結(jié)

本文闡述了SQL Server 2014中可更新列存儲(chǔ)索引的原理，概念，適用場(chǎng)景、空間使用情況，并舉出兩個(gè)OLAP和OLTP極端的例子進(jìn)行性能比對(duì)。列存儲(chǔ)索引對(duì)于數(shù)據(jù)倉(cāng)庫(kù)和類(lèi)OLAP查詢來(lái)說(shuō)是一個(gè)巨大的飛躍。

版權(quán)聲明：本站文章來(lái)源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請(qǐng)保持原文完整并注明來(lái)源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來(lái)源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來(lái)，僅供學(xué)習(xí)參考，不代表本站立場(chǎng)，如有內(nèi)容涉嫌侵權(quán)，請(qǐng)聯(lián)系alex-e#qq.com處理。