列存储

阅读目录 1 为什么要按列存储 2补充：数据压缩 3查询执行性能 add by zhj: 终于明白了什么是列式存储，什么是行式存储。这跟数据在存储介质中的存储结构有关， 列式存储是指，一列中的数据在存储介质中是连续存储的；行式存储是指一行中的数据在存储介质 中是连续存储的。简单的说，你可以把列式数据库认为是每一列都是一个表，这个表只有一列，如 果只在该列进行条件查询，速度就很快。 那这两种不同的存储方式对数据的CRUD有什么不同的影响呢？看了一些文章， 一般说的是下面两点 1。行数据库适用于读取出少行，多列的情况；列数据库相反，适用于读取出少数列，多数行的情况。 2。列数据库可以节省空间，如果某一行的某一列没有数据，那在列存储时，就可以不存储该列的值。 这比行数据库节省空间 我个人感觉列数据库只适合对单个列进行条件查询，不适合对几个列的字段进行多条件组合查询，因 为每一列上的查询都是独立完成的，相当于每一列都是一个单独的数据库表，需要每一列的查询结果进行 join连接，join的条件是row_key相等，但每列的查询结果集可能很大。当我们对一个列的数据进行切片， 存储在不同的机器上时，一般是按主键进行排序，然后分片。额，有点乱。以HBase为例来说吧，它每一 列的数、据其实都是按row-key排序的，这样的好处是，一定范围内row-key可以放在一台机器上，当我们 用row

add by zhj: 终于明白了什么是列式存储，什么是行式存储。这跟数据在存储介质中的存储结构有关，列式存储是指，一列中的数据在存储介质中是连续存储的；行式存储是指一行中的数据在存储介质中是连续存储的。简单的说，你可以把列式数据库认为是每一列都是一个表，这个表只有一列，如果只在该列进行条件查询，速度就很快。 那这两种不同的存储方式对数据的CRUD有什么不同的影响呢？看了一些文章，一般说的是下面两点 1. 行数据库适用于读取出少行，多列的情况；列数据库相反，适用于读取出少数列，多数行的情况。 2. 列数据库可以节省空间，如果某一行的某一列没有数据，那在列存储时，就可以不存储该列的值。 这比行数据库节省空间，我个人感觉列数据库只适合对单个列进行条件查询，不适合对几个列的字段进行多条件组合查询，因为每一列上的查询都是独立完成的，相当于每一列都是一个单独的数据库表，需要每一列的查询结果进行join连接，join的条件是row_key相等，但每列的查询结果集可能很大。当我们对一个列的数据进行切片，存储在不同的机器上时，一般是按主键进行排序，然后分片。额，有点乱。以HBase为例来说吧，它每一列的数、据其实都是按row-key排序的，这样的好处是，一定范围内row-key可以放在一台机器上，当我们用row-key进行查询时，可以很快就查到数据。HBase没有二级索引

原文: 性能调优8：分组聚合 - group by 聚合实际上对数据做分组统计，SQL Server使用两种操作符来实现聚合，流聚合（Stream Aggregation）和哈希聚合（Hash aggration）。流聚合是非阻塞性的，具有流的特性，流聚合操作符；边处理数据，边输出聚合的结果。而哈希聚合是阻塞性的，只要处理完所有的数据，才会输出聚合的结果。 一，流聚合 流聚合要求输入的数据集在group by 即分组列上是有序的，也就是说，流聚合需要排序。分组列的位置和顺序不会影响聚合的结果，因此分组列的排序是任意的。对于索引上的流聚合，由于数据是已经排序的，使用流聚合算法没有排序操作的开销。 流聚合算法是：第一个被读取的数据会创建第一个分组，后续读入的数据都会先和当前的分组匹配，如果匹配，把该行放入到当前的分组中；如果不匹配，创建新的分组，直到所有数据行都处理完成为止，最终对各个分组计算聚合值。 二，哈希聚合 在执行计划中，哈希聚合使用的物理操作符是：Hash Match(Aggregate)，实际上，Hash Join也是使用Hash Match作为物理操作符。哈希聚合不需要排序，但是需要授予内存来创建Hash表。优化器倾向于使用哈希聚合来对无序的大表进行聚合操作，哈希聚合的算法： 对于每一个输入行，在group by列上计算哈希值， 检查该行是否映射到hash表中

