Optimization of Distributed Queries in Grid Via Caching

Optimization of Distributed Queries in Grid via Caching

Piotr Cybula1, Hanna Kozankiewicz2, Krzysztof Stencel3, Kazimierz Subieta2,4

2 University of Lodz, Lodz, Poland [email protected]

2 Institute of Computer Sciences of the Polish Academy of Sciences, Warsaw, Poland [email protected]

3 Institute of Informatics Warsaw University, Warsaw, Poland [email protected]

4 Polish-Japanese Institute of Information Technology, Warsaw, Poland [email protected]

Abstract. Caching can highly improve performance of query processing in dis-tributed databases. In this paper we show how this technique can be used in grid architecture where data integration is implemented by means of updatable views. Views integrate data from heterogeneous sources and provide users with their integrated form. The whole process of integration is transparent, i.e. users need not be aware that data are not located at one place. In data grids caching can be used at different levels of architecture. We focus on caching at the mid-dleware layer where the cache is stored in the database of the integrating unit. These results can be then used while answering queries from grid users, so there will be no need to reevaluate the whole queries. In such a way caching can highly increase performance of applications operating on grid. In the paper we also present an example how a query can be optimized by rewriting to make use of cached results.

1 Introduction

Performance is a crucial issue for distributed systems. In the area of databases re-search focuses on optimization of queries which allows for achieving better query evaluation time. There are many methods of distributed query optimization like query decomposition, using distributed indices, etc. Among these methods caching has emerged as one of fundamental techniques. Generally speaking caching increases per-formance via storing results of queries, which are then used during evaluation of fol-lowing queries, so query processing is sped up. Cache can be kept at a middleware layer – i.e. a mediator between local servers (which provide data) and applications acting on these data.

Caching is a subject of various research papers like [1, 4, 6]. There exist many techniques related to caching e.g. cache investment [10]. In this method a query opti-mizer aims to enhance performance of future queries instead of thinking about per-formance of only currently processed query. It means that sometimes the query opti-

mizer generates a suboptimal plan for a particular query in order to establish a better performance of subsequent queries.

Data caching can be implemented by means of materialized views. There are a lot of work done in the area of processing queries using views e.g. [9]. One of the main problems is an algorithm determining choice of optimal views to materialize and there are many proposals [2, 8, 16]. There have been also proposed algorithms for answer-ing queries using views that were developed for the context of data integration and distributed database systems [5, 15, 20]. In systems with data caching there is also a problem to have consistency of real data with cached data. The problem has been ad-dressed in many papers, for instance [3, 7].

In this paper we aim to show how caching can be useful in our data grid architec-ture, where data are integrated by means of updatable object-oriented views with full computational power. Such views (defined in a very high-level query language) facili-tate the development of intelligent mappings between heterogeneous data/service on-tologies. Within the architecture we analyze how caching of data can be used to en-hance performance. We show how cached results of queries stored at middleware layer can fasten query evaluation, when query is optimized via query rewriting tech-niques.

The paper is structured as follows. In Sections 2 and 3 we describe the Stack Based Approach and mechanism of updatable views defined within this approach. In Section 4 we present our grid architecture. Section 5 includes description how caching can be useful in such an application. In Section 6 we show an example of query optimization through rewriting that illustrates how cached results of queries can be used during query evaluation. Section 7 concludes.

2 Stack-Based Approach

Our grid mechanism is based on the Stack-Based Approach (SBA) to query languages [22, 23, 24]. SBA treats a query language as a kind of a programming language. Therefore, queries are evaluated using mechanisms which are common in program-ming languages. The approach is based on the naming-scoping-binding principle what means that each name in the query is bound to the proper run-time entity depending on the scope for the name. The mechanism of name binding and scopes are managed by means of environment stack (ENVS). The stack consists of sections and each of these sections describes a different environment e.g. environment of the databases, or of the user session. Sections of ENVS consist of entities called binders whose role is to relate a name with a run-time entity (object, procedure, view, etc). Binding of the name n means that the query interpreter looks through the consecutive sections of the ENVS to find the closest (to ENVS top) binder with the name n. The result of binding is a proper run-time entity (an object identifier, a physical memory address, etc.)

SBA defines an abstract formal framework that is known as the Stack-Based Query Language (SBQL). In SBQL queries can be defined in the following way: • a literal or a name (of the variable, procedure, view, etc) is an atomic query • more complex queries can be built from the simpler ones using unary operators

(like not, factorial, sin) and binary operators (like where, max, +, ∀).

