登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发评论 > 正文

SQL Server 2014可更新列存储聚集索引

2014-02-18 10:57    博客园 来源:博客园  作者: 宋沄剑 编辑: 徐志远

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

  可更新聚集列存储索引?

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

  首先对于大量聚合、扫描、分组等数据仓库类查询仅仅需要读取选择的列,对于需要Join多个表的星型结构等场景性能提升尤其明显

  其次是列索引可以更新,并且每个表中只需要一个(这是优点也是缺点,因为无法再建非聚集索引)聚集列索引即可,大大节省了空间

  列索引由于是按列存储,同一列中数据类型是一样的,因此可以更加容易的实现更高的压缩比率

  列存储的表会占用更少的存储空间,因此存在更少的IO

  那么列存储索引有什么弊端呢?

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

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

SQL Server 2014可更新列存储聚集索引
图1.列存储索引只支持Scan操作

  那么列索引是如何存储呢?

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

SQL Server 2014可更新列存储聚集索引
▲图2.列存储的过程

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

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

SQL Server 2014可更新列存储聚集索引
▲图3.压缩后的列和Deltastore

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

SQL Server 2014可更新列存储聚集索引
▲图4.再次插入的数据依然在DeltaStore中

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

SQL Server 2014可更新列存储聚集索引
▲图5.插入大量数据后也无法将数据压缩

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

SQL Server 2014可更新列存储聚集索引
▲图6.重建索引后归档列存储索引

  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部