我对常规的旧行存储索引非常了解,比如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可能会导致性能显着降低(行模式执行),除非采用通常涉及本节链接文章中所示的异常语法重写的变通方法.
更多信息