In SBQL all operators are orthogonal (with exception of typing constraints). In this way in SBQL can be assembled complex queries. Example SBQL queries are: 1, 2+2, Book, Book where author =”Lem”, Book.(title, author).

SBQL also supports procedures and functional procedures with no restrictions on their computational complexity. Procedures can be defined with or without parame-ters, can have local environment, can call other procedures, and can have side-effects. Procedures are key elements of the SBQL view mechanism.

3 Updatable Views in SBA

A view is a mapping of stored data into virtual data. In the classical approach (SQL) a view is a function, similar to programming languages’ functions. View updating means that a function result is treated as an l-value in updating statements. Such an approach, however, appeared to be inconsistent due to problems with finding un-equivocal mapping of updates on virtual data into updates on stored data. In our ap-proach to view updates [11, 12] a view definer can extend a view definition by the in-formation on update intents. The information allows the programmer to eliminate ambiguities connected with multiple ways of performing a view update and the risk of warping user intention, which is the well-known problem related to view updates. In our approach a view definition consists of two main parts: 1. A mapping between stored and virtual objects. This part of the view definition has

a form of a functional procedure that returns entities called seeds. They are used as parameters for the re-defining procedures. This part of the view definition is identi-fied by the clause virtual objects.

2. Re-definitions of generic operations that can be performed on virtual objects. We have identified four such operations on virtual objects, i.e., dereference returning the value of a given virtual object, insertion of an object into a given virtual object, deletion of a given virtual object, and update the value of a given virtual object. The view definer has freedom to decide which of them and how these operations should be re-defined. (If an operation is not defined for virtual objects, it is forbid-den). Description of these operations also has a form of functional procedures with arbitrary complexity. To distinguish operations we use fixed names on_retrieve, on_insert, on_delete, on_update. View definitions can contain other elements such as definition of subviews, inter-

nal state variables, etc.

View update process. A query interpreter must distinguish updates of virtual data and updates of stored data. Thus we have introduced the notion of a virtual identifier. It is a counterpart of an identifier of a stored object. A virtual identifier, besides in-formation on the seed of a virtual object, contains information on the definition of view that has generated the given virtual object.

When the user performs an update operation on a virtual object, a query interpreter detects that it deals with a virtual object due to its virtual identifier. Thus instead of the generic update operation the interpreter calls the corresponding procedure defined within the view definition. The interpreter knows which operation is to be called due to view definition identifier included into the virtual identifier.

4 Grid Architecture

The heart of our approach is the global virtual object and service store (shortly: global virtual store), Fig.1 [13, 14]. Global clients are applications that send requests to the global virtual store. Global clients see data in grid according to global schema (collection of definitions of data/services provided by the global virtual store). The global schema is agreed upon by a consortium, by a standard or by a law that estab-lishes the grid. The grid offers data/services supplied by local servers. Local sche-mata define data/services inside a local server. These schemata, as well as the busi-ness meaning of the data/services, can be different at each local server. The schemata are invisible to the grid users. Global

client 1 Global client 3

Global client 2

Global views Global virtual object and service store

Communication protocol

Contributory views

Local service and object store Local server

Contributoryviews

Local service and object store

Local server

Caching at local servers of: • The mostly often used

expressions• Aggregated functions (e.g.

min, max, avg)

Caching at middleware layer: • Caching data received from

local servers• Caching answer to queries

from users• Caching results of elements of

queries being part of definitions of views

Caching at client layer : • Caching results of queries

from middleware

Global client 1

Global client 3

Global client 2

Global views Global virtual object and service store

Communication protocol

Contributory views

Local service and object store Local server

Contributoryviews

Local service and object store

Local server

Caching at local servers of: •

expressions• Aggregated functions (e.g.

min, max, avg)

Caching at middleware layer: • Caching data received from

local servers• Caching answer to queries

from users•

Caching at client layer : • Caching results of queries

from middleware

Fig.1. Architecture of the GRID illustrating places where caching can be used

The first step of integration of a local server into the grid is done by the administra-tor of this local server who has to define the contributory schema. It is the description of the data and services contributed by the local server to the grid. The local server’s administrator also defines contributory views that constitute the mapping of the local data/services to the canonical data/service model assumed by the grid. The second step of the integration of local servers into the grid is the creation of global views. These views are stored inside the global virtual store. The interface of them is defined by the global schema. They map the data and services provided by the local servers to the data and services available to the global clients.

The global views are defined by the grid designer, which is a person, a team or software that generates these views upon the contributory schemata, the global schema and the integration schema. The integration schema contains additional in-

