行存储 VS 列存储

概述

目前大数据存储有两种方案可供选择:行存储(Row-Based)和列存储(Column-Based)。业界对两种存储方案有很多争持,集中焦点是:谁能够更有效地处理海量数据,且兼顾安全、可靠、完整性。从目前发展情况看,关系数据库已经不适应这种巨大的存储量和计算要求,基本是淘汰出局。在已知的几种大数据处理软件中,Hadoop的HBase采用列存储MongoDB是文档型的行存储,Lexst是二进制型的行存储。

什么是列存储?

列式存储(column-based)是相对于传统关系型数据库的行式存储(Row-basedstorage)来说的。简单来说两者的区别就是如何组织表:

Ø Row-based storage stores atable in a sequence of rows.

Ø Column-based storage storesa table in a sequence of columns.

从上图可以很清楚地看到,行式存储下一张表的数据都是放在一起的,但列式存储下都被分开保存了。所以它们就有了如下这些优缺点对比:

在数据写入上的对比

1)行存储的写入是一次完成。如果这种写入建立在操作系统的文件系统上,可以保证写入过程的成功或者失败,数据的完整性因此可以确定。

2)列存储由于需要把一行记录拆分成单列保存,写入次数明显比行存储多(意味着磁头调度次数多,而磁头调度是需要时间的,一般在1ms~10ms),再加上磁头需要在盘片上移动和定位花费的时间,实际时间消耗会更大。所以,行存储在写入上占有很大的优势。

3)还有数据修改,这实际也是一次写入过程。不同的是,数据修改是对磁盘上的记录做删除标记。行存储是在指定位置写入一次,列存储是将磁盘定位到多个列上分别写入,这个过程仍是行存储的列数倍。所以,数据修改也是以行存储占优。

在数据读取上的对比

1)数据读取时,行存储通常将一行数据完全读出,如果只需要其中几列数据的情况,就会存在冗余列,出于缩短处理时间的考量,消除冗余列的过程通常是在内存中进行的。

2)列存储每次读取的数据是集合的一段或者全部,不存在冗余性问题。

3) 两种存储的数据分布。由于列存储的每一列数据类型是同质的,不存在二义性问题。比如说某列数据类型为整型(int),那么它的数据集合一定是整型数据。这种情况使数据解析变得十分容易。相比之下,行存储则要复杂得多,因为在一行记录中保存了多种类型的数据,数据解析需要在多种数据类型之间频繁转换,这个操作很消耗CPU,增加了解析的时间。所以,列存储的解析过程更有利于分析大数据。

4)从数据的压缩以及更性能的读取来对比

优缺点

显而易见,两种存储格式都有各自的优缺点:

1)行存储的写入是一次性完成,消耗的时间比列存储少,并且能够保证数据的完整性,缺点是数据读取过程中会产生冗余数据,如果只有少量数据,此影响可以忽略;数量大可能会影响到数据的处理效率。

2)列存储在写入效率、保证数据完整性上都不如行存储,它的优势是在读取过程,不会产生冗余数据,这对数据完整性要求不高的大数据处理领域,比如互联网,犹为重要。

 

两种存储格式各自的特性都决定了它们的使用场景。

列存储的适用场景

1)一般来说,一个OLAP类型的查询可能需要访问几百万甚至几十亿个数据行,且该查询往往只关心少数几个数据列。例如,查询今年销量最高的前20个商品,这个查询只关心三个数据列:时间(date)、商品(item)以及销售量(sales amount)。商品的其他数据列,例如商品URL、商品描述、商品所属店铺,等等,对这个查询都是没有意义的。

而列式数据库只需要读取存储着"时间、商品、销量"的数据列,而行式数据库需要读取所有的数据列。因此,列式数据库大大地提高了OLAP大数据量查询的效率

OLTP OnLine Transaction Processor 在线联机事务处理系统(比如Mysql,Oracle等产品)

OLAP OnLine Analaysier Processor 在线联机分析处理系统(比如Hive Hbase等)

2)很多列式数据库还支持列族(column group,Bigtable系统中称为locality group),即将多个经常一起访问的数据列的各个值存放在一起。如果读取的数据列属于相同的列族,列式数据库可以从相同的地方一次性读取多个数据列的值,避免了多个数据列的合并。列族是一种行列混合存储模式,这种模式能够同时满足OLTP和OLAP的查询需求。

3)此外,由于同一个数据列的数据重复度很高,因此,列式数据库压缩时有很大的优势。

例如,Google Bigtable列式数据库对网页库压缩可以达到15倍以上的压缩率。另外,可以针对列式存储做专门的索引优化。比如,性别列只有两个值,"男"和"女",可以对这一列建立位图索引:

如下图所示

"男"对应的位图为100101,表示第1、4、6行值为"男"

"女"对应的位图为011010,表示第2、3、5行值为"女"

如果需要查找男性或者女性的个数,只需要统计相应的位图中1出现的次数即可。另外,建立位图索引后0和1的重复度高,可以采用专门的编码方式对其进行压缩。

当然,如果每次查询涉及的数据量较小或者大部分查询都需要整行的数据,列式数据库并不适用。

最后总结如下

传统行式数据库的特性如下:

①数据是按行存储的。

②没有索引的查询使用大量I/O。比如一般的数据库表都会建立索引,通过索引加快查询效率。

③建立索引和物化视图需要花费大量的时间和资源。

④面对查询需求,数据库必须被大量膨胀才能满足需求。

列式数据库的特性如下:

①数据按列存储,即每一列单独存放。

②数据即索引。

③只访问查询涉及的列,可以大量降低系统I/O。

④每一列由一个线程来处理,即查询的并发处理性能高。

