簡(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中的可更新聚集列索引則解決了該問題。

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

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

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

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

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

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

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

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

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

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

    我們注意到其中有一部分不夠分組的，那么就直接讓這部分?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ǔ)的兩部分我們可以通過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ù)后也無法將數(shù)據(jù)壓縮

    那么究竟何時(shí)會(huì)壓縮這些數(shù)據(jù)呢，根據(jù)BOL的說法：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)橥涣型峭活悢?shù)據(jù)，因此這類數(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ǔ)比即使沒有非聚集索引的行存儲(chǔ)，占用空間也幾乎少了2/3，提升不可謂不巨大。

性能簡(jiǎn)單比較

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

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

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

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

小結(jié)

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