Fragmentation Investigation And Evaluation In Distributed DBMS Using JDBC and OGSA-DAI

Report as inappropriate Your report has been received

Description

The International Journal of Computer Science and Information Security (IJCSIS) is a well-established publication venue on novel research in computer science and information security. The year 2010 has been very eventful and encouraging for all IJCSIS authors/researchers and IJCSIS technical committee, as we see more and more interest in IJCSIS research publications. IJCSIS is now empowered by over thousands of academics, researchers, authors/reviewers/students and research organizations. Reaching this milestone would not have been possible without the support, feedback, and continuous engagement of our authors and reviewers. Field coverage includes: security infrastructures, network security: Internet security, content protection, cryptography, steganography and formal methods in information security; multimedia systems, software, information systems, intelligent systems, web services, data mining, wireless communication, networking and technologies, innovation technology and management. ( See monthly Call for Papers) We are grateful to our reviewers for providing valuable comments. IJCSIS December 2010 issue (Vol. 8, No. 9) has paper acceptance rate of nearly 35%. We wish everyone a successful scientific research year on 2011. Available at http://sites.google.com/site/ijcsis/ IJCSIS Vol. 8, No. 9, December 2010 Edition ISSN 1947-5500 � IJCSIS, USA.

Shared by: ijcsiseditor

Stats

views:: 194
posted:: 1/19/2011
language:: English
pages:: 8

Public Domain

Document Sample

(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 9, 2010

FRAGMENTATION INVESTIGATION AND
EVALUATION IN DISTRIBUTED DBMS USING
JDBC AND OGSA-DAI

Ahmed Almadi, Ahmed Manasrah, Omer Abouabdalla, Homam El-Taj
National Advanced IPv6 Center of Excellence (NAv6)
UNIVERSITI SAINS MALAYSIA
Penang, Malaysia
{almadi, ahmad, omar, homam}@nav6.org

Abstract— This research investigates and evaluate the impact of Moreover, some noticeable overheads are come into view
the fragmentation on different database retrieval modes based on clearly from several new technologies in the distributed
derived horizontal fragmentation by generating and distributing systems such as OGSA-DAI middleware. A reason is that the
the query to the servers (distributed search) or send the query to high-level technologies and processing gives a noticeable
the direct server (direct search). Moreover, it provides
overhead. In particular, the perceptible overheads are
recommendation on suitable query execution strategies based on
a proposed fitness fragmentation formula. Furthermore, examine appearing clearly on retrieving databases and accessing the
the suitable technology such as OGSA-DAI and JDBC in grid distributed systems. From this point of view, main research
database to examine the time overhead in distributed systems and question is "How to reduce the overhead in the grid systems
grid environments in different cases like size or number of and distributed systems on distributed database retrieval
servers. The results show that the fragmentation's time service?"
performance impact is clearly effective and positively applied Sub-questions arise from the research are as the following:
while increasing the database size or the number of servers. On • What is the best database size to apply the fragmentation
the other hand, the OGSA-DAI kept on showing slower execution
if we consider the performance in order to generate sub-
time on all conducted scenarios, and the differences between the
execution time exceeds up to 70% while increasing the size of
queries to the servers or just to the local server?
data or number of servers. In addition, this thesis has tested the • What is the tradeoff between transparency and the
impact of fragmentation search against the distributed search performance in case of using JDBC and OGSA-DAI?
where the first one submit the query to direct server(s) (direct
search), and the second one distribute the query to the servers This paper focuses on the impact of the fragmentation on
(distributed search). The result shows that the speed effectiveness different cases of database systems, and on the JDBC
of direct search technique in JDBC case is around 70% faster performance under several layers of executions against the
than the distributed search and around 50% faster in OGSA-DAI OGSA-DAI. The evaluation part will be based a quantitative
case.
evaluation and the execution time overhead is the main
Keywords-component; JDBC; OGSA-DAI; Fragmentation; attribute of the evaluation.
Distributed DBMS
II. LITERATURE REVIEW
1B

I. INTRODUCTION 1) Distributed Query Performance
16B

