提高I / O效率Hadoop-Based大规模数据分析程序

文摘

Apache Hadoop是一个受欢迎的时代大数据的并行处理工具。虽然从业者改写许多传统分析算法让他们定制的Hadoop,低效的I / O问题Hadoop-based项目一再在文献中报道。在本文中,我们解决问题的I / O效率低下Hadoop-based大规模数据分析通过引入我们的Hadoop的有效修改。我们首先把一个柱状的数据布局与传统的Hadoop框架,没有任何修改的Hadoop内部。我们还提供Hadoop与索引能够节省大量的I / O处理不仅选择时星形联结查询谓词也经常使用在许多分析任务。

1。介绍

数据量在科学领域得到前所未有飞涨,和新来源和类型的信息正在激增。我们见证的速率数据生成的更快,而生成的数据量是非常大的。Apache Hadoop (1),谷歌的一个开源实现MapReduce (2),是一个著名的数据处理工具,处理海量数据和无共享架构在一个平行的和有效的方式。因此,它被广泛认为是一个有效的工具,大规模数据分析大数据的时代。许多数据分析和挖掘算法运行在Hadoop已经重写了。MapReduce,引起了不小的关注表现出明显的I / O效率之间的权衡和容错3]。Pavlo解决Hadoop MapReduce是2至50倍低于传统的并行数据库系统除了数据加载的情况下(4]。安德森和Tucek还指出,Hadoop非常可伸缩但每个节点实现效率很低,不超过5 MB每秒处理速度(5]。社区从而获得高效的I / O,特别是通过建立新的框架在Hadoop (6- - - - - -10]。

在同一条线上,这手稿地址MapReduce-based程序中I / O效率低下的问题。具体来说,我们关注的是提高I / O效率使用Apache Hadoop在大规模数据分析。至关重要的是消除I / O瓶颈Hadoop-based程序,考虑Hadoop在许多科学领域的广泛使用。

在这方面,我们建议ColBit,位图索引和一个有效的组合柱状数据布局数据块存储在Hadoop分布式文件系统,又名HDFS。ColBit显著提高性能Hadoop-based项目通过减少大量的I / O在处理数据分析任务。它是通过分析期间(我)跳过不必要的数据读取和(2)减少整体中间数据的大小尺寸通过大多数的替换与压缩bitvectors中间结果。在加载时间,ColBit自动转换数据块复制到相应的柱状布局。因此,用户不需要知道细节内部数据布局。布局转换和index-building任务执行加载时间所以没有开销强加在处理数据分析任务。此外,Hadoop内部没有必要的修改我们的方法。此外,位图索引方便的处理不仅选择谓词星形联结查询,而且还广泛应用于数据仓库中,在Hadoop。此外,位图索引帮助拯救大量I / O和压缩bitvectors。最后,我们加入技术装备的位图索引只允许我们使用bitvectors加入关系。本文的其余部分组织如下。下一节讨论了现有文献的丰富的身体与我们的工作相关。反过来,我们提出一个新颖的柱状布局利用位图索引。 Next, we elaborate on query processing using the proposed bitmap indexes (ColBit), which are then evaluated by a microbenchmark test. Finally, Section6结束我们的讨论总结我们的贡献。

Hadoop MapReduce是一个开源框架,它支持MapReduce编程模型引入了谷歌(2]。这个模型的主要思想是隐藏并行执行的细节,以允许用户只关注他们的数据处理任务。MapReduce模型由两个基本功能:Map ()和Reduce ()。输入一个MapReduce工作列表(关键1,价值1)对,Map ()函数应用于每一对,然后中间键值对计算结果。中间键值然后key-equality基础组合在一起,即。,(关键2,list_of_value2)。关键2,Reduce ()功能适用于所有值的列表,然后产生零个或多个聚合的结果。用户可以定义Map ()和Reduce ()功能。每个处理在Hadoop的工作被分解为许多地图任务作为输入数据块和一个或多个减少任务。Hadoop MapReduce也利用HDFS作为底层存储层(11]。HDFS是对支持容错数据分区和文件系统块复制,由一个或两个主节点。

