为什么列存储能够大幅度提高数据的查询性能?

存储 存储软件
传统的存储数据的方式是逐行存储(Row Store),每一个Page存储多行数据,而列存储(Column Store)把数据表中的每一列单独存储在Page集合中,这意味着,Page集合中存储的是某一列的数据,而不是一行的所有列的数据。

传统的存储数据的方式是逐行存储(Row Store),每一个Page存储多行数据,而列存储(Column Store)把数据表中的每一列单独存储在Page集合中,这意味着,Page集合中存储的是某一列的数据,而不是一行的所有列的数据。

为什么列存储能够大幅度提高数据的查询性能呢?要回答这个问题,首先必须明白SQL Server引擎是怎样读取数据的。在读取数据时,SQL Server每次都把所需数据所在的整个Page读取到内存中,Page是数据读取的最小单位。如果采用行存储,每一个Page都存储所有列的数据,每行的Size决定了单个Page能够存储的数据行数量。

我们可以粗略计算一下,如果一个数据行有10列,每列的平均Size是10B,一行的Size是100B,那么单个Page最多存储80行(8060B/100B);如果采用列存储模式,那么单个Page可以存储806行(8060B/10B)。就单个Page存储的数据行数量而言,列存储是行存储的10倍,SQL Server引擎把一个Page读取到内存中,能够获取的数据行数量成10倍增加。

[[218715]]

因此,采用列存储模式时,每一个Page能够存储更多的数据行。在加载列存储数据时,SQL Server只需要消耗少量的IO,就能把某一列的全部数据加载到缓存中。当从列很多的大表中读取几个列时,相比传统的行存储(Row Store)模式,列存储(Column Store)能够成千上万倍地提高数据的读取速度和查询性能。

一,列存储的物理实现

数据表(堆,B-Tree)以行存储模式存储数据,而列存储索引以列存储模式存储数据,行存储和列存储的示例图:

1,列存储的优点

对于列存储,列C1…C6 存储在不同的Page组中,列存储的有点是:

列存储是把每一列都单独存储在Pages集合中,对于行存储,哪怕只从数据表中选择(select)一列,SQL Server引擎都把整个数据行所在的Page读取到内存中,而使用列存储索引,仅仅需要把select子句指定的列读取到内存,不需要的列不会被读取;因此,如果一个查询请求只需要从少量的几个列中获得数据,列存储能够大幅度提高查询性能;

由于单个数据列的数据冗余度更高,因此同一列的数据更容易被压缩存储,单个Page存储更多的数据;

缓存***率提高,这是因为同一列的数据被高度压缩,常用的Page被频繁访问而变得异常活跃,Buffer Manager把活跃的数据页缓存到内存中,不常用的Page被换出(Page Out)。

更高级的查询执行技术,列存储模式读取数据使用的是批处理模式(Batch Processing Mode),相对于传统的行处理技术,查询性能更高。

2,列存储模式的物理实现

SQL Server引擎分三步实现列存储:

step1,列存储索引先把数据表的所有数据行分组,每个分组也称作行组(Row Groups)。

step2,在每个行组中,每列的所有数据行构成一个列段(Column Segment),简称段。

step3,对每个段进行压缩处理和编码,每个段都单独存储在列存储索引中。

3,编码和压缩

列存储使用两种编码类型:基于字典(dictionary based)和基于值(value based),使用Vertipaq压缩数据。

字典编码是把唯一值编入字典,每一个唯一值都匹配一个序号,而序号用于索引字典,通过存储序号来压缩数据。如果数据表中存在大量的重复值,那么使用字典编码压缩率高。

值编码用于整数类型,或小数类型,编码的原理是把Value的范围按照比例缩小或增大,并使用一个指数(exponent)来表示比例。如果整数(integer) 或小数(decimal)的值分布集中,那么使用基于值(value-based)编码方法进行压缩非常高效。

列存储索引的物理存储如下图所示:

二,列存储索引

SQL Server 2012开始引入列存储模式,用户通过创建列存储索引(Column Store Index)来体验列存储模式带来的性能提升。而列存储模式非常适用于星型连接(Star- Join)类型的聚合查询,所谓星型连接(Star-Join)的聚合查询是指对一个大表(Large Table)和多个小表(Little Table)进行连接,并对Large Table 进行聚合查询。在数据库仓库中,是指事实表和维度表的连接。

在大表上创建列存储索引,SQL Server 引擎将充分使用批处理模式(Batch processing mode)来执行星型查询,获取更高的查询性能。

典型的Star- Join的聚合查询类似于下面的示例脚本:

  1. select lt.Grouping_Columns, 
  2.         AggregationFunction(bt.Columns) 
  3. from dbo.LittleTable lt with(nolock) 
  4. inner join dbo.BitTable bt with(nolock) 
  5.     on lt.Int_Col1=bt.Int_col1 
  6. where .... 
  7. group by lt.Grouping_Columns 