整理了一下网上的几种Hive文件存储格式的性能与Hadoop的文件存储格式。 Hive的三种文件格式：TEXTFILE、SEQUENCEFILE、RCFILE中，TEXTFILE和SEQUENCEFILE的存储格式都是基于行存储的，RCFILE是基于行列混合的思想，先按行把数据划分成N个row group，在row group中对每个列分别进行存储。另：Hive能支持自定义格式，详情见： Hive文件存储格式 基于HDFS的行存储具备快速数据加载和动态负载的高适应能力，因为行存储保证了相同记录的所有域都在同一个集群节点。但是它不太满足快速的查询响应时间的要求，因为当查询仅仅针对所有列中的 少数几列时，它就不能跳过不需要的列，直接定位到所需列；同时在存储空间利用上，它也存在一些瓶颈，由于数据表中包含不同类型，不同数据值的列，行存储不 易获得一个较高的压缩比。RCFILE是基于SEQUENCEFILE实现的列存储格式。除了满足快速数据加载和动态负载高适应的需求外，也解决了SEQUENCEFILE的一些瓶颈。 下面对这几种几个作一个简单的介绍： TextFile： Hive默认格式，数据不做压缩，磁盘开销大，数据解析开销大。 可结合Gzip、Bzip2、Snappy等使用（系统自动检查，执行查询时自动解压），但使用这种方式，hive不会对数据进行切分，从而无法对数据进行并行操作。

我今天分享的话题是Druid驱动海量数据实时多维分析。 1、需求背景 首先我来谈一下海量实时多维分析的需求背景，我们广告系统有DSP睿视系统和AD exchange等，前段时间品友的曹老师分享时提到DSP Ad exchange,如果对DSP不了解的同学，可以在百度百科上查一下“互联网广告DSP”，实时竞价是DSP的核心，广告主或者优化师需要动态调整出价优化使收益最大化。 广告主调整出价策略或者投放策略进行优化，想要尽快得到实时的反馈，比如修改了地域定投，实时分地域的竞得率和转化率，甚至是分钟粒度的。在我们的DSP系统中我们提供12种维度(不算多)的多维分析，用户可以任意组合下钻查询。 最初的时候我并不是采用Druid，而是采用Storm+Kafka+Redis实时数据处理，以及hive+mysql的离线处理的Lambda架构架构见下图。 实时数据经过Storm ETL，主要是将不同维度组合作为key，计算metrics以后为value存在redis中。离线数据定时将昨天的数据在Hive中 经过一系列ETL，按照维度组合计算metrics以后将结果存储在mysql中。 采用redis作为实时数据的存储有两个核心问题需要解决： redis不支持range scan，我们需要在app层拼好所有的key，然后调用mget获取，如果执行groupby查询的话例如select area,pv

在这篇文章里我想小结下SQL Server 2014引入各种惊艳性能提升！！ 缓存池扩展（Buffer Pool Extensions） 缓存池扩展 的想法非常简单：把页文件存储在非常快的存储上，例如SSD硬盘，用来扩展缓存池。缓存池扩展来得非常方便，如果你不能给你的数据库服务器物理上增加更多的内存，可以考虑使用缓存池扩展。 资源调控器（Resource Governor） 资源调控器 首次是在SQL Server 2008里引入的，但那个时候还不是个成熟的技术，因为你不能在存储级别调控I/O操作，对于指定工作负荷组，你不能限制缓存池大小。在SQL Server 2014里这些都改变了，因为现在你可以压制I/O操作。限制缓冲池使用率还是不行，但谁会知道在SQL Server 2016里会怎样呢：）。 锁优先级（Lock Priorities） 或许你已经知道，在企业版本里，SQL Server提供你在线操作，或者我可以称它们为“近乎在线操作”。它们近乎是在线的，因为内部SQL Server还是要获取一些锁，这会导致阻塞情况。因此SQL Server 2014引入了 锁优先级 ，在那里如果有这样的情况发生，你可以控制SQL Server如何应对。 聚集列存储索引(Clustered Column Store Indexes) 在SQL Server 2014里引入的最热门的提升是

写入： 行存储的写入是一次完成，数据的完整性因此可以确定。 列存储需要把一行记录拆分成单列保存，写入次数明显比行存储多。 行存储在写入上占有很大的优势 数据修改： 行存储是在指定位置写入一次，列存储是将磁盘定位到多个列上分别写入。 行存储在数据修改也是占优的 数据读取： 行存储通常将一行数据完全读出，如果只需要其中几列数据，就会存在冗余列 列存储每次读取的数据是集合中的一段或者全部。 由于列储存的数据是同质的，这种情况使数据解析变得容易。行存储则复杂的多，因为在一行记录中保存了多种类型的数据，数据解析需要在多种数据类型之间频繁转换，这个操作很消耗cpu 所以列存储的解析过程中更有利于分析大数据 显而易见，两种存储格式都有各自的优缺点：行存储的写入是一次性完成，消耗的时间比列存储少，并且能够保证数据的完整性，缺点是数据读取过程中会产生冗余数据，如果只有少量数据，此影响可以忽略；数量大可能会影响到数据的处理效率。列存储在写入效率、保证数据完整性上都不如行存储，它的优势是在读取过程，不会产生冗余数据，这对数据完整性要求不高的大数据处理领域，比如互联网，犹为重要。 什么时候应该使用行式存储？什么时候应该使用列式存储呢？ 如果你大部分时间都是关注整张表的内容，而不是单独某几列，并且所关注的内容是不需要通过任何聚集运算的，那么推荐使用行式存储。原因是重构每一行数据（即解压缩过程