一些方法提高I / O性能MapReduce-based项目。读者被称为最近的一项调查(MapReduce及其改进3]。骆驼有一个柱状布局叫什么用帮助连接处理(12]。这个想法是输入数据分区和排序的基础上选定的列和列存储在HDFS。然而,由于HDFS随机决定了块放置在运行时,相关的列值在一个行不得坐落在一个节点。柱状记录文件(RCFile)[13)由Facebook和用于Apache蜂巢和猪的项目,而选择另一种方法类似于罗马帝国布局(4]。一个单一的RCFile由一组行组,通过水平分区的关系,然后,值的枚举和存储列在每一行组。的弱点RCFile数据放置在HDFS是由主节点在运行时决定。因此,在相同的记录不能保证所有相关字段保存在同一个节点如果每一列在HDFS被保存在一个单独的文件。CoHadoop(14)也被设计在一个节点定位相关文件。为了达到这个目标,CoHadoop扩展HDFS文件级属性,和文件标有相同的定位器放在同一组从节点。Floratou等人还提出一个二进制用于存储格式存储大量文件中每一列(10]。Floratou的工作和RCFile利用一群列数据压缩在一行。Hadoop本身也提供了数据压缩映射输出提高I / O效率而检查点中间结果(1]。

蜂巢(6)是一个开源项目,旨在提供一个数据仓库解决方案在Hadoop框架。它支持临时查询sql的查询语言。蜂巢评估它的sql查询查询编译到一个有向无环图,由多个MapReduce工作。蜂巢还维护提供模式的系统编目信息和数据统计,类似于其他关系数据库系统。蜂巢目前适应RCFile [13)和Apache兽人的格式,这是一个改进版本的RCFile功能块组,作为其强制性的存储类型。HBase [7)是一个开源的Java实现Google的Bigtable [8]。HBase是一个商店,宽栏映射两个任意字符串值(行键和列键)和时间戳进一个相关的任意字节数组,HDFS上工作。数据压缩特性,使用布隆过滤器检查数据的存在,和一个日志结构存储。HBase不是一个关系数据库,而已知稀疏分布式multisorted地图哪个更有效治疗稀疏数据,如web地址。

3所示。柱状布局配备位图索引

3.1。柱状存储布局HDFS

在最初的HDFS中,逻辑文件是物理上分割成大小相同的块,然后,一点逻辑文件列举行操作中的值在每个物理块在本地文件系统中。一点虽然这行操作数据布局提供快速数据加载,它包括两个主要的问题在数据分析的任务10,15]。一点首先,行操作数据布局需要读不必要的列即使只有几列在访问一个关系查询处理。第二,MapReduce本身会导致很多I / o,因为它只是提供不必要的列到下一个阶段,即:,reduce tasks and the next MapReduce job, checkpointing every tuple with unnecessary column values into disks or HDFS at each stage.

灵感来自于柱状存储模型在读取最优化数据库系统16)和位图索引技术(17),我们设计对HDFS数据布局配备位图索引。关系加载时,首先我们的系统分区每个关系分成多个组,每组基列值的大小是一样的HDFS块大小。换句话说,每组每个数据块的大小不超过物理块大小,即。,基本上64 MB。这使得其他列有大致相同的块大小。然后每组分区列,每列存储在一个单独的二进制文件。每组中的所有列被存储为二进制文件,可以选择在ZLIB压缩18与组相关联的子目录中)。图1说明一个关系是分区和列存储在HDFS上的方法。

在图中,关系T1加载在我们的系统,然后每一列,例如,C₁∼C₅在T1,基本上是作为一个数据块存储在HDFS。因此,处理一个解析查询将只有几列,ColBit不需要读不必要的列。

此外,我们允许用户组多个列成一个单一的块来获得更多的查询处理I / O效率。

