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

作者 Jonathan Allen 译者 侯伯薇 发布于 2011年3月14日

领域

企业架构,

运维 & 基础架构,

架构 & 设计,

语言 & 开发

主题

SQL Server ,

.NET ,

关系型数据库 ,

数据访问 ,

微软 ,

数据库设计 ,

编程 ,

数据库 ,

数据仓库

分享到

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

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

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

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

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

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

译者 侯伯薇 是InfoQ中文站架构社区编辑，有多年对日和国内项目开发经验，目前关注企业中技术与实际业务之间的融合和协作。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！

1. 返回顶部

   性能上 期望有好的改善

   发表人 郝 宪玮

   性能上 期望有好的改善

   回复