In distributed systems, data are fragmented, located and In processing such an index partitioning scheme two
being retrieved in a transparent manner among the distributed approaches are presented in response to a range query. A
sites[3]. Therefore, accessing some distributed data from comparison between such approaches and other similar
different locations are applied using a “View” of the data. schemes is done in order to compare their performances.
However, technically, in the distributed systems, the catalogue Accordingly, this performance is assessed from the
database is an essential demand where it makes an affix for the perspective of the response time, system throughput network
physical location into the catalogue [11]. utilization and disk utilization. Taking in account varying the
Moreover, web-services are playing a big role on retrieving number of nodes and query mix [12].
the fragmented database and applying certain services.
Fragmentation is considered to be one of the most important Sidell in (1997) presented the distributed query processing
phases that is been conducted to achieve the distributed problem in Mariposa. A comparison of its performance with a
database design. Yet, the impact of the fragmentation traditional cost-based distributed query optimizer is obtained
performance on the case of increasing or decreasing the [9].
overhead is unclear.

17 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 9, 2010
The ability to adapt a dynamic workload is displayed services model; trying to serve the needs of the various target
through a Mariposa system. In addition, the adaptive communities; and using the Globus Toolkit OGSI core
distributed query processing in Mariposa and its interaction distribution [7].
with multi-user workloads, network latencies and query size In 2008, Hoarau & Tixeuil, presented an experimental
benefits are investigated. Performance results observed to study of studying the OGSA-DAI [5]. Results were quite
show that the Mariposa system outperforms a static optimizer stable and performed quite well in scalability tests, and were
as it distributes works regularly among the available sites. executed on Grid5000. It is also discussed that the OGSA-DAI
Besides, it is to be noticed that the overhead which is WSI uses a SOAP container (Apache Axis1.2.1) which suffers
introduced by Mariposa's budding protocol gives insignificant from severe memory leaks. It is shown that the default
results if it is used with large, expensive queries. In addition, configuration of OGSA-DAI is not affected by that problem;
though for small queries it is outweighed by the benefits of however, a small change in the configuration of a Web-service
load balancing. Truthfully , the comparisons based on the could lead to very unreliable execution of OGSA-DAI [5].
TPC-D benchmark show that the authors' point of view in An OGSA-DQP is an open source service-based
which their approach behave as a static optimizer is influenced distributed query processor. The evaluation of queries is
by network latency and query size [9]. supported by this processor. The OGSA-DQP effects over
In 2003, a paper in title of “Distributed Query Processing several layers of service-oriented infrastructure. Experiences
on the Grid” [10] argues on the significant of the distributed in investigating the impact of infrastructure layers were
query processing in the Grid and on the facilities in the grid discussed in a study in [1]. In addition, this study presents an
that support the distributed query processing producers. The understanding of the performance issues, identify bottlenecks,
paper describes a Polar prototype implementation of and improve response times of queries. It also describes the
distributed query processing running over Globus. They used a experiments carried out and presents the results gained [1].
bioinformatics case study to illustrate the benefits of the However, as illustrated in Figure 1 the processes in the
approach [10]. OGSA-DAI which are in high-level schematically
Oliveira et al., have presents in 2007 a paper that shows the representations are passing through several layers of interfaces
development on the grid computing and a comparison was between each layer. Therefore, it gives the fact of the time
conducted on two algorithms for planning the distribution and overhead performance through using the OGSA-DAI high-
parallelization of database equerry on grid computing [8]. level schematically representation to communicate and
Showing the partial order planning algorithm with resource retrieve the database [6].
and monitoring constraints is the best choice for distribution
and parallel DBMS queries was their main contribution.

2) Investigating the OGSA-DAI
In grid computing, many investigations and studies on
OGSA technology where aim to decipher the importance of
OGSA-DAI and the benefits of its services.
An overview of the design and implementation of the core
components of the OGSA-DAI project was presented in High-
Figure 1. OGSA-DAI architecture and flow processes
level manner. The paper describes the design decisions made
the project’s interaction with the Data Access and Integration
Working Group of the Global Grid Forum and provides an III. FRAGMENTATION FRAMEWORK
2B

overview of implementation characteristics. Implementation
The derived fragmentation is a fragmentation where
details could be seen from the project web site [2].
databases are fragmented according to a specific attribute.
In describing experiences of the OGSA-DAI team, a team
Since that, a catalogue table is a compulsion in the main server
has an experience in designing and building a database access
to keep on mind knowledge for all fragmented databases.
layer using the OGSI and the emerging DAIS GGF
Catalogue database is a database that contains the
recommendations [7].
information of the distributed database. It contains the site, the
They designed this middleware to enable other UK e-
name of the database and the attributes in where the database
Science projects which need database access. It also provides
was fragmented.
basic primitives for higher-level services such as Distributed
We will apply a basic student database which consists of
Query Processing. In addition, OGSA-DAI intends to produce
student’s information such as name, id and year of each
one of the required reference implementations of the DAIS
student. Table I. shows the catalogue table which will be
specification once this becomes a proposed recommendation
conducted in the research implantation.
and, until then, scope out their ideas, provide feedback as well
as directly contributing to the GGF working group [7].
In this paper, issues that have arisen in tracking the DAIS
and OGSI specifications are presented. These issues appeared
during a development of a software distribution using the Grid