假设一个给定的分析查询Q1需要投影在T1这几列,例如,C1, C2, C3, C5加入键列。然后,我们的系统允许用户构建只有两个街区的四列值:三个列值,即:,C1, C2, C3,一点都存储在一个块行操作和C5列值存储在另一个块。因此,MapReduce工作读取一个单块列值的选择。这使我们能够跳过晚一点物质化显示行操作的结果列存储(10,15]。

一个问题在我们的方法是构成一行的列值可能不是在单个节点物理位置。这导致很多I / o,因为它是必要的查询处理期间通过网络来访问它们。原因是Hadoop的原始块放置政策并不能保证相关块的主机托管,因为它决定了块放置在运行时没有语义相关的街区。RCFile(11)是罗马帝国的布局(14为了避免这个问题。RCFile,关系是第一分区为一组行组,每个HDFS块充斥着这些行组,列在每个存储的值。因为所有相关列驻留在一行集团,它避免了主机托管问题,同时提供一个柱状布局。然而,它仍然遭受不必要的数据读取,因为所有列都位于一个单独的块。我们不是解决这个问题提供了一个新的块安置政策,允许在HDFS Hadoop 0.21.0发布以来[2]。新块放置策略、阻塞位置与其他在同一组物理节点。

3.2。位图索引HDFS

虽然转换数据布局,也允许用户为每一组选定的列上建立索引。ColBit提供了一个位图索引,它被认为是比传统的B +树索引分析工作负载(17]。位图索引是bitvectors的集合,由只有0和1。位图索引的bitvectors域对应于不同的值在一定价值。1在一个bitvector识别bitvector所代表的元组的关系。几位图索引编码方案可用于确定如何1位置映射到不同的价值观在价值领域。例如,平等编码方案将每个1位置映射到一个元组的位置,其中包含一个列值由bitvector表示。不久,一个位图索引的bitvectors数量的基数是一样的列索引是建立在。另一方面,在范围和间隔编码方案中,一个不仅bitvector代表一个不同的值还多列值。读者被称为陈的工作(19,20.)了解各种编码方案用于建立位图索引。在我们的系统中,用户可以选择自己的编码方案,更好地支持各种查询类型。例如,用户可以选择范围编码方案,而不是平等有效地处理范围选择查询的编码方案。目前,ColBit提供了三个主要的编码方案包括平等、范围、和区间编码。

为了进一步提高I / O效率,ColBit压缩bitvectors使用行程长度编码计划,“运行”代表一个连续相同的比特序列,即0或1。我们还利用哇(字之间对齐混合)压缩方案(17]位分组到压缩和未压缩的词汇。执行逐位操作的主要利润是非常有效地受益于在词实际上是执行逐位操作单元在一个计算机系统。此外,ColBit还设计了方便查询处理通过执行逐位操作压缩bitvectors没有减压。

图2提出如何bitvector 8000比特压缩成4个32位字的一个系统。每个单词的第一个表示这个词是否压缩。如果第一位是1,这个词是压缩的位值,第二位序列称为填补一些代表。举个例子,在图中,第二个词是压缩代表256人31 0。第四个词让其余部分,存储最后几位,不能一个字。

快速获取元组的位置从bitvector代表某种独特的价值,我们建立一个虚拟光标能够运行压缩bitvectors计算下一个1的立场没有减压。这个虚拟光标包含三个值:(1)这个词的位置W一个虚拟光标C目前位于,(2)内一点的位置吗W那C位于,(3)钻头的位置在其余的单词如果C位于这个词。

例1。假设一个虚拟光标当前C表示第一个单词的最后一点一点矢量图的底部2,那么当前光标显示31元组在一定关系。如果我们找到下一个1的位置来获取一个元组,它包含bitvector代表的价值,它从第一位开始第二个词压缩。这个词充满了0自填在这个词表示0。我们因此简单地跳过下1计数的位置一点一点地简单地移动光标Crun_length0没有减压。因此,下一个元组,我们必须拿7998 (31 + 25631 + 31)元组。
我们还利用B +树索引(21)有效地获取有关bitvectors某些值选择查询。注意压缩bitvectors存储为每个块组作为一个单独的文件,还连同相应的数据块位于块组I / O效率。

4所示。查询处理ColBit

在我们的系统中,MapReduce工作是广泛利用开发的ColBit在海量数据处理分析查询为更好的提高I / O效率。值得注意的是我们的方法并不局限于处理关系数据也处理其他数据模型包括图表如RDF数据集也需要选择和连接查询。自MapReduce编程模型没有任何依赖数据模型和模式,这是被广泛接受的文学MapReduce编程模型可以处理不规则或非结构化数据比他们更容易与DBMS (3]。

图3说明了两个流行的查询执行计划的关系数据分析:选择和明星- - - - - -连接查询。

(一)

(b)

在MapReduce的模型中,选择谓词通常由映射器,和异径接头组映射输出使用一对表名和列名。ColBit便于选择使用两个柱状数据查询处理布局和位图索引,如图3(一个)。为了达到这个目标,我们扩展原始输入格式类Hadoop框架。我们的输入格式类第一选择位图索引建立在选定的列,然后读取只有柱状文件与所选的列。阅读时的值列文件,我们的输入格式类只输出值的行所示位置的值被设置为1。是不必要的列值不读,我们节省许多在查询处理I / o。注意,我们遵循实体化后期政策(15]这元组重建被延迟减少阶段。

MapReduce是最初设计过程一个大型输入,连接处理对Hadoop的挑战。Blanas等人相比,各种连接技术设计为运行Hadoop MapReduce (22]。重新分配加入是Hadoop MapReduce(最一般的连接技术4,22]。在重新分配连接,每个映射器附加一个标签作为每一行的键值,以确定哪些行来自关系。行具有相同键值然后转移到减速器在洗牌阶段。最后,每个减速器连接行key-equality基础上。然而,再分配加入星形联结查询也不支持。这个断言背后的基本原理是一个星形联结查询通常是由多个执行二进制连接在一个事实表和多个维度表。因此,多个MapReduce工作通常需要执行多个二进制连接在Hadoop [4,22]。此外,许多I / Os消耗数据传输到下一个阶段,即:,reduce tasks or the next MapReduce jobs, while process join operations since the philosophy of MapReduce is to sacrifice I/O efficiency for guaranteeing fault tolerance by utilizing frequent checkpointing and block-level data replication.

与ColBit我们最初的想法是通过提供压缩来节省很多I / o数据结构,而不是数据本身,到下一个阶段。我们进一步发展,整体提高Hadoop的星形联结查询处理。星形联结查询通常限制一组事实表中的元组使用选择一个或多个维度表上的谓词,然后执行一些聚合在受限制的事实表,经常分组的其他维度表元组的属性。因此,应该执行连接操作事实表和维度表之间的选择谓词和每个group-by-aggregation。示例2的示例查询是找到客户的总收入在亚洲购买亚洲供应商提供的产品在1992年到1998年之间,和总收入必须由每个国家分组和事务。

例2。一个示例星形联结查询从星型模式基准23]。选择c的国家,美国的国家,d,总和(lo.revenue)收入从客户和c, lineorder lo,供应商的年代,dwdate作为d瞧。custkey = c.custkey和罗。suppkey = s.suppkey和lo.lo。orderdate = d datekey和c。地区= "亚洲"和s。地区= "亚洲"d≥1992年和d≤1998年GROUP BY c的国家,美国的国家,dORDER BY d . asc,收入desc;我们适应看不见的加入技术,最初设计用于数据库,减少访问的数据量的顺序从维度表15]。与传统的连接技术,无形的加入是一个变种的物化末加入关注最小化所需的值中提取出故障了。因此,重写在事实表的连接操作列,以便连接时可以执行其他选择谓词评估事实表。选择谓词计算通过使用哈希表查找等其他数据结构。我们定制的无形的加入技术以适应MapReduce模型ColBit位图索引。图3 (b)说明了我们的连接技术实现与两个Hadoop MapReduce工作。
在第一个MapReduce作业,我们扩展InputFormat类应用每个选择谓词为选择维度表键值满足谓词的维度表。InputFormat类然后返回一个Java HashMap对象用于检查哪些键值满足谓词。在映射阶段,每个映射器使用哈希映射寻找事实表的元组满足选择谓词。这是由查找值的哈希表事实表的外键列。然后创建一个bitvector 1的位置代表元组的外键列满足谓词的选择。Bitvectors从所有映射器然后传输和分组行组织最后合并成一个单一的bitvector bitwise-AND运营商降低阶段。一个合并bitvector代表所有元组满足谓词的位置在事实表。注意,当事实表列在映射阶段阅读,只读有关列直接映射器从柱状文件存储在HDFS。在第二MapReduce工作,我们使用合并bitvector实际加入的过程。每个事实表映射器读取行,列和提取外键值对应的比特在哪里bitvector设置为1。 The foreign key values are then used to extract column values from the dimension tables. In the second MapReduce join, grouping and aggregations are applied to the selected and joined results that came from the first MapReduce job. Based on the observation that a MapReduce job simply works like a group-by-aggregation query in database systems, it is reasonable that grouping and aggregating are assigned to a separated MapReduce job. Note that the second MapReduce job is omitted in Figure3由于空间限制。
总结了我们的方法的主要贡献如下:首先,作为中间结果作为压缩bitvectors交付,我们可以节省大量的I / O。第二,通过对压缩bitvectors逐位操作,我们可以很容易地计算多个选择谓词。最后,当涉及到处理星形联结查询,不超过二MapReduce工作充分的在我们的方法更MapReduce工作需要其他连接技术。注意(或召回)单个MapReduce工作实现了每个连接操作。

