Chapter 4. Evaluation and Analysis
42
4.4 Multi-Way Joins
Similar experiments were run for the multi-way joins as well. The experiments were
run for 3 datasets at a time. The deductions can easily be extrapolated for higher
number of input datasets.
Please note that unless otherwisespecified, Reduce-Side CascadeJoin includes the
optimizations explained in section 3.3.3.
4.4.1 Experiment 4 : Performance of multi-way joins on increasing
input data size
Like experiment 1 (section 4.3.1, this experiment involves running the multi-way algo-
rithms discussed in section 3.3 on increasing sizes of input datasets. The experiment
was run with three datasets of the same size, all of which had the following character-
istics -
 Same number of tuples
 Same key space
 #keys =
1
10
#tuples
Figure 4.5 and figure 4.6 show the results of the experiment. Figure 4.5 shows the
results when the experiment was conducted with datasets that had uniform key distri-
bution. Figure 4.6 shows the results when two of the input datasets had a skewed key
distribution and the third one had a uniform key distribution. Skewed datasets, as in
experiment 1 (section 4.3.1) had one of the keys occurring in half of the tuples in the
datasets. The keys exhibiting the skew were randomly chosen for each dataset. Opti-
mization involving output cardinality of thejoins(mentioned forReduce-SideCascade
Join in section 3.3.3)were not tested with uniform input since the output cardinality of
both the smaller joinswould bethesameand cannotbe exploited in this case. Theopti-
mizations were tested for skewed input and as expected, showed improvement against
test-runs with no optimization.
The graphs show that the Reduce-Side One-Shot Join algorithm and Map-Side Join
algorithm gave performances that were very close to each other relative to the times
taken by Reduce-Side Cascade Join algorithm. Though this may lead one to think
that Reduce-Side Cascade Join algorithm is a bad choice for joining datasets, this in
Pdf to multi page tiff - SDK control project:C# PDF Convert to Tiff SDK: Convert PDF to tiff images in C#.net, ASP.NET MVC, Ajax, WinForms, WPF
Online C# Tutorial for How to Convert PDF File to Tiff Image File
www.rasteredge.com
Pdf to multi page tiff - SDK control project:VB.NET PDF Convert to Tiff SDK: Convert PDF to tiff images in vb.net, ASP.NET MVC, Ajax, WinForms, WPF
Free VB.NET Guide to Render and Convert PDF Document to TIFF
www.rasteredge.com
Chapter 4. Evaluation and Analysis
43
fact is not true. If you notice, the largest size of the datasets used for this experiment
contained 2,500,000 tuples. The choice was intentional since Reduce-Side One-Shot
Join failed to complete most of the times when used with datasets of higher sizes
and hence we could not compare the times when datasets having more than 2,500,000
tuples were used. Though we do not claim that this will be the case when clusters of
higher sizes are used, this certainly was the case with our cluster of 8 machines. The
system gave OutOfMemory exceptions a number of times for Reduce-Side One-Shot
Join algorithm when used with datasets that contained more than 2.5 million tuples
each. In contrast, the Reduce-Side Cascade Join algorithm was able to handle dataset
with each of themcontaining 5 million rows, albeit it took avery long timeto complete
(one of the test-runs took 9427 seconds, which is over 2 and half hours)
Figure 4.5: Experiment 4 : Uniform Key Distribution
Tables 4.7 and 4.8 show the actual values that were recorded to construct graphs in
Figures 4.5 and 4.6. Even here, likein earlier experiments, wecan notice that theData
Shuffle ratio remains close to 1.14. This means that with increasing data, Hadoop is
able to achieve better data locality. Table 4.6 also shows the times for test-runs when
no optimization involving output-cardinality was used for Reduce-Side Cascade Join.
SDK control project:C# TIFF: C# Code for Multi-page TIFF Processing Using RasterEdge .
com aims at developing professional multi-page Tiff processing SDK adding & deleting Tiff file page, merging and commonly used file formats, like PDF, Bmp, Jpeg
www.rasteredge.com
SDK control project:VB.NET Image: Multi-page TIFF Editor SDK; Process TIFF in VB.NET
VB.NET Imaging - Multi-page TIFF Processing in VB. VB.NET TIFF Editor SDK to Process Multi-page TIFF Document Image. Visual C#. VB.NET.
www.rasteredge.com
Chapter 4. Evaluation and Analysis
44
Figure 4.6: Experiment 4 : Skewed Key Distribution
Tuples(x100000)
Reduce-Side
One-ShotJoin
Data Shuffle Ra-
tio
Map-Side Join
Reduce-Side
Cascade Join
1
71s
1.150
59s
194s
2.5
174s
1.148
124s
425s
5
324s
1.147
254s
834s
7.5
437s
1.147
380s
1247s
10
585s
1.147
500s
1612s
25
1354s
1.144
1300s
4076s
Table 4.7: Experiment 4 : Uniform Key Distribution
Tuples(x100000)
Reduce-Side
One-Shot Join
Data Shuffle Ra-
tio
Map-SideJoin
Reduce-Side
CascadeJoin
Reduce-Side
Cascade
Join
(No-Opt)
1
106
1.150
62
289
325
2.5
216
1.148
228
852
910
5
477
1.147
449
1755
1814
7.5
700
1.147
627
1933
2024
10
891
1.147
822
2853
3013
25
2158
1.144
2111
6319
6604
Table 4.8: Experiment 4 : Skewed Key Distribution
SDK control project:.NET Multipage TIFF SDK| Process Multipage TIFF Files
on Windows Forms applications, upload to SharePoint and save to PDF documents View, edit, insert, delete and mark up pages in multi-page TIFF files; Annotate and
www.rasteredge.com
SDK control project:C# TIFF: How to Delete Page(s) from Multi-page TIFF File Using
VB.NET How-to, VB.NET PDF, VB.NET Word, VB.NET Excel, VB.NET RasterEdge.com offers an advanced multi-page Tiff editing utility, XDoc.Tiff for .NET, which allows
www.rasteredge.com
Chapter 4. Evaluation and Analysis
45
4.4.2 Experiment 5 : Two-way Join algorithms across different clus-
ters
For the multi-way join algorithms as well, like in experiment 2 (section 4.3.2) for two-
way join algorithms, we ran the three algorithms on different types of clusters (see
Table 4.2.1). The datasets that we used had -
 1 million tuples each.
 Thesamenumberof keys - #keys=
1
10
#tuplesspread acrossthesamekey space.
Figure 4.7 showstheresults that were observed. Theresultswere similar to the un-
expected ones observed in experiment 2 (section 4.3.2). 1-machine cluster performed
better than the 5-machine cluster with the performance then improving again for the
8-machine cluster. On checking the logs, we found the very same reasons for this
anomaly. There was no network traffic involved in the case of 1-machine cluster and
this was a dominant factor in case of the 5-machine cluster. The 8-machine cluster
performed better since the smaller units of work that were well distributed across the
cluster took lesser time to complete and brought down the overall time.
Figure 4.7: Experiment 5 : Multi-way Join algorithms across different clusters
SDK control project:VB.NET TIFF: VB.NET Sample Code to Process & Manage TIFF Page
TIFF pages into a new multi-page TIFF document file VB.NET programming, this TIFF page processing control add & profession imaging controls, PDF document, image
www.rasteredge.com
SDK control project:Process Multipage TIFF Images in Web Image Viewer| Online
images into one; Swap two pages' position in multi-page TIFF images; Convert multi-page TIFF image into scannable PDF; Convert TIFF to
www.rasteredge.com
Chapter 4. Evaluation and Analysis
46
Table 4.9 shows the actual numbers that were recorded for the graph in figure 4.7.
No. of
Nodes
Reduce-Side
One-Shot
Join
Data Shuffle
Ratio
Map-Side
Join
Pre-
Processing
Reduce-Side
Cascade Join
Pre-
Processing
1
427
0
519
83
1889
85
5
1342
1.147
1657
243
2107
96
8
565
1.147
534
71
1612
32
Table 4.9: Experiment 5 : Multi-way Join algorithms across different clusters
SDK control project:Online Convert PDF file to Tiff. Best free online PDF Tif
C# developers can render and convert PDF document to TIFF image file with no loss in original file quality. Both single page and multi-page Tiff image files
www.rasteredge.com
SDK control project:C# PDF File & Page Process Library SDK for C#.net, ASP.NET, MVC
VB.NET Word, VB.NET Excel, VB.NET PowerPoint, VB.NET Tiff, VB.NET Easily manipulate multi-page PDF document file with page inserting, deleting and re-ordering
www.rasteredge.com
Chapter 5
Discussion and Conclusion
5.1 Overview
Though an elegant solution, Map/Reduce has its pros and cons like any other interest-
ing idea. Quite obviously there have been proponents and opponent of this ideology.
In this project, we set out to test the viability of the Map/Reduce framework for
joining datasets as part of database query processing. The motivation stems from the
fact that the rate at which information is exploding in today’s world has forced us to
look at database query processing from a different perspective. To keep up with its
pace, use of distributed processing no longer seems to be an option, but seems to be
anecessity. Map/Reduce was a novel idea that was developed at Google for simple
computations. These computation, though simple, required very large inputs and thus
necessitated the use of distributed processing to get results in reasonable amounts of
time. Over a period of time, Map/Reduce started getting used for myriad of different
application and it was a matter of time before data warehousing specialists started
using it for the purposes of query processing over database systems.
It was soon picked-up by the open source community and developed into an open-
sourceframework and implementation called Hadoop -theframework and theMap/Re-
duce implementation we used in this project. One of the main queries performed over
adatabase (or a dataset) is a Join. We specifically explored the options available for
joining datasets using Map/Reduce (particularly Hadoop in our case). The aim was to
consolidate and extend the existing algorithms, propose new ones and quantitatively
evaluate and analyse their performances.
The algorithms were broken into two categories with three algorithms discussed in
both categories each -
47
SDK control project:C# PDF Page Rotate Library: rotate PDF page permanently in C#.net
Using this C# .NET PDF rotate page control SDK, you can easily select any page from a multi-page PDF document file, rotate selected PDF page to special
www.rasteredge.com
Chapter 5. Discussion and Conclusion
48
 Two-way joins - joins involving only 2 datasets.
– Reduce-Side Join
– Map-Side Join
– Broadcast Join
 Multi-way joins - joins involving more than 2 datasets.
– Map-Side Join (for multi-way joins)
– Reduce-Side One-Shot Join
– Reduce-Side Cascade Join
We also suggested optimizations for Reduce-Side Cascade Join exploiting the out-
put cardinality of smaller joins involved in the algorithm. Subsequently we performed
quantitative performance tests by changing input data sizes and number of machines
participating in the cluster.
5.2 Conclusion
Thefirstthing thatimpressed us whileundertaking thisprojectwastheease with which
one could program a distributed application using Map/Reduce or Hadoop. Without
any considerable prior knowledge about distributed systems we were able to easily
install and configure Hadoop on on our development machines. Being an open-source
produce and free to download, it is an inexpensive solution for someone looking to
harnessing the power of a distributed system for solving problems. It is indeed an
inexpensive and simple, yet powerful solution for exploiting the potential of parallel
processing.
We found some quite interesting results from our experiments on Join algorithms
using Map/Reduce. Even though our clusters were of relatively small sizes, we could
notice from our experiments how the Hadoop framework exploited the cluster archi-
tecture when more nodes were added (as was seen with the Data Shuffle ratio that
remained the same throughout our experiments). This gave us a first-hand feel of why
Hadoop seems to be enjoying such a high popularity among data warehousing special-
ists.
The experiments on the two-way join algorithms concurred with the results ob-
served by Blanas et. al. in [6]. We found that Map-Side joins performs the best when
Chapter 5. Discussion and Conclusion
49
the datasets have relatively uniform key distribution. But this comes at the cost of
apre-processing step. Broadcast Join is a better option when one of the datasets is
much smaller compared to the other and the dataset is small enough to be easily repli-
cated across all the machines in the cluster. It deteriorated the fastest when the input
data size was increased. Reduce-Side Join gave almost the same performance for both
uniform and skewed key distributions whereas Map-Side Join seemed to give slightly
unpredictable results with skewed data. We also noticed that the 1-machine cluster
gave better performances than the 5-machine cluster since there was no data transfer
involved overthe network in caseof the1-machinecluster. Buttheperformance started
to improve again with 8-machine cluster.
The samebehaviourof the1-machine clusterwasobserved in thecaseof multi-way
joins as well while being tested on different clusters. When we tested the multi-way
algorithms with increasing data sizes, we successfully showed thatour optimization for
Reduce-Side Cascade Join using output cardinality improved the performance of the
algorithm. Although this came at the cost of pre-processing step and was the slowest
of the algorithms, it was successful in joining datasets that contained over 2.5 million
tuples whereas Reduce-SideOne-Shot Join gaveOutOfMemory exception anumber of
times.
5.3 Future Work
We explored the practicality of using Map/Reduce for joining datasets and found it
quite easy to use and implement over different sizes of cluster. The largest cluster we
had at our disposal contained only 8 machines. The first interesting thing would be to
test all the algorithms discussed on clusters of much larger size, with much larger data
sizes. Especially the multi-way joins since the authors in [6] did conduct experiments
on two-way joins on a cluster containing 100 nodes. Another idea would be to try and
use acombination of the algorithmsforbetter performance. For instance, in thecase of
Reduce-Side Cascade Join, the intermediate result is suitable for input to a Map-Side
Join. It might be possible to run a pre-processing step in parallel to the first join such
that the rest of the datasets are ready for joining by the time the first join produces the
intermediateresult. This may involve exploring the scheduling mechanismsof Hadoop
or any other implementation of Map/Reduce. Another possible area to explore could
be the use of indices to speed-up the join queries. It might be possible to construct
data structures to hold information about the HDFS blocks holding the datasets such
Chapter 5. Discussion and Conclusion
50
that the user program will know which block a particular tuple from a dataset corre-
sponds to. This project looked at query evaluation. Thereis alwaystheaspect of query
optimization that chooses the join algorithm best suited for a particular situation.
Appendix A
TextPair Class
The code below has been reproduced from [18]
//cc TextPair A Writable implementation that stores a
pair of Text objects
//cc TextPairComparator A RawComparator for comparing
TextPair byte representations
//cc TextPairFirstComparator A custom RawComparator for
comparing the first field of TextPair byte
representations
//vv TextPair
import java.io.*;
import org.apache.hadoop.io.*;
public class TextPair implements WritableComparable <
TextPair> {
private Text first;
private Text second;
public TextPair() {
set(new Text(), new Text());
}
public TextPair(String first, String second) {
set(new Text(first), new Text(second));
}
public TextPair(Text first, Text second) {
set(first, second);
}
public void set(Text first, Text second) {
this.first = first;
51
Documents you may be interested
Documents you may be interested