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

上个月参加了一个云存储的技术讨论会。这一个月里,陆续收到几位同学讨论大数据保存和处理的邮件。今天是周末,索性把这个月的交流内容整理写下来,供各位参考。

目前大数据存储有两种方案可供选择:行存储和列存储。业界对两种存储方案有很多争持,集中焦点是: 谁能够更有效地处理海量数据,且兼顾安全、可靠、完整性。从目前发展情况看,关系数据库已经不适应这种巨大的存储量和计算要求,基本是淘汰出局。在已知的几种大数据处理软件中,Hadoop 的 HBase 采用列存储,MongoDB 是文档型的行存储,Lexst 是二进制型的行存储。在这里,我不讨论这些软件的技术和优缺点,只围绕机械磁盘的物理特质,分析行存储和列存储的存储特点,以及由此产生的一些问题和解决办法。

一.结构布局

行存储数据排列

列存储数据排列

表格的灰色背景部分表示行列结构,白色背景部分表示数据的物理分布,两种存储的数据都是从上至下,从左向右的排列。行是列的组合,行存储以一行记录为单位,列存储以列数据集合单位,或称列族(column family)。行存储的读写过程是一致的,都是从第一列开始,到最后一列结束。列存储的读取是列数据集中的一段或者全部数据,写入时,一行记录被拆分为多列,每一列数据追加到对应列的末尾处。

二. 对比

从上面表格可以看出,行存储的写入是一次完成。如果这种写入建立在操作系统的文件系统上,可以保证写入过程的成功或者失败,数据的完整性因此可以确定。列存储由于需要把一行记录拆分成单列保存,写入次数明显比行存储多,再加上磁头需要在盘片上移动和定位花费的时间,实际时间消耗会更大。所以,行存储在写入上占有很大的优势。

还有数据修改, 这实际也是一次写入过程。不同的是,数据修改是对磁盘上的记录做删除标记。行存储是在指定位置写入一次,列存储是将磁盘定位到多个列上分别写入,这个过程仍是行存储的列数倍。所以,数据修改也是以行存储占优。 数据读取时,行存储通常将一行数据完全读出,如果只需要其中几列数据的情况,就会存在冗余列,出于缩短处理时间的考量,消除冗余列的过程通常是在内存中进行的。列存储每次读取的数据是集合的一段或者全部,如果读取多列时,就需要移动磁头,再次定位到下一列的位置继续读取。 再谈两种存储的数据分布。由于列存储的每一列数据类型是同质的,不存在二义性问题。比如说某列数据类型为整型(int),那么它的数据集合一定是整型数据。这种情况使数据解析变得十分容易。相比之下,行存储则要复杂得多,因为在一行记录中保存了多种类型的数据,数据解析需要在多种数据类型之间频繁转换,这个操作很消耗 CPU,增加了解析的时间。所以,列存储的解析过程更有利于分析大数据。

三. 优化

显而易见,两种存储格式都有各自的优缺点:行存储的写入是一次性完成,消耗的时间比列存储少,并且能够保证数据的完整性,缺点是数据读取过程中会产生冗余数据,如果只有少量数据,此影响可以忽略;数量大可能会影响到数据的处理效率。列存储在写入效率、保证数据完整性上都不如行存储,它的优势是在读取过程,不会产生冗余数据,这对数据完整性要求不高的大数据处理领域,比如互联网,犹为重要。

改进集中在两方面:行存储读取过程中避免产生冗余数据,列存储提高读写效率。

如何改进它们的缺点,并保证优点呢?

行存储的改进:减少冗余数据首先是用户在定义数据时避免冗余列的产生;其次是优化数据存储记录结构,保证从磁盘读出的数据进入内存后,能够被快速分解,消除冗余列。要知道,目前市场上即使最低端 CPU 和内存的速度也比机械磁盘快上 100-1000 倍。如果用上高端的硬件配置,这个处理过程还要更快。

列存储的两点改进:1. 在计算机上安装多块硬盘,以多线程并行的方式读写它们。多块硬盘并行工作可以减少磁盘读写竞用,这种方式对提高处理效率优势十分明显。缺点是需要更多的硬盘,这会增加投入成本,在大规模数据处理应用中是不小的数目,运营商需要认真考虑这个问题。2. 对写过程中的数据完整性问题,可考虑在写入过程中加入类似关系数据库的“回滚”机制,当某一列发生写入失败时,此前写入的数据全部失效,同时加入散列码校验,进一步保证数据完整性。

这两种存储方案还有一个共同改进的地方:频繁的小量的数据写入对磁盘影响很大,更好的解决办法是将数据在内存中暂时保存并整理,达到一定数量后,一次性写入磁盘,这样消耗时间更少一些。目前机械磁盘的写入速度在 20M-50M/ 秒之间,能够以批量的方式写入磁盘,效果也是不错的。

四. 总结