5。实验研究

我们执行我们的微基准测试9-node集群,其中每个节点配备英特尔i7 - 6700 3.4 GHz处理器,16 GB的内存和7200 RPM SATA3 HDD, CentOS 7.5上运行。所有节点通过千兆交换中心连接。我们使用了tpc - h基准测试数据集的一个子集(24)和三个查询(Q1和Q6选择查询,和第三季度星形联结查询),如表所示1。我们比较我们的方法与原HDFS数据布局,RCFile [13),和兽人25]。此外,我们将我们的方法与Hadoop的改进,即。2.3.3蜂巢,Apache版本。,which currently accepts RCFile and ORC as its storage types [25]。


表名	数据大小	表中的行号

客户	年代∗24 MB	150000年代∗
订单	∗171 MB	1500000年代∗
Lineitem	∗759 MB	6001215年代∗

比例因子。

所有程序都是使用JDK 8和Hadoop 2.7版本实现。图4显示了加载的运行时间tpc - h的数据集。在所有情况下,所有的数据布局方案扩展线性输入数据的数量的增加。其中,Hadoop一点的行操作布局(顺序文件)的数据显示,最好的加载时间。这是因为它不需要任何布局转变。所有列的数据布局表现出加载时间相对较长。兽人显示最糟糕的加载时间RCFile紧随其后。列中数据布局,ColBit表现出最好的性能,无论bitvector编码方案应用于位图索引。具体地说,ColBit与位图索引了稍微增加一个额外的位图索引。然而,快速查询处理时间可以弥补加载时间的边际损失。