formation how particular data and services of local servers contribute to the global canonical model of the grid. In Fig.1 we show that caching can be used at each of three layers of the architecture: at clients, at middleware, and at local servers.

Data integration example. Assume a database that contains Book objects with attrib-utes ISBN, title, author and price. In this paper we based our consideration on an ex-ample of integration where data are horizontally fragmented (it is one of the most fre-quent case). Assume there are three local servers located in Cracow, Gdansk, and Warsaw (we call these servers by their locations). Each server keeps data of the books. All contributory schemata are the same. In the considered case the integration schema contains the following information: • ISBN is a unique identifier of all books • There are no duplicates of ISBN in local databases. • The global database is the virtual union of all three databases.

We would like to define a view that provide prices and titles of books with prices smaller than 5 Euro. The definition of the global view might look as shown below: create view CheapBookDef {

virtual objects CheapBook { /* returning seeds */ return ((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5) as b;}

on_delete do { delete b }

create view TitleDef { virtual objects Title { return b . title as t; } on_update newTitle do { t := newTitle; } on_retrieve do { return t; }

}

create view PriceDef { virtual objects Price { return b . price as p; } on_retrieve do { return p; }

} }

Note that the view refers to objects from a particular server using the name of its location (e.g. delete Warsaw . Book). The view delegates the updates to appropriate servers. The view definer can use implicitly several routines of the communication protocol, for instance, the navigation (“.”), insert, delete, update (“:=”). These remote operations are called as if they were local.

We would like to emphasize that the global clients of the view cannot see the ori-gin of particular virtual objects. The seeds of virtual objects are encapsulated and global clients just refer to the name of the view and attribute names, like in the following query that returns the titles of all very cheap books:

(CheapBook where Price < 2) . Title or in an updating statement (change the title ‘Salaris’ into ‘Solaris’):

(CheapBook where Title = ‘Salaris’) . Title := ‘Solaris’;

5 Caching in Grid Architecture

In our architecture caching of data can be used in threefold (refer to Fig.1): 1. Caching at local servers. This kind of caching is identical to caching in non-

distributed databases. The problem has been described in details in [3]. 2. Caching at clients. Applications acting on grid can store results of queries returned

by grid and use this results later instead of re-asking grid database. It seems that this kind of caching does not imply any conceptual difficulties.

3. Caching at middleware. Caching at integrating unit can have many forms: • Caching of data stored at local servers (e.g. if server A stores data of books, then

this data are kept replicated in grid data store). • Caching results of queries that are often evaluated while creating virtual objects

(e.g. if average price of books at servers A, B, and C is often evaluated then we can save this value in the object store).

• Caching answers to client queries – in this way query reevaluation can be avoided.

In this paper we focus on the last category of caching i.e. data caching at middle-ware. The choice of queries beneficial for caching is an important issue and there are plenty of techniques which allows choosing a set of optimal queries for caching. Ma-jority of such techniques is based on statistics kept at clients (how often parts of que-ries are used, mean access time to servers, etc.)

We assume that at middleware there must be a cache registry – a module which keeps information about all stored results of queries. The organization of this cache has been described in [3].

optimizedquery

syntactic tree Optimization

via caching Query interpreter Optimization via rewriting

Cache registry Virtual object store

Query optimizer

query syntactic

tree ...query

syntactic tree

...

Fig.2. Architecture of query evaluation environment at middleware

In Fig.2 we presented architecture of query optimization at middleware layer. (We included only techniques related to caching.) The scenario of query processing looks as follows – the middleware receives query from a user. The parser transforms it into the form of a syntactic tree. This tree is the input of the middleware query optimizer which rewrites it using known rewriting rules. The optimizer uses the cache registry to identify queries that need not be reevaluated. At the end the optimizer passes the optimized query syntactic tree to the query interpreter.

6 Query Optimization via Rewriting

Due to full orthogonality and consistent conceptual continuation (with no anomalies and irregularities), queries involving views are fully optimizable through the query modification technique [21, 25]. The idea of query modification is to combine a query containing a view invocation with the definition of the invoked view. The resulting query has no references to view invocations (instead, it has direct access to their defi-nitions). The optimization concerns cases when sack definitions are reduced to single (however complex) queries, with no parameters and recursion. These conditions are satisfied by majority of views. In all such cases textual substitution of the views invo-cation by the corresponding query from the sack definition results in a semantically equivalent query that can be optimized by standard methods, e.g. by removing dead sub-queries, factoring out independent sub-queries, and low level techniques (e.g. based on indices).

Some peculiarity of our view mechanism in comparison to [25] concerns the fact that a view for retrieval is determined by two queries: the first one from the sack defi-nition and the second one from the on_retrieve clause. In consequence, we proceed as follows: the first query substitutes textually the corresponding view invocation, and the second query substitutes textually the dereferencing operator acting on the view invocation (in the post-fix order, with the dot operator inside). Although the derefer-encing operator is usually implicit in queries, it can be easily recognized during pars-ing. Thus, we can apply the full static optimization by query modification.

Updating operations that are parts of a view definition do not interfere with the use of the presented methods, but only for querying. However, view updating requests cannot be optimized in this way. New optimization techniques addressing this issue will be the subject of further investigations.

After query modification several rewriting techniques can be used to achieve an optimized form of the query, among others: • Removing dead subqueries, i.e., these parts of the query which do not contribute to

the result of the whole query in any way [19]. • Method of independent subqueries [18] that is based upon the observation that

some subqueries can be evaluated outside loops implied by non-algebraic opera-tors.

• Changing joins into less expensive navigations. • Removing auxiliary names. • Transforming queries to forms where indices can be used. • Using cached results of queries.

Example of query optimization. To illustrate query rewriting technique we analyze a query that involves a view CheapBook defined in Section 4. The view returns virtual objects that include information about titles and prices of books that are claimed to be cheap (i.e. they cost less than 5 Euro).

Here, we present the consecutive steps of optimization of a query that contains a view invocation. We assume that server in Cracow has very long access time and therefore data of books kept there are cached at middleware (under the name CBook). Let us consider the following query, that returns titles of cheap books, which price is lower then the average price of cheap books with title “databases”:

( CheapBook where Price < avg( (CheapBook where Title = “databases“) . Price)

) . Title The optimization of the query may look as follows:

1. In the first step we add explicit calls to the dereference function in these places where the dereference is implicit (e.g. it is forced by operator = ):

( CheapBook where deref (Price) < avg( (CheapBook where deref (Price) = “databases“) . deref (Price))

) . deref (Title) 2a. In the next step we substitute the view invocation with parts of its definition. For

the sake of clarity we divided this step into two (2a and 2b). First, we insert a query from on_retrieve body of the corresponding view instead of calls to the deref function:

( CheapBook where (Price . p) < avg( ((CheapBook where (Title . t) = “databases“) . (Price . p)))

) . (Title . t) 2b. Next, we substitute all view invocations by the queries from the corresponding

sack definitions: ((((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5) as b)

where ((b . price as p) . p) < avg(((((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5 ) as b) where ((b . title as t) . t) = “databases“) . ((b . price as p) . p))

) . ((b .title as t) . t) 3. In the following step we remove auxiliary names t and p:

((((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5) as b) where ( b . price ) < avg(((((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5) as b) where (b .title) = “databases“) . (b . price))

) . (b . title) 4. Next, we remove the auxiliary name b:

(((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5) where price < avg((((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5) where title = “databases“) . price)

) . title 5. We connect two consecutive where subqueries into one subquery with the filtering

condition built by means of the and operator: ((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5

and price < avg(((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5 and title = “databases“) . price)

) . title 6. Now, we take the common part before a loop to prevent multiple evaluation of a

query that calculates average price of cheap books on databases:

(avg(((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5 and title = “databases“) . price) as a ) .((Gdansk.Book ∪Cracow.Book∪Warsaw.Book) where price < 5 and price<a

) . title 7. Finally, we use the cached result CBook (because the access to the data from Cra-

cow is very slow): (avg(((Gdansk . Book ∪ CBook ∪ Warsaw . Book) where price < 5

and title = "databases") . price) as a ) . ((Gdansk .Book ∪ CBook ∪Warsaw . Book)where price < 5 and price < a ) . title The above query is optimal according to the assumed rewriting methods. We

would like to underline that all steps of query optimization presented in this section can be performed in an automatic way using query optimization techniques elaborated for SBQL ([17]).

7 Conclusions and Future Work

In the paper we have described how query caching can be used to enhance perform-ance of applications operating on grids. We based our consideration on grid architec-ture where the key element is the mechanism of updatable views. We showed where in this architecture caching can be implemented and how query rewriting techniques can use these cached results.

Future research on caching in grid will include: • Elaboration of methods of selection of optimal query set for caching. • Providing mechanism of consistency of data in cache at middleware and data

stored at local servers (protocol is required that will propagate such updates). • Work on new method of query rewriting to be able to optimize queries involving

complex view definitions (current methods work on views, where the sack defini-tion and operations are limited to a single query). In the future we are aiming to implement caching in distributed grid database based

on the ODRA prototype – an object-oriented database platform built from scratch by our team.

References

1. S. Adali, K.S. Candan, Y. Papakonstantinou, V.S. Subrahmanian: Query Caching and Op-timization in Distributed Mediator Systems. SIGMOD Conference 1996: 137-148

2. S. Agrawal, S. Chaudhuri, V.R. Narasayya: Automated Selection of Materialized Views and Indexes in SQL Databases. VLDB 2000: 496-505

3. P. Cybula, K. Subieta: Cached Queries in the Stack Based Approach. ICS PAS Report 985, 2005

4. S. Dar, M.J. Franklin, B.T. Jónsson, D. Srivastava, M. Tan: Semantic Data Caching and Replacement. VLDB 1996: 330-341

5. O.M. Duschka, M. Genesereth, A.Y. Levy: Recursive Query Plans for Data Integration. Journal of Logic Programming. Logic Based Heterogeneous Information Systems, 2000

6. M..J. Franklin, M.J. Carey, M. Livny: Local Disk Caching for Client-Server Database Sys-tems. VLDB 1993: 641-655

7. M..J. Franklin, M.J. Carey, M. Livny: Transactional Client-Server Cache Consistency: Al-ternatives and Performance. ACM Trans. Database Syst. 22(3): 315-363 (1997)

8. H. Gupta, I.S. Mumick: Selection of Views to Materialize in a Data Warehouse. IEEE Trans. Knowl. Data Eng. 17(1): 24-43 (2005)

9. A.Y. Halevy: Answering queries using views: A survey. VLDB J. 10(4): 270-294, 2001 10. D. Kossmann, M.J. Franklin, G. Drasch: Cache investment: integrating query optimization

and distributed data placement. ACM Trans. Database Syst. 25(4): 517-558 (2000) 11. H. Kozankiewicz, J. Leszczyłowski, K. Subieta: Updatable XML Views. Proc. of ADBIS

Conf., Springer LNCS 2798, pp. 385-399, Dresden, Germany, 2003 12. H. Kozankiewicz, J. Leszczyłowski, K. Subieta: Implementing Mediators through Virtual

Updatable Views. Proc. of EFIS Workshop, IOS Press, pp. 52-62, Coventry, UK, 2003 13. H. Kozankiewicz, K. Stencel, K. Subieta: Integration of Heterogeneous Resources through

Updatable Views. ETNGRID Workshop, June 2004, Proc. published by IEEE 14. H. Kozankiewicz, K. Stencel, K. Subieta: Implementation of Federated Databases through

Updatable Views. Proc. of the European Grid Conference, Amsterdam, The Netherlands, 2005, LNCS (to appear)

15. A.Y. Levy, A. Rajaraman, J.J. Ordille: Querying Heterogeneous Information Sources Using Source Descriptions. VLDB 1996: 251-262

16. H. Mistry, P. Roy, S. Sudarshan, K. Ramamritham: Materialized View Selection and Main-tenance Using Multi-Query Optimization. SIGMOD Conference 2001

17. J. Płodzień: Optimization Methods in Object Query Languages. Ph.D. Thesis. Institute of Computer Science, Polish Academy of Sciences (2000)

18. J. Płodzień, A. Kraken: Object Query Optimization through Detecting Independent Subque-ries. Inf. Syst. 25(8): 467-490 (2000)

19. J. Płodzień, K. Subieta: Query Optimization through Removing Dead Subqueries, Proc. of ADBIS Conf., Springer LNCS 2151, 2001, 27-40

20. R. Pottinger, A.Y. Halevy: Minicon: A Scalable Algorithm for Answering Queries Using Views. VLDB Journal 2001

21. M. Stonebraker: Implementation of Integrity Constraints and Views by Query Modifica-tion. Proc. of SIGMOD Conf., 1975

22. K. Subieta: Theory and Construction of Object-Oriented Query Languages. Polish-Japanese Institute of Information Technology Editors, Warsaw 2004, 522 pages

23. K. Subieta, C. Beeri, F. Matthes, J.W. Schmidt: A Stack Based Approach to Query Lan-guages. Proc. of Intl. East-West Database Workshop, 1995

24. K. Subieta, Y. Kambayashi, J. Leszczyłowski: Procedures in Object-Oriented Query Lan-guages. Proc. of 21-st VLDB Conf., 1995, 182-193

25. K. Subieta, J. Płodzien: Object Views and Query Modification, Proc. of IEEE Bal-ticDB&IS, pp. 13-24, Vilnius, Lithuania, 2000