sql-server – 列存储索引的解剖结构是什么？

我对常规的旧行存储索引非常了解,比如b-tree结构,叶级别和b-tree页面之间的存储差异,包含字段的影响,优化使用它们,键的顺序等等.

我很难在列存储索引的内部获得任何好的信息.

>它是如何构建的？
>有一棵b树吗？还有其他一些结构吗？
>数据如何组织？
>哪种特定的操作符最适合使用它？
>使用它们时要避免的任何其他反模式？

我能找到的关于它们的很多东西基本上与“正常”索引完全相反,即没有键的排序,没有包含的字段,仅非集群.

任何见解都表示赞赏.

解决方法

列存储数据每列物理存储在one or more segments(常规LOB分配单元)中,也可以通常的方式进行分区.每个段包含大约一百万行高度压缩的值或值引用(可以使用多种压缩技术).值引用链接到最多两个hash dictionaries之一中的条目.

在查询执行期间,字典是pinned in memory,只要执行需要实际数据值,就会在字典中查找来自该段的数据值ID(出于性能原因,该查找会尽可能长地延迟).

段还具有包含元数据的标题记录,例如段中存储的最小值和最大值.来自标头的信息通常可用于执行时处理的eliminate完整分区.标题记录信息存储在通常的LOB数据根结构中,因此消除段意味着存储引擎可以完全跳过从物理存储读取LOB数据页.最大化消除的可能性可能需要careful design,包括在构建Columnstore索引时的聚簇索引顺序上的dependency.

具体计划操作符

SQL Server 2012引入了一种称为批处理模式的新执行模式.在这种模式下,大约1000行的数据包在操作符之间传递,显着提高了处理器利用率.在每个数据包中,列数据表示为向量.并非所有计划运算符都支持批处理模式操作,但其中的示例包括列存储索引扫描,哈希内部联接,批处理哈希表构建,位图筛选,哈希聚合(不是scalar聚合),筛选和计算标量(用于投影和表达式)评价).查询执行计划已得到增强,以显示估计和实际执行模式.

反模式

第一个版本中存在大量限制,包括对允许的data types的约束.支持最常见的类型;不支持的数据类型包括精度大于18位的DECIMAL,(N)VARCHAR(MAX),UNIQUEIDENTIFIER,CLR类型和(VAR)BINARY.

使用string types,OUTER JOIN,IN,EXISTS,NOT IN,OR,UNION ALL可能会导致性能显着降低(行模式执行),除非采用通常涉及本节链接文章中所示的异常语法重写的变通方法.

更多信息

Remus Rusanu在博客上发表了很好的概述here.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!