图5显示的大小tpc - h的数据读取在映射阶段Q1和Q6。ColBit大大减少数据读取使用映射器的大小。具体地说,ColBit与位图索引显示最小的数据读取进一步跳过许多不必要的值在查询处理。RCFile和兽人记录第二和第三最佳性能的尺寸数据读取。一点的行操作布局标签“原始”记录的所有数据以来最糟糕的表现应该可以理解阅读使用Hadoop的批处理。

多少I / O总体性能的影响,我们测量时间的tpc - h查询。这些查询选择照顾公平的比较。请注意,Apache蜂巢可以利用查询处理的两个柱状布局:RCFile和兽人。因此,我们配置Apache蜂巢和两个柱状布局和测量每一个布局的性能。同时,注意,MapReduce工作可以使用Apache蜂巢的柱状布局没有任何帮助。所以,我们检查了柱状布局可能会影响性能的MapReduce工作。

图6给两个选择查询的执行时间。再一次,ColBit优于其他方法的两个数量级,显著降低I / O数据阅读。值得注意的是I / O效率和查询处理时间被RCFile改进。PAX-similar布局的原因是,不必要的列行集团仍读在RCFile查询处理如前所述2。Apache蜂巢,利用RCFile和兽人存储格式也表现出更好的性能比原来Hadoop MapReduce工作的输入RCFile或者兽人。这是因为一个最新的版本的Apache蜂巢选择查询处理的性能比(i)删除不必要的阶段和(2)采用矢量化地图查询执行模式25]。

