BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

SQL Server 2011中基于列的存储方式

| 作者 Jonathan Allen 关注 595 他的粉丝 ,译者 侯伯薇 关注 0 他的粉丝 发布于 2011年3月15日. 估计阅读时间: 2 分钟 | AICon 关注机器学习、计算机视觉、NLP、自动驾驶等20+AI热点技术和最新落地成功案例。

和大多数主流数据库一样,如果表拥有聚集索引,那么SQL Server就会以B-树的方式存储,否则就会使用的方式存储。这两种方法本质上都是基于行的,其中每页中行的条数会根据总体上行的大小不同而不同。从SQL Server 2011开始,微软为我们提供了第三种选择。SQL Server会提供一种“列存储索引”,从而以列而不是行的方式来存储数据。

当使用数据规模为1TB、记录条数为十四亿四千万的表时,微软声称基于列的查询在CPU时间上会有16倍的提升,而在使用时间上会有455倍的提高。在真实情况下,这意味着本来要耗费501秒的查询,现在只需要1.1秒就可以完成了。这项测试是在拥有32个逻辑处理器和256GB内存的计算机上执行的。

微软把每个列都隔离在自身的一组页中,从而达到了这种惊人的改善。当执行查询的时候,只会从磁盘载入位于结果集中的列。而包含其它列的页会被忽略。

这种方法相当于为每种我们所能想象到的列组合创建替代索引。然而,这种方式不会消耗大量的磁盘空间,它实际上会比传统的表占用更小的空间。由于SQL Server的压缩会发生在页级别上,并且和行相比,列中的数据更容易重复,所以使用列存储索引的表将会拥有更高的压缩等级。

但暂时我们还不能轻易决定使用列存储索引。首先也是最重要的,它们是不可更新的。一旦创建了列存储的索引,那么就不允许在表上执行插入、更新或者删除等操作了。微软期望更多商店每天对数据进行刷新,否则就需要把数据做只读处理。在刷新周期中,我们会删除索引,更新数据,然后再重新建立索引。由于这肯定是代价昂贵的操作,所以我们可以使用垂直分区来把操作限制到逻辑表的子集范围内。

使用列存储的索引也会导致性能的降低。如果你使用大多数列,那么重新组合行会耗费大量的资源。这意味着OLTP样式的查询应该避免这种方式,而对于OLAP形式的查询,这种方式会比较有利。或者换句话说,如果你在编写“SELECT *”或者每次抓取一行数据,那么列存储索引就不适合你。

查看英文原文:Column-based Storage in SQL Server 2011

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

性能上 期望有好的改善 by 郝 宪玮

性能上 期望有好的改善

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT