簡介

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

可更新聚集列存儲索引？

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

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

那么列存儲索引有什么弊端呢？

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

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

圖1.列存儲索引只支持Scan操作

那么列索引是如何存儲呢？

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

圖2.列存儲的過程

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

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

圖3.壓縮后的列和Deltastore

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

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

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

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

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

圖6.重建索引后歸檔列存儲索引

空間占用比較

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

圖7.不同存儲占用空間

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

性能簡單比較

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

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

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

圖9.對于OLTP操作來說，列存儲索引非常乏力

小結(jié)

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