揭秘SQL Server 2014有哪几种新特性(3)-可更新列存储聚集索引

简介

     列存储索引其实在在SQL Server 2012中就已存在，但SQL Server 2012中只允许建立非聚集列索引，这意味着列索引是在原本的行存储索引之上的援用了底层的数据，因此会消耗更多的存储空间，但2012中的限制最大的或者一旦将非聚集列存储索引建立在某个表上时，该表将变成只读，这使得即便在数据仓库中使用列索引，每次更新数据都变成非常痛苦的事。SQL Server 2014中的可更新聚集列索引则解决了该问题。

可更新聚集列存储索引？

    聚集列存储索引的概念可以类比于传统的行存储，聚集索引既是数据本身，列存储的概念也是一样。将数据依照列存储而不是行存储则提供了诸多好处，

首先对大量聚合、扫描、分组等数据仓库类查询仅仅需要读取选择的列，对需要Join多个表的星型结构等场景性能提升特别明显 其次是列索引可以更新，并且每一个表中只需要一个（这是优点也是缺点，由于没法再建非聚集索引）聚集列索引便可，大大节省了空间 列索引由因而按列存储，同一列中数据类型是一样的，因此可以更加容易的实现更高的紧缩比率 列存储的表会占用更少的存储空间，因此存在更少的IO

那末列存储索引有甚么弊端呢？

    行存储对OLTP操作十分合适，由于每一个聚集索引键可以标识某一行，该行存储在物理磁盘上也连续，因此可以利用Seek操作完成大量选择性非常高的查询，而列存储索引同一行的每列其实不在物理上联系，并且列存储聚集索引中并没有“主键”的概念，因此其实不存在SEEK操作，如果大量OLTP类的查询，性能将会出现问题。

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

图1.列存储索引只支持Scan操作

那末列索引是如何存储呢？

    列索引存储可以望文生义，就是按列存储。这个进程可以分为3个阶段，首先将一堆行分组，这就是所谓的“行组”，分组完成后，再按列切分，最后将列紧缩，如图2所示。

图2.列存储的进程

    我们注意到其中有一部份不够分组的，那末就直接让这部份数据以传统行存储的情势老实呆着吧，这就是所谓的Deltastore，等数据增长到可以分组时再进行分组，目前SQL Server 2014认为10W以下的数据都不够分组。

    上述列存储的两部份我们可以通过2014新引入的DMV进行观测，如图3所示。在图3中，我们队目前已存在31465行的聚集列索引插入了1000行新的数据，则SQL Server认为这部份数据不满10W行，因此以Deltastore的方式存在。

图3.紧缩后的列和Deltastore

     当我们再插入1000数据时，可以视察到DeltaStore中的数据又增加了1000，到达2000，但仍然存在DeltaStore中。如图4所示。

图4.再次插入的数据仍然在DeltaStore中

      那末我插入大量的行进行观测，会发现，大批量的数据仍然以DeltaStore的方式存储，如图5。

图5.插入大量数据后也没法将数据紧缩

    那末究竟什么时候会紧缩这些数据呢，根据BOL的说法：http://msdn.microsoft.com/en-us/library/dn223749(v=sql.120).aspx，会有一个后台的线程定期检测，另外当重建或整理索引时也能够自动归档，如图6所示。

图6.重建索引后归档列存储索引

空间占用比较

    可更新列存储聚集索引的紧缩比率是最高的，由于同一列常常是同一类数据，因此这类数据有更好的紧缩比。现在我纯洁的从传统聚集索引、页紧缩、行紧缩、列存储索引所占用的空间进行比较，固然，如果我们把传统表的非聚集索引算上，那末行存储表将会需要更多的空间。我们用3W多条数据进行简单比对，如图7所示。

图7.区别存储占用空间

    图7的示例数据很少，但仍然可以看到，列存储比即便没有非聚集索引的行存储，占用空间也几近少了2/3，提升不可谓不巨大。

性能简单比较

    首先，先依照列存储，我们选择所有的列，对行存储来讲需要选择全部表才能把一列数据全部读取出来，但列存储则只需要读取被选择的列，因此如果只选择特定的列的话，列存储性能提升巨大，如图8所示。

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

    但反之，我们尝试一个典型的OLTP操作，只选择一行的所有列，则会和图8的结果大相庭径了。如图9所示。

图9.对OLTP操作来讲，列存储索引非常乏力

小结

    本文论述了SQL Server 2014中可更新列存储索引的原理，概念，适用处景、空间使用情况，并举出两个OLAP和OLTP极真个例子进行性能比对。列存储索引对数据仓库和类OLAP查询来讲是一个巨大的奔腾。