两种存储格式各自的特性都决定了它们不可能是完美的解决方案。 如果首要考虑是数据的完整性和可靠性,那么行存储是不二选择,列存储只有在增加磁盘并改进软件设计后才能接近这样的目标。如果以保存数据为主,行存储的写入性能比列存储高很多。在需要频繁读取单列集合数据的应用中,列存储是最合适的。如果每次读取多列,两个方案可酌情选择:采用行存储时,设计中应考虑减少或避免冗余列;若采用列存储方案,为保证读写入效率,每列数据尽可能分别保存到不同的磁盘上,多个线程并行读写各自的数据,这样避免了磁盘竞用的同时也提高了处理效率。 无论选择哪种方案,将同内容数据聚凑在一起都是必须的,这是减少磁头在磁盘上的移动,提高数据读取时间的有效办法。

Reference:

https://www.infoq.cn/article/bigdata-store-choose  大数据存取的选择:行存储还是列存储

原文地址:https://www.cnblogs.com/piperck/p/10142124.html

时间: 2024-11-09 17:51:08

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

大数据为什么要选择Spark

大数据为什么要选择Spark Spark是一个基于内存计算的开源集群计算系统,目的是更快速的进行数据分析. Spark由加州伯克利大学AMP实验室Matei为主的小团队使用Scala开发开发,其核心部分的代码只有63个Scala文件,非常轻量级. Spark 提供了与 Hadoop 相似的开源集群计算环境,但基于内存和迭代优化的设计,Spark 在某些工作负载表现更优秀. 在2014上半年,Spark开源生态系统得到了大幅增长,已成为大数据领域最活跃的开源项目之一,当下已活跃在Hortonwor

湖北大数据平台企业有哪些?政企大数据平台如何选择?

2019年两会,各大代表纷纷发表对互联网大数据的建言,足以显示,大数据对于目前互联网的重要性已经国家对大数据的关注度,接下来,我们就具体聊一下湖北地区大数据平台企业有哪些?政企大数据平台软件如何选择? 2019年大家在聊到大数据,可能对它不在是以前浅显的认识,大家对大数据已经有了一定的认识.在大数据的浪潮中,大数据被认为是数据的大容量.数据类型的多样.数据的处理速度快.数据的应用高价值的有趋势预测的.海量的.高增长率的信息资产.但是又因为大数据可给人类社会带来潜在的无可估量的价值. 政企大数据平

中小企业的大数据技术路线选择(二)-Cassandra+Presto方案

中小企业的大数据技术路线选择(二)-Cassandra+Presto方案 我前面曾经写过:中小企业的大数据技术路线选择 和 低调.奢华.有内涵的敏捷式大数据方案:Flume+Cassandra+Presto+SpagoBI . 最近用了两个月的时间终于把Cassandra+Presto+SpagoBI方案验证通过了.验证了Presto的JDBC Driver .Prestogres网关.SHIB三种方式. 一.Presto JDBC驱动方案 Presto JDBC驱动方案,Java动用客户端,如

行存储 VS 列存储

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

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

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

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

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

大数据技术之_08_Hive学习_04_压缩和存储(Hive高级)+ 企业级调优(Hive优化)

第8章 压缩和存储(Hive高级)8.1 Hadoop源码编译支持Snappy压缩8.1.1 资源准备8.1.2 jar包安装8.1.3 编译源码8.2 Hadoop压缩配置8.2.1 MR支持的压缩编码8.2.2 压缩参数配置8.3 开启Map输出阶段压缩8.4 开启Reduce输出阶段压缩8.5 文件存储格式8.5.1 列式存储和行式存储8.5.2 TextFile格式8.5.3 Orc格式8.5.4 Parquet格式8.5.5 主流文件存储格式对比实验8.6 存储和压缩结合8.6.1 修

中小企业的大数据技术路线选择

目前,大数据主要应用在互联网.电商领域,电信.电力行业也在逐步使用.对广大的中小企业来说,大数据也听得太多了.然而,大数据的技术门槛还是很高的.从技术路线上来说,选择大公司使用的技术方案可能是不能承受之重. 笔者所在的公司,选择的是行业通用的Hadoop方案.历经一年之久,前后三拨人员,一个Demo版还没出来.大数据真的让人望眼欲穿啊. 对中小企业而言,要选择适合自己的大数据技术路线.跟着大公司,人云亦云,还真玩不起.那么,有没有适合中小企业的大数据方案呢?笔者用心收集了几个,供参考. 1.Ca

大数据之HDFS命令行基本操作

1. 课程简介 HDFS是Hadoop大数据平台中的分布式文件系统,为上层应用或其他大数据组件提供数据存储,如Hive,Mapreduce,Spark,HBase等. 本文章中所有命令均在CentOS-6.4-x86_64,hadoop-2.5.2,jdk1.8.0_152,zookeeper-3.4.11中运行通过,为减少linux权限对初学者造成影响,所有命令均在linux的root权限下进行操作. 2.理论回顾 Hadoop技术本身包含HDFS.Map/Reduce.HDFS作海量数据存储