在SQL Server 2012中,只能创建非聚集的列存储索引,由于列存储索引的每一列都有独立的存储空间(Page Set),因此,列存储索引会包含数据表的所有列,这样,每一个数据列都会被索引到。但是,并不是每一列都能获得的相同的性能提升,这是因为,列存储使用的压缩算法对于具有大量重复值的字符或数值的数据,压缩效率更高。对于列存储索引而言,查询性能的提升很大程度上依赖列数据的高度压缩,这会大幅减少存储该列数据所占用的数据页(Data Page),进而大幅减少把数据加载到内存所耗费的内存和时间。

  1. CREATE [ NONCLUSTERED ] COLUMNSTORE INDEX index_name  
  2. ON schema_name . table_name ( column  [ ,...n ] ) 
  3. WITH ( DROP_EXISTING = { ON | OFF } | MAXDOP = max_degree_of_parallelism ) ] 
  4. ON  partition_scheme_name ( column_name )  | filegroup_name ] 

一旦表上创建了非聚集的列存储索引,基础表就变成只读的(read-only),不能对基础表做任何更新(insert,update,delete 或merge)操作,如果需要修改数据,那么,首先要禁用列存储索引,然后更新数据,***重建列存储索引:

  1. ALTER INDEX mycolumnstoreindex ON mytable DISABLE; 
  2. -- update mytable -- 
  3. ALTER INDEX mycolumnstoreindex on mytable REBUILD 

由于创建或重建列存储索引是IO密集型资源,十分耗费内存资源,因此必须在系统空闲的情况下,更新数据。 

三,列存储索引的存储空间

列存储索引首先把数据分组,然后每个行组中的每个列构成一个段(Segment),每段都是单独存储的,列存储索引占用的存储空间的大小是由所有段占用的硬盘空间的加和。

系统视图:sys.column_store_segments 提供每个段的数据信息,每个段都是每个行组中的一列的数据的集合,例如,如果一个列存储索引分为10个行组,每个行组有15个数据列,那么,该视图将返回150个段。

 View Code

可以看出,列存储索引中每个段占用的硬盘空间是很少的,加载到内存所需要耗费的时间,IO次数和内存资源也是很少的,再配上性能更高的批处理模式,所以,列存储能够大幅度提高数据的查询性能,特别是对星型聚合的查询。

  1. select i.object_id 
  2.     ,object_name(i.object_id) as object_name 
  3.     ,i.name as index_name 
  4.     ,i.type_desc as index_type 
  5.     ,col_name(i.object_id,ic.column_id) as index_column_name 
  6.     ,sum(s.row_count) as row_count 
  7.     ,sum(s.on_disk_size)/1024/1024 as on_disk_size_mb 
  8. from sys.column_store_segments s 
  9. inner join sys.partitions p  
  10.     on s.partition_id=p.partition_id 
  11. inner join sys.indexes i  
  12.     on p.object_id=i.object_id 
  13.         and p.index_id=i.index_id 
  14. inner join sys.index_columns ic  
  15.     on i.object_id=ic.object_id 
  16.         and i.index_id=ic.index_id 
  17.         and s.column_id=ic.index_column_id 
  18. group by i.object_id 
  19.     ,i.index_id 
  20.     ,i.name 
  21.     ,i.type_desc 
  22.     ,ic.column_id 
  23. order by i.object_id 
  24.     ,i.name 
  25.     ,index_column_name 
责任编辑:武晓燕 来源: 博客园
相关推荐

2009-05-11 14:19:55

Oracle性能优化数据库

2015-11-16 11:31:35

Kubernetes网络性能新版本特性

2013-11-13 15:22:16

架构系统架构

2020-12-21 12:50:48

RPA数字化AI

2011-05-27 06:58:13

LifeSize碳排放

2022-07-13 15:41:13

代码检查审查员开发

2020-11-27 06:58:24

索引

2012-07-06 09:00:34

MySQL

2009-08-14 10:14:23

H.264编码器数字视频编码标准PowerSmart

2024-04-30 10:04:14

目标检测AI

2021-08-06 08:52:17

数字化

2018-11-13 14:15:33

数据库OracleMySQL

2017-11-12 20:25:40

FacebookAndroid程序员

2018-02-08 10:47:19

存储技术列存储

2022-07-01 15:46:20

网络安全数字化智能制造

2013-05-20 15:33:35

锐捷网络万兆接入万兆以太网

2012-03-22 15:15:49

云计算微软Windows 8

2021-05-31 07:37:48

Windows10操作系统微软

2019-03-20 11:16:10

CIO安全项目
点赞
收藏

51CTO技术栈公众号