【2011-3-7】SQL Server 2011 基于列的存储

SQL Server 2011 基于列的存储

文章来源：http://www.infoq.com/news/2011/03/Columnstore-index
发表: Jonathan Allen 日期：2011-3-7
译者：TransBean  翻译主页：http://blog.csdn.net/transbean

    就像大多数主流数据库一样,如果有一个集群索引的话SQL Server通常使用B树 来保存一个表，除非它使用堆。两种方法基本上都是基于行的，每分页行数的变化依赖于总的行大小。通过SQL Server 2011， 第三种选择变得可行。通过使用“列存储索引”, SQL Server 从列的方式存储数据来替代从行的方式.

    当使用一个具有1TB和1.44万亿行的表时，Microsoft声称面向列的查询会16倍的提高CPU时间，以及455倍的极大提高处理所需的时间。实际上这意味着一个查询原本应花费501秒而缩减到仅仅1.1秒.这个测试在一台32核处理器256GB内存的机器上完成。

    这令人惊讶的提升得益于在分页的集合中隔离每一列.当一个查询在从磁盘加载的结果集中的各列中完成时.分页中包含的其他列会被简单的忽略掉.

    这非常像有一个Covering Index(覆盖索引)包含各列的每种可能组合.但无需花费巨量的硬盘空间，它实际上比传统表占用更少.由于SQL Server在分页级压缩占用空间，一个列比一个行可预期更多的存在重复数据，具有列存储索引的表预计应有更高的压缩级别。

    不能够轻易的下使用列存储索引的决定。首先和首要的，他们不可更新.一旦列存储索引被创建，新的插入、更新或删除操作在这个表上将不再允许。Microsoft期望大多数的商店使用一个每日刷新的循环或其他方式而将这些数据视为只读。在刷新循环运行时索引被删除，数据被更新，然后索引被重新应用。这肯定是昂贵的操作，大家可以使用垂直分区来在逻辑表的一个子集中限制这些复杂动作。

    列存储索引的使用也会导致性能的降低。如果你需要操作大多数或全部列，重新连接这些行将会十分昂贵。这意味着OLTP类型的查询应该避免，而使用OLAP类型的查询。换句话说，如果你发现自己写下“select *”或一次拖回一行内容，列存储索引对你来说就不适合了。