⑤数据类型一致,数据特征相似,可以高效压缩。比如有增量压缩、前缀压缩算法都是基于列存储的类型定制的,所以可以大幅度提高压缩比,有利于存储和网络输出数据带宽的消耗。

原文地址:https://www.cnblogs.com/shuzhiwei/p/11316511.html

时间: 2024-09-30 16:23:11

行存储 VS 列存储的相关文章

如何在一个实例下并存行存储和列存储数据库

相关概念 BLU Acceleration BLU Acceleration 是 DB2 10.5 最新特性,与传统的行存储数据方式不同,数据是按照列来进行组织存储的,即采用列式存储.BLU 除了列存储表特性外,它的数据跳读,SIMD 和类哈弗曼的压缩算法等特性方便在内存中完成数据处理,简化并且加速了数据分析的工作量.同时不再需要索引.MQT 等,这样易于实施并可以自行调优,提高了 CPU 的使用率,以及降低了 IO. IBM Data Server Manager IBM 最新推出的管理多种平

【转】大数据存取的选择:行存储还是列存储?

上个月参加了一个云存储的技术讨论会.这一个月里,陆续收到几位同学讨论大数据保存和处理的邮件.今天是周末,索性把这个月的交流内容整理写下来,供各位参考. 目前大数据存储有两种方案可供选择:行存储和列存储.业界对两种存储方案有很多争持,集中焦点是: 谁能够更有效地处理海量数据,且兼顾安全.可靠.完整性.从目前发展情况看,关系数据库已经不适应这种巨大的存储量和计算要求,基本是淘汰出局.在已知的几种大数据处理软件中,Hadoop 的 HBase 采用列存储,MongoDB 是文档型的行存储,Lexst

Apache Druid 底层存储设计(列存储与全文检索)

导读:首先你将通过这篇文章了解到 Apache Druid 底层的数据存储方式.其次将知道为什么 Apache Druid 兼具数据仓库,全文检索和时间序列的特点.最后将学习到一种优雅的底层数据文件结构. 今日格言:优秀的软件,从模仿开始的原创. 了解过 Apache Druid 或之前看过本系列前期文章的同学应该都知道 Druid 兼具数据仓库,全文检索和时间序列的能力.那么为什么其可以具有这些能力,Druid 在实现这些能力时做了怎样的设计和努力? Druid 的底层数据存储方式就是其可以实

行存储和列存储

传统的行式数据库将一个个完整的数据行存储在数据页中.这种方式在大数据量查询的时候会出现以下问题 1.在没有索引的情况下,会把一行全部查出来,查询会使用大量IO 2.虽然建立索引和物化视图可以可以快速定位列,但是也需要花费大量时间 但是如果处理查询时需要用到大部分的数据列,这种方式在磁盘IO上是比较高效的. 一般来说,OLTP(Online Transaction Processing,联机事务处理)应用适合采用这种方式. 一个OLAP类型的查询可能需要访问几百万甚至几十亿个数据行,且该查询往往只

译--列存储索引1:初始列存储索引

2012以后提供了一种不同于传统B树结构的索引类型,就是内存列存储索引.这种索引应用了一种基于列的存储模式,也是一种新的查询执行的批处理模式,并且为特定的负载提供了巨大的性能提升.它是如何构建?如何工作?又是为什么能对性能有如此大的提升,接下来我们用简明的描述和详尽的示例来解释说明. 那么列存储索引究竟是什么?大多数时候,列存储索引被描述作为一种数据仓库和数据报表的功能.事实上,你最有可能就是在这种情况下利用这种索引.然而,即使在OLTP数据库中,你也会遇到一些要从大量数据表中获取数据的报表,它

几张图片来了解列存储

最近我看到了一个非常好的信息,里面的几句话伴随着几个数字就把列存储(Column-based Storage)讲清楚.牛啊! 最喜欢的就是这个很容易理解就会放亮清晰的白色背景.而不是谈论啰嗦的概念. 1 根据列存储为什么 列存储(Columnar or column-based)是相对于传统关系型数据库的行式存储(Row-basedstorage)来说的. 简单来说两者的差别就是怎样组织表(翻译不好,直接抄原文了): ?  Row-based storage stores atable in a

Oracle 12.1.0.2 New Feature翻译学习【In-Memory column store内存列存储】【原创】

翻译没有追求信达雅,不是为了学英语翻译,是为了快速了解新特性,如有语义理解错误可以指正.欢迎加微信12735770或QQ12735770探讨oracle技术问题:) In-Memory Column Store内存列存储 Starting in Oracle Database 12c Release 1 (12.1.0.2), the In-Memory Column Store (IM column store) is an optional, static SGA pool that sto

SQL Server 2014 聚集列存储

SQL Server 自2012以来引入了列存储的概念,至今2016对列存储的支持已经是非常友好了.由于我这边线上环境主要是2014,所以本文是以2014为基础的SQL Server 的列存储的介绍.下面我们主要看一下列存储的发展以及一些原理: 列存储的开发是想要处理超大量数据进行分析计算,于是在SQL Server 2012时,SQL Server 引入了列存储索引,用以显著提供高传统数据仓库类型语句的性能,并在SQL Server 2014中做了进一步加强.列存储会将一个列的数据单独存放在一

SQL Server 列存储索引强化

SQL Server 列存储索引强化 SQL Server 列存储索引强化... 1 1. 概述... 1 2.背景... 2 2.1 索引存储... 2 2.2 缓存和I/O.. 2 2.3 Batch处理方式... 2 3 聚集索引... 3 3.1 提高索引创建... 4 3.2 采样的支持... 4 3.3 BookMark的支持... 4 3.4 其他加强... 4 4 更新处理... 4 4.1 随机插入... 6 4.2 批量插入... 6 4.3 删除和更新... 6 4.4 对