18 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 9, 2010
TABLE I. CATALOGUE DATABASE

Table
FAbase Dbname Serverid FAconstraints
Name
Student Year DB1 S1 1
student year DB2 S2 2

Table I. above consists of 5 main attributes that displays the
main information about the fragmented relational or tables in
the distributed system:
1. Table Name: contains the name of the fragmented tables.
2. FAbase: contains the attribute where the tables where
fragmented according on.
3. Dbname: contains the name of the DB in the distributed
servers where it handles the fragmented table.
4. Serverid: contains the server ID to refer to the server’s
IP for the distributed DB.
5. FAconstraints: contains the value of the fragmentation
base attribute for each table.

IV. MAIN FRAMEWORK FOR ENGINE SEARCHING
3B

In distributed systems, database retrieval process is
achieved on two main ways. The first way is to directly access
the server that contains the required data. The second
technique is to distribute the searching query into the
distributed servers. In this research, we will be calling these Figure 3. Flowchart for database retreiving based on catalogue database
two techniques direct search and distributed search
respectively. A. SQL Processing Search
7B

The system will take the decision of choosing the
searching method after analyzing and understanding the SQL In SQL processing step, several procedures will be done inside
statement. The decision will be based on the existing of the the engine to process the SQL, which are:
fragmentation attribute via the query, in such case, system will 1. Getting the SQL statement from the web-server: in
choose the direct search and. The existing of the fragmentation the interface, the user will write the SQL statement for
attribute in the query means that the system can get directly retrieving certain data as a string.
the data from the distributed server(s) by getting the site of 2. Select checking: (validation) does it start with
that server from the catalogue database, by referring to the “SELECT”, by using searching method for this word
FAbase in that table. In this case, the performance will be (select), if yes, continue to next step, else, give an error
higher since it reduces lots of time if it was using the message and back to the main page .
distributed search. 3. Table Name Searching: After getting the SQL, a table
From Figure 2. we can see the main architecture of the searching method will be called. Its main job is to
research framework. The processes can be categorized into search for the table's name inside the SQL statement
five main layers: User interface, SQL Processing System (string).
Management Connections (JDBC) and Servers pool. 4. Checking Name: checks if the name was mentioned
(the SQL statement is correct so far), if yes, save the
table name and continue to next step, else, give an error
message and back to the main page.
5. Retrieving Fragmentation Attribute (FA): Get the FA
style for that table from the catalogue database which is
saved in the main server.
6. FA Searching: Another searching method will be called
to search for the FA style in the SQL statement.
7. Found: If the FA was found in the SQL statement, the
system will choose the direct search; else it will choose
the distributed search.

Figure 2. Main framework and architecture