行存储 与 列存储 行业业务集中焦点: 有效地处理海量数据 兼顾安全, 可靠, 完整性 example: HBase采用列存储, MongoDB采用文档型的行存储, Lexst采用二进制的行存储 列存储(column-based) 传统关系型数据库行式存储(Row-based storage storestable in a sequence of rows) 列存储(Column-based storage storesatable in a sequence of columns) 行式存储下一张表的数据是放在一起的, 但列式存储下都被分开保存了。 数据写入对比 行存储的写入是一次完成。如果这种写入建立在操作系统的文件系统上, 可以保证写入过程的成功或者失败, 数据的完整性因此可以确定。 列存储由于需要把一行记录拆分成单列保存, 写入次数明显比行存储多(意味着磁头调度次数多, 而磁头调度需要时间, 一般在1ms ~ 10ms)， 再加上磁头需要在盘片上移动和定位话费的时间, 实际时间消耗会更大。所以, 行存储在写入上占有很大的优势。 数据修改实际上也是一次写入过程。区别是数据修改是对磁盘上的记录做删除标记。行存储是在指定位置写入一次, 而列存储是将磁盘定位到多个列上分别写入, 这个过程仍是行存储的列数倍, so数据修改也是行存储占优势。 数据读取对比 数据读取时,

数据库基础 你可能还没有意识到，其实自己一直在使用数据库，在电子邮件地址簿里查找名字时，在搜索网站站点上进行搜索， 都是在使用数据库 数据库 数据库这个术语的用法很多，理解数据库最简单时方法是将其想象为一个文件柜，此文件柜是一个存放数据的物理位 置，不管数据是什么以及如何组成的 数据库（database）: 保存有组织的数据的容器 表 当你将资料放入自己的文件柜时，并不是随便将它们扔进某个抽屉(数据库）中，而是在抽屉中创建文件（表），然后将相关的资料 放入特定的文件中 表（table） 某种特定类型数据的结构化清单 存储在表中的数据应该是一种类型的 数据库中的每个表都有一个名字，用来标示自己。此名字时唯一的。这表示数据库中没有其他表具有相同的名字 列 列（column）表中的一个字段，所有表都是由一个或者多个列组成的 理解列的最好办法就是将数据库表想成一个网格，网格中每一列存储着一条特定的信息 比如在顾客表中，一个列存储着顾客编号，一个列存储着着顾客姓名，地址和联系方式等其他信息都存储在各自的列中 数据类型 数据库中每个列都有相关的数据类型，数据类型定义列可以存储的数据种类 数据类型（datatype） 所容许的数据的类型，每个表列都有相应的数据类型，它限制该列存储的数据 数据类型还帮助正确的排序数据，并在优化磁盘使用方面起到重要的作用。因此，在创建表时必须对数据类型给予特别的关注

1、什么是行存储和列存储？ 　　传统的关系型数据库，如 Oracle、DB2、MySQL、SQL SERVER 等采用行式存储法(Row-based)，在基于行式存储的数据库中， 数据是按照行数据为基础逻辑存储单元进行存储的， 一行中的数据在存储介质中以连续存储形式存在。 　　列存储(Column-based)是相对于行存储来说的，新兴的 Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。在基于列式存储的数据库中， 数据是按照列为基础逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在。 2、OLTP和OLAP 　　在数据库中，数据处理可分为两类：联机事务处理OLTP（on-line transaction processing）和联机分析处理OLAP（On-Line Analytical Processing），OLTP是传统关系型数据库的主要应用，用来执行一些基本的、日常的事务处理，比如数据库增、删、改、查等等，而OLAP则是分布式数据库的主要应用，它对实时性要求不高，但处理的数据量大，通常应用于复杂的动态报表系统上。 　　OLTP和OLAP的主要区别： 3、行存储和列存储的应用场景 　　行存储的适用场景： 　　　　（1）适合随机的增、删、改、查操作； 　　　　（2）需要在行中选取所有属性的查询操作； 　　　　（3