12/7/09

More is better?
Intuitively , increasing the number of processors decreases the time taken to complete a task (as long as the task can be shared effectively between processors). Think of it as the old If it takes 10 minutes for 1 person to wash 1 car, how many minutes will it take for 10 people to wash 1 car? problem. In theory it should only take a 10th of the time i.e. 1 minute to complete the entire task.

Parallelisation

Scale-up
The question could have been re-phrased another way how long will it take 10 people to wash 10 cars? (Answer the same time, 10 minutes) i.e. as the overall task gets larger. Increasing the number of workers allows the larger task to be completed in the same time. This is an example of Scale-up. Unfortunately, the 10 workers may get in each others way and this may cause the time taken to be slightly greater than 10 minutes or the number of cars washed to be less than 10.

Architecture
Network CPU CPU M M

Network CPU CPU

CPU

CPU

Network M M M

Disk

Disk

Disk

Disk

Disk

Disk

Shared nothing

Shared memory

Shared disk

12/7/09

Which is best?
In all three architectures, the shared component can become a bottle neck, i.e. as more work needs to be done, each CPU will start to contend /interfere with other CPUs for the shared component. Any system that allows the processor to spend more time working and less time waiting will be better. Shared nothing architectures are only contending for network time and are therefore less likely to suffer from interference than the other two architectures.

Data partitioning
Parallel query evaluation involves giving individual processors a task to complete which; when added to the work of other processors, yields the total query For example: We want to know who lives in a detached house. We have the following two relations: R1 (name, dateOfBirth, houseType*) name, dateOfBirth are indexed. R2 (houseType, numberRooms, detached) R1 contains 5 million individuals and R2 contains 50 house types. For a single processor R2 would be loaded into memory and then R1 would be scanned through for matching houseTypes

In a multiprocessor environment, each processor would load R2 into memory, BUT would only take PART of R1. e.g. for 26 processors, each processor could take the projection of R1 for a particular letter of the alphabet. This strategy should produce a fairly even load for each processor and keep the interference to a minimum (except for the initial demand for R2)
n=5228

Producing effective parallel query plans requires that:

the interference is kept to a minimum (distribute the small relation to all) work is balanced over processors such that they all complete their task in roughly the same amount of time (to maintain scale-up).
n=5228

12/7/09

Partitioning methods
Hash : a hash function is chosen which will split the data evenly into a pre-defined number of buckets (Partitions) Round-Robin : each tuple is delivered to a different processor in turn (very much like a card dealer dealing cards to a group of players) This is a particularly effective method when the data is stored on a striped RAID system. Range : each processor receives a projection based on a particular range for a chosen set of fields e.g. all tuples where the surname starts A-B etc. Range partitioning suffers badly from skew, where each range does not have a roughly similar number of relations (as in the example above)

Pipelined parallelism
In the absence of parallelism, each relational operator has to generate the complete relation before starting on the next operation. Parallelism allows operations to be split into sub-task which can be carried out independently. Each task processes a tuple and immediately passes it on to the next task without having to store the complete relation. Pipelining allows tuples to come out of the entire process earlier. However, pipelining can be hampered by operations which require the full relation to be known before progressing e.g. sorting and grouping. These operations block pipelining.
Run Test1 and Test2 of the task simulator to see the effect of pipelining and the advantage of splitting the select task (T1)

Query Optimisation

Parallel Query Optimisation involves combining partitioning and pipelining to overcome bottlenecks in the query plan, usually created by slow tasks such as comparisons and joins. Consider the following relations and SQL statement:
R1 (name, dateOfBirth, houseType*) name, dateOfBirth are indexed. R2 (houseType, numberRooms, detached)
R1
name, dateOfBirth,numberRooms

name, dateOfBirth,numberRooms

X
(houseType=houseType)

(houseType=houseType)

R2

houseType, numberRooms

houseType,

R1

SELECT name, dateOfBirth, numberRooms FROM R1,R2 WHERE R1.houseType=R2.houseType AND detached=true The relational algebra for this might be: name, dateOfBirth,numberRooms ( R1 X (houseType=houseType) houseType, numberRooms (detached=true(R2) ) )

numberRooms

detached=true

detached=true

detached=true

R2