19 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 9, 2010
B. Direct Search difference between using distributed processing using JDBC
In direct search step, after receiving the FA, several or OGSA-DAI as a quantitative evaluation based.
procedures will be done inside the engine to process and Moreover, examining the significant of the direct search and
achieve the result, which are: distributed search approaches will be highlighted.
1. FA Receiving: System will receive the FA from SQL A. Implementation
processing step.
The implementation and examinations were carried out on
2. Select Statement Generator: Calling a generator
the Grid Computing Lab, in University Sains Malaysia, 2008.
method that generates a select statement that will
Implementation was applied using java code applied on an
select from catalogue database locations according to
open development platform (Eclipse). Frome the hardware
the FA.
point of view, There were 4 workstations were applied to
3. Main Server Connection: Calling the connection to
conduct the testing of this research and one for the
the main server.
development detailed in Table II.
4. Sending Generated Select Statement: Send the
generated select statement to the main server. TABLE II. HARDWARE USED DURING IMPLEMENTATION AND TESTING
5. Server Location Retrieving: Getting back the site
information for the server. Machine used for development
6. Server Connection: Prepare a connection to that Hard disk Operating
Processor(s) Memory
server (site). drive System
7. Sending User's SQL: Send the user's SQL statement Intel ® Core
to the server. ™ 2 CPU 1GB RAM 80 GB Mac OS X
8. Check Data Availability: If the data were found, get T7200 @ Leopard v10.5
back the result from the server and save it, else, 2.00GHz
return a message to the system (“No Data Found”). 4 Machines used for testing
9. Getting Results: Get the result and save to display it Hard disk Operating
Processor(s) Memory
to the user. drive System
Intel Pentium 4
CentOS
C. Distributed Search processor 1.8 512 MB 80 GB
Rocks
1. Select Statement Generator: Calling a generator GHz
method that generates a select statement, it will select
all sites that the table was fragmented to.
2. Main Server Connection: Calling the connection to From the software point of view, Software, libraries and
the main server. web servers where used are:
3. Sending Generated Select Statement: Send the o Java EE open development platform (Eclipse).
generated select statement to the main server. o MySQL as the DBMS for the data base.
4. Servers Location Retrieving: Getting back the sites o Apache Tomcat 5.5.25 web server. downloaded from:
information for the servers. (http://tomcat.apache.org/).
5. Servers Connection: Prepare a connection to all o Main libraries: java.sql.connection; java.util.*;
servers (sites).
6. Sending User's SQL: Start to send the user's SQL In addition, the OGSA-DAI were deployed in the stations.
statement to the selected servers at the same time. B. Experimental Designe
7. Check Data Availability: If the data were found, stop In order to achieve the objectives of the research, several
searching, else, return a message to the system (“No experiments and scenarios has been examined and analyzed.
Data Found”). The first group of tests was concerned about comparing the
8. Saving Result: get back the result from the server and time execution performance of JDBC beside OGSA, besides
save it. the speed up while increasing the database size. The second
9. Display Result: Display the result to the user. group of tests was concerned on the symptomatic of the of
fragmentation service system. Moreover, analysis of the
V. IMPLEMENTATION AND RESULTS experimental results and recommendation will be presented.

In the following sections, we will present the process flow C. Performance of JDBC next to OGSA-DAI
or model that the research implementation will be based on. According to the research framework, several experiments
The main concern on these experiments is to evaluate the have been conducted based on two general scenarios of
usability of JDBC connection in low-level manner against the distributed database retrieval systems. These main scenarios
OGSA-DAI middleware by measuring the time overhead are generally under the following headlines:
1. Direct Search.

20 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 9, 2010
2. Distributed Search. As a conclusion for the previous experiments, results show a
1) Scenario 1: Direct Search less time overhead using JDBC connection in comparison to
In this case, the system will access the data from OGSA-DAI.
direct server according to the fragmentation constraint. We 2) Scenario 2: Distributed Search
based our scenarios on 2 cases: In this case, the system will send generated query to the
1. Data quantity in the servers. servers at once, and access the data from all fragmented
2. Server Quantity. databases. The experiments aims to show the distributed
The testing was applied using different connection search approach among JDBC and OGSA-DAI. We based the
approaches: scenarios on the cases of data quantity in the servers.
- Request is sent via JDBC in low level of parsing and The testing was applied using different connection
connecting. approaches:
- Request is sent via OGSA-DAI Grid Data Service (GDS) • Request is sent via JDBC in low level of parsing and
to the same relational database. connecting.
• Request is sent via OGSA-DAI Grid Data Service (GDS)
(a) Case of Data Quantity to the same relational database.
Each query case is being tested while increasing the Accordingly, we will start to conduct the phase of data
amount of database rows, and the time for each case is given quantity in servers, by increasing the data gradually and test
in Milliseconds (ms). the given scenarios of query. From here the computational
time for the database retrieving must show differences
between JDBC connection and OGSA-DAI.
Figure 6 illustrates clearly the differences query execution
time using JDBC and OGSA-DAI, which it gives better results
using the JDBC.

Figure 4. Average query execution time in JDBC and OGSA-DAI

The previous experiments show a less time overhead on
using JDBC low level connection rather than OGSA-DAI
connection on scalable database size.
Figure 6. Execution time on case of retrieving the entire database from all
(b) Case of Server Quantity servers
In this case, the experiments are done while increasing the
number of servers and taking the previous average execution The second distributed query is being processed among the
time experiment result.. distributed system. The table below shows the experimental
These results were gained by applying different size result of that case.
of database starting from 10 rows up to 50000 rows. The Second query test: “Select * from Table where
average execution time of the query on the multiple amounts gender=’M’ ”.
of servers via JDBC and OGSA-DAI is illustrated in Figure 5.
(1)