最后,图7介绍了基于MapReduce星形联结查询性能的分析。作为ColBit减少了许多数据读取bitvectors和柱状数据布局,我们目睹了一个显著的性能改进的查询执行时间。星形联结查询,这也是值得注意的,Apache蜂巢甚至并没有显示出更好的性能相比原Hadoop MapReduce工作,利用无形的加入,其输入是RCFile或者兽人。原因是Apache蜂巢的查询计划构建一个多个MapReduce对于一个给定的用户编写的HiveQL声明,蜂巢的查询计划构建一个MapReduce工作对于每个二进制连接操作符。但是我们的解决方案可以完成星形联结查询只有两个MapReduce工作涉及这种性能差距。

6。结论

我们解决I / O效率低下的问题与柱状Hadoop-based数据分析本文数据布局和压缩位图索引。实验结果展示,我们的方法优于Hadoop-based程序和Apache利用RCFile和兽人的蜂巢,Hadoop的最近的柱状数据布局。此外,我们的技术不需要任何修改Hadoop内部。

因此,任何Hadoop版本可以合并与我们的技术没有努力。未来的工作,给定一组查询,我们打算找到一个有效的方法来选择指数类型和组列成几列组,自动I / O效率最大化和最小化tuple重建的机会。

数据可用性

TPC - h基准决策支持数据集被用来执行我们的实验是由TPC(事务处理性能委员会)http://tpc.org/tpch。源代码用于我们的实验也可交付的要求。

的利益冲突

作者宣称没有利益冲突。

确认

这项工作是由韩国科学技术信息研究所、韩国(批准号K-18-L11-C03和K-18-L15-C02-S18)。这项工作也支持基础科学研究项目通过韩国国家研究基金会(NRF)由教育部(NRF - 2018 r1a6a1a03025109)。

引用

