设为首页 收藏本站
查看: 1371|回复: 0

[经验分享] SQL Server 2014新特性探秘(3)-可更新列存储聚集索引

[复制链接]

尚未签到

发表于 2015-6-29 13:25:59 | 显示全部楼层 |阅读模式
简介
    列存储索引其实在在SQL Server 2012中就已经存在,但SQL Server 2012中只允许建立非聚集列索引,这意味着列索引是在原有的行存储索引之上的引用了底层的数据,因此会消耗更多的存储空间,但2012中的限制最大的还是一旦将非聚集列存储索引建立在某个表上时,该表将变为只读,这使得即使在数据仓库中使用列索引,每次更新数据都变成非常痛苦的事。SQL Server 2014中的可更新聚集列索引则解决了该问题。
  
  可更新聚集列存储索引?
    聚集列存储索引的概念可以类比于传统的行存储,聚集索引既是数据本身,列存储的概念也是同样。将数据按照列存储而不是行存储则提供了诸多好处,
  
       
  • 首先对于大量聚合、扫描、分组等数据仓库类查询仅仅需要读取选择的列,对于需要Join多个表的星型结构等场景性能提升尤其明显   
  • 其次是列索引可以更新,并且每个表中只需要一个(这是优点也是缺点,因为无法再建非聚集索引)聚集列索引即可,大大节省了空间   
  • 列索引由于是按列存储,同一列中数据类型是一样的,因此可以更加容易的实现更高的压缩比率   
  • 列存储的表会占用更少的存储空间,因此存在更少的IO
    
  那么列存储索引有什么弊端呢?
    行存储对于OLTP操作十分适合,因为每个聚集索引键可以标识某一行,该行存储在物理磁盘上也连续,因此可以利用Seek操作完成大量选择性非常高的查询,而列存储索引同一行的每一列并不在物理上联系,并且列存储聚集索引中并没有“主键”的概念,因此并不存在SEEK操作,如果大量OLTP类的查询,性能将会出现问题。
  列存储索引只支持Scan操作,如图1所示。
DSC0000.png
  图1.列存储索引只支持Scan操作
  
  那么列索引是如何存储呢?
    列索引存储可以望文生义,就是按列存储。这个过程可以分为3个阶段,首先将一堆行分组,这就是所谓的“行组”,分组完成后,再按列切分,最后将列压缩,如图2所示。
DSC0001.gif
  图2.列存储的过程
  
  我们注意到其中有一部分不够分组的,那么就直接让这部分数据以传统行存储的形式老实呆着吧,这就是所谓的Deltastore,等数据增长到可以分组时再进行分组,目前SQL Server 2014认为10W以下的数据都不够分组。
  上述列存储的两部分我们可以通过2014新引入的DMV进行观测,如图3所示。在图3中,我们队目前已经存在31465行的聚集列索引插入了1000行新的数据,则SQL Server认为这部分数据不满10W行,因此以Deltastore的方式存在。
DSC0002.png
  图3.压缩后的列和Deltastore
  
  当我们再插入1000数据时,可以观察到DeltaStore中的数据又增加了1000,达到2000,但依然存在DeltaStore中。如图4所示。
DSC0003.png
  图4.再次插入的数据依然在DeltaStore中
  
  那么我插入大量的行进行观测,会发现,大批量的数据依然以DeltaStore的方式存储,如图5。
DSC0004.png
  图5.插入大量数据后也无法将数据压缩
  
  那么究竟何时会压缩这些数据呢,根据BOL的说法:http://msdn.microsoft.com/en-us/library/dn223749(v=sql.120).aspx,会有一个后台的线程定期检测,此外当重建或整理索引时也可以自动归档,如图6所示。
DSC0005.png
  图6.重建索引后归档列存储索引
  
  空间占用比较
    可更新列存储聚集索引的压缩比率是最高的,因为同一列往往是同一类数据,因此这类数据有更好的压缩比。现在我纯粹的从传统聚集索引、页压缩、行压缩、列存储索引所占用的空间进行比较,当然,如果我们把传统表的非聚集索引算上,那么行存储表将会需要更多的空间。我们用3W多条数据进行简单比对,如图7所示。
DSC0006.png
  图7.不同存储占用空间
  
  图7的示例数据很少,但依然可以看到,列存储比即使没有非聚集索引的行存储,占用空间也几乎少了2/3,提升不可谓不巨大。
  
  性能简单比较
    首先,先按照列存储,我们选择所有的列,对于行存储来说需要选择整个表才能把一列数据全部读取出来,但列存储则只需要读取被选择的列,因此如果只选择特定的列的话,列存储性能提升巨大,如图8所示。
DSC0007.png
  图8.可更新列存储聚集索引性能提升巨大
  
  但反之,我们尝试一个典型的OLTP操作,只选择一行的所有列,则会和图8的结果大相庭径了。如图9所示。
DSC0008.png
  图9.对于OLTP操作来说,列存储索引非常乏力
  
  小结
    本文阐述了SQL Server 2014中可更新列存储索引的原理,概念,适用场景、空间使用情况,并举出两个OLAP和OLTP极端的例子进行性能比对。列存储索引对于数据仓库和类OLAP查询来说是一个巨大的飞跃。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-81511-1-1.html 上篇帖子: 收缩SQL Server日志不是那么简单的(翻译) 下篇帖子: (provider: 命名管道提供程序, error: 40
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表