In Figure 6, the result is similar comparing with the previous
scenario with slightly small differences. According to the
previous gained results, increasing of speed up in JDBC while
increasing the size of database is clear as shown in the
following figure. The speed up was measured by using the
Formula (1) of speed up.
Figure 7 shows the speed up and the increasing of the
execution time differences between JDBC and OGSA-DAI
Figure 5. Average query execution time on multiple amounts of servers in among the servers.
direct search

21 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 9, 2010
TABLE III. FRAGMENTATION SPEED BASED ON FORMULA (3)

Data 1 server 2 servers 3 servers 4 servers
amount (local)
1000 75 142.5 141.6 141.25

5000 95 165 148.3 146.25

10000 120 190 156.6 152.5

30000 270 215 190 177.5

Figure 8 illustrates the result table (Table III) of the
Figure 7. Speed up of distributed process using JDBC versus OGSA-DAI fragmentation among the distributed servers. Well, it’s clear
that if performance is taking on account, the fragmentation is
not always the right choice. Yet, it gives better speed on the
case of increasing the database amount and server amount.
D. Fragmentation Significant
In this case, the test is going to test the execution on
multiple servers in order to realize the significant of the
fragmentation. In fact, the main goal of these experiments is to
answer the question: “when should we fragment?”
To answer the earlier question, we need to consider several
formulas to be based on while analyzing the answer.
If we consider the following variables:
• Number of servers = ns
• Time of SQL processing = tsp
• Time for retrieving one row = tdr
• Amount of data = ad
• Direct Search Time = dst Figure 8. Fragmentation speed on different amount of servers
• Distributed Search execution time = distst
• Parallel Process time = ppt According to the fitness case, Figure 9 below shows the
scale of fragmentation speed on different amount of servers.
The total time T for accessing data based on distributed
database according to general approach is represented by the
following formula:

(2)

From here, time elapsed without distributing the data (local
search) gives less overhead than if it was subjected to the
distributed system. Accordingly, the execution time for the
distributed search is presented as in the following formula:

(3) Figure 9. Fragmentation significant based on fitness

Consequently, the fitness case here will event when the time From Figure 9 above, it's clear that the fragmentation scale
for local search is equal to the distributed search time starts with giving overheads for the system; yet, it shows a
execution for the same amount of data. better performance on the time when increasing the data
From the second formula, dst search gives 50% less amount and the server amount as well.
execution time as an average case than the total of distst Figure 9 and analysis table shows quantitative evaluation
average. Base on that, for understanding and analyzing the regarding the proposed fragmentation which uses this amount
situations, we presented the following results table that of database is not giving much efficient results always. The
illustrates Formula (3). reason is although the generating method is done on parallel
By referring to Connolly’s assumptions, that the tsp = 70 and the query sending to the global servers is done on parallel
milliseconds and tdr= 0.005 milliseconds / one row [4]: by creating threads, the process spends longer time while
generating the obtained methods and creating threads than just