Apache Hadoop,“Apache Hadoop项目”,2010年12月,http://hadoop.apache.org。视图:谷歌学术搜索
j·迪恩和美国格玛沃特,“MapReduce:简化数据处理大型集群,”ACM的通信,51卷,不。1,第113 - 107页,2008。视图:出版商的网站|谷歌学术搜索
Y.-J k . Lee。李,崔h . y . d .钟,b .月亮,“与MapReduce并行数据处理:一项调查,”ACM SIGMOD记录,40卷,不。4、11日至20日,2012页。视图:出版商的网站|谷歌学术搜索
A . Pavlo“大规模数据分析方法的比较,”SIGMOD研讨会论文集普罗维登斯,页165 - 178年,RI,美国,2009年6月。视图:谷歌学术搜索
e·安德森和j . Tucek“效率很重要!”ACM SIGOPS操作系统复习,44卷,不。1,降价,2010页。视图:出版商的网站|谷歌学术搜索
a . Thusoo j . s . Sarma n . Jain et al .,“蜂巢:仓库解决方案通过使用映射-规约模式框架中,“诉讼VLDB养老,卷2,不。2、1626 - 1629年,2009页。视图:出版商的网站|谷歌学术搜索
l·乔治,HBase:明确的指南:随机存取你的行星大小的数据O ' reilly Media Inc .,塞瓦斯托波尔,CA,美国,2011年。
f . Chang j·迪恩,美国格玛沃特et al .,“Bigtable:结构化数据的分布式存储系统,”ACM交易计算机系统(toc),26卷,不。2,1-26,2008页。视图:出版商的网站|谷歌学术搜索
m . Zaharia m·j·富兰克林,a Ghodsi et al .,“Apache火花:统一对大数据处理引擎,”通信的ACM (CACM)卷,59号11日,56 - 65,2016页。视图:出版商的网站|谷歌学术搜索
a . Floratou美国f . Minhas, f . Ozcan”SQL-on-Hadoop:完整的循环回到无共享数据库架构,”诉讼VLDB养老,7卷,不。12日,第1306 - 1295页,2014年。视图:出版商的网站|谷歌学术搜索
k . Shvachko”Hadoop分布式文件系统”IEEE学报》研讨会上大规模存储系统和技术(MSST)太浩湖,页1 - 10,NV,美国,2010年5月。视图:谷歌学术搜索
y, d . Agrawal c . Chen公元前Ooi和吴,“骆驼:利用柱状存储可伸缩连接处理”学报ACM SIGMOD会议,页961 - 972年,雅典,希腊,2011年6月。视图:谷歌学术搜索
y y, r . Lee淮河et al .,“RCFile:快速高效和空间数据位置结构mapreduce-based仓库系统”学报》27日IEEE ICDE会议,页1199 - 1208,汉诺威,德国,2011年4月。视图:谷歌学术搜索
m . y . Eltabakh y, f . Ozcan r . Gemulla a . Krettek和j·麦克弗森,“CoHadoop:灵活的数据放置和Hadoop的剥削,”美国养老,4卷,不。9日,第585 - 575页,2011年。视图:出版商的网站|谷歌学术搜索
d . j . Abadi s r·马登和n·赫克曼于柱形储存与row-stores:他们真的有多不同?“在学报ACM SIGMOD Data-SIGMOD 08年国际会议管理温哥华,页967 - 980年,公元前,加拿大,2008年5月。视图:谷歌学术搜索
s . Harizopoulos诉梁,d . j . Abadi和s·马登,“读——优化数据库性能的权衡”,VLDB研讨会论文集,页487 - 498,首尔,韩国,2006年9月。视图:谷歌学术搜索
e . j . k . Wu Otoo, a . Shoshani“优化和高效的压缩位图索引,”ACM事务在数据库系统没有,卷。31日。1,1-39,2006页。视图:出版商的网站|谷歌学术搜索
Deutsch和J.-L页。盖尔:“ZLIB压缩数据格式规范3.3版本,“互联网工程任务组,弗里蒙特,CA,美国,1996年,没有。RFC 1950。视图:谷歌学术搜索
c . y . Chan和y . e .埃尼迪斯”,一个有效的位图选择查询的编码方案,”学报1999年ACM SIGMOD Data-SIGMOD 99国际会议管理,页215 - 226年,费城,宾夕法尼亚州,美国,1999年6月。视图:谷歌学术搜索
c . y . Chan和y . e .埃尼迪斯”,位图索引设计和评估。”ACM SIGMOD记录,27卷,不。2、355 - 366年,1998页。视图:出版商的网站|谷歌学术搜索
d .来者“无处不在的b -树”,ACM计算调查,11卷,不。2、121 - 137年,1979页。视图:出版商的网站|谷歌学术搜索
s . Blanas j·m·帕特尔诉Ercegovac j . Rao e . j . Shekita y .田,“加入算法的比较在MapReduce日志处理,”学报ACM SIGMOD会议印第安纳波利斯,页975 - 986年,2010年6月,美国。视图:谷歌学术搜索
p·奥尼尔,奥尼尔大肠,x,和s . Revilak“星型模式基准和增强事实表索引”绩效评估和基准测试技术会议施普林格,柏林,德国,2009年。视图:谷歌学术搜索
事务处理性能委员会“tpc - h基准测试规范,”2008年4月,http://www.tpc.org/hspec.html。视图:谷歌学术搜索
张x, y淮河a Chauhan et al .,“在Apache蜂巢,主要的技术进步”学报ACM SIGMOD会议雪鸟,页1235 - 1246年,但是,美国,2014年6月。视图:谷歌学术搜索