22 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 9, 2010
retrieving it from one place. Nevertheless, the results also distributed system in high-level manner. Moreover, the
demonstrate a better result in the case of huge amount of data approaches, which were conducted to examine the distributed
and comparing more than two servers with each other. The environment, illustrate the distributed concept among
expected approach to gain a good fragmentation result is to fragmentation.
exceed the amount and the size of data, and expanding the The main framework has passed through different phases
amount of servers to more than 10 servers will show a better to examine the distributed system environment:
result. 1. Fragmentation design.
2. SQL optimizing.
E. Direct Search versus Distributed Search
3. In addition, the web-server based approaches to
The conducted search schema of direct search is giving a demonstrate the work.
good result in big amount of databases. From previous tests,
we can see the average effectiveness that has been found by Fragmentation design was based on derived horizontal
using the direct search. Figure 4.13 captures the average of fragmentation design in this research, and the experimental
these differences while deploying it using JDBC and using results on the retrieval system shows a speed up on the
OGSA-DAI. distributed search approach using parallel features instead of
Figure 10 below shows the speed effectiveness of direct using central located database. Moreover, the second approach
search technique. In JDBC case, it shows around 70% faster of the direct search shows an efficient execution and less time
than the distributed search and around 50% faster in OGSA- consuming for retrieval system than distributing the queries
DAI case. among the database.
In the SQL optimizing, the query system shows a good
result on processing the query on basic tested cases, where it
generates directly a query for sending the request according to
the fragmented database.
Accordingly, there is a big relation of distributed
fragmentation design and its impact on the query optimization
for the reason that the SQL processing system will find a
suitable generation method according to the specification of
the fragmented tables.
In the web-server, analytical analysis shows that the
Figure 10. Effectiveness of using direct search versus distributed search process under a low-level manner gives a faster speed on
distributed systems than the high-level based connection.
As we can see from the results in the previous chapter, the
F. 4.7 Findings and Recommendations OGSA-DAI gives considerable overheads over the JDBC
From the previous presented experiments, we found that: connection in low level. Moreover, the better results are being
1. The time overhead performance differences increases gained while increasing the size of database or the number of
between distributed systems processing using JDBC and servers.
OGSA-DAI while increasing the data quantity or the
number of servers.
2. Nevertheless, the OGSA-DAI still more secure in the grid VII. REFERENCES
environment since it provides message and transparent
level. [1] Alpdemir1, M. N. Mukherjee, A., Paton1, N. W., Fernandes, A. A. A.,
3. Moreover, unlike the distributed processing using JDBC, Watson, P., Glover3, K., Greenhalgh, C., Oinn, T., and Tipney, H.
(2005) Contextualised Workﬂow Execution in MyGrid P.M.A. Sloot et
OGSA-DAI is data heterogeneous. al. (Eds.): EGC, LNCS 3470, pp. 444–453. Springer-Verlag Berlin
4. On the fragmentation side, the distributed system was Heidelberg.
tested on a 4 servers in where the fragmented database [2] Anjomshoaa, A., Brisard, F., Drescher, M., Fellows, D., Ly, A.,
where applied there. It will be useful on the event of using McGough, S., Pulsipher, D. and Savva, A. (2005) Job Submission
Description Language (JSDL) Specification, Version 1.0 (draft 19),
a large size of database around more than 10000 in our Global Grid Forum 27.
tests case. [3] Browne, J.C. (2004) “Grid Computing as Applied Distributed
5. Moreover, increasing the database size, gives the Computation: A Graduate Seminar on Internet and Grid
fragmentation process a positive impact on the Computing“.IEEE international Symposium on Cluster Computing and
performance. the Grid, pp. 239-245.
[4] Connolly, b. (1999) Distributed System and Database A Practical
Approach to Design, Implementation, and Management.2nd ed.
VI. CONCLUSIONS England: Addison Wesley. pp. 603-638, 645-686.
[5] Hoarau, W., and Tixeuil, S. (2008) Dependability Evaluation of the
In this research, we have discussed about the distributed OGSA-DAI MiddleWare. Achievements in European Research on Grid
systems and the features of the distributed database design. Systems.
Fragmentation and transparency are a main concept of the [6] International Business Machines Corporation. OGSA-DAI Architecture.
[Online]. [Accessed 17 March 2008]. Available from the World Wide

23 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 8, No. 9, 2010
Web: [10] Smith, J., Gounaris, A., Watson, P., Paton, N., Fernandes, A.,
http://www.globus.org/toolkit/docs/development/3.9.5/techpreview/ogsa Sakellarious, R. (2003) ‘Distributed Query Processing on the Grid’. The
dai/doc/background/architecture.html International Journal of High Performance Computing Applications, vol.
[7] Krause, A., Malaika, S., McCance, G., Magowan, J., Paton, N. And 17, pp. 353–367.
Riccardi, G. (2002) Grid Database. Service Specification,[Online]. [11] Stockinger, H. (2001) Distributed Database Management Systems and
Available from the World Wide Web: http://www.cs.man.ac.uk/grid- the Data Grid. Mass Storage Systems and Technologies. MSS '01.
db/papers/draft-ggf-dais-gdss-ggf8.pdf. Eighteenth IEEE Symposium on, pp. 1-1.
[8] Oliveria, C. H. P., Amaral, M. A., Oliveria, E.(n.d.) Algorithms for [12] Liebeherr, J., Akyildiz, I. F., and Omiecinski, E. (1991) Performance
Distributed Database Query Command on the Grid. [Online]. [Accessed comparison of index partitioning schemes for distributed query
28th May 2008]. Available from World Wide Web: http:// processing. IEEE. In: System Sciences. Proceedings of the Twenty-
ccgrid07.lncc.br/docs/posters/27468.pdf Fourth Annual Hawaii International Conference, 8-11 Jan 1991, Kauai,
[9] Sidell, J. (1997) Performance of Adaptive Query Processing in the HI, USA, 1, pp. 317-323.
Mariposa Distributed Database Management System. [Online].
[Accessed 25th May 2008]. Available from World Wide Web:
http://www. db.cs.berkeley.edu/papers/unpubl-perf.pdf.

24 http://sites.google.com/site/ijcsis/
ISSN 1947-5500