Query Optimization through Cached Queries for Object-Oriented ...

SOFSEM 2010 January 23–29, 2010, Špindlerův Mlýn, Czech Republic

Query Optimization through Cached Queries for Object-Oriented Query Language SBQL Piotr Cybula Institute of Mathematics and Computer Science, University of Łódź, Poland

Kazimierz Subieta Institute of Computer Science, Polish Academy of Sciences, Poland Polish-Japanese Institute of Information Technology, Poland

SOFSEM 2010, January 23–29, 2010, Špindlerův Mlýn, Czech Republic Query Optimization through Cached Queries for Object-Oriented Query Language SBQL

Outline       

Stack-Based Approach Concept of Cached Queries Query Cache Registry Architecture of Optimizer for SBA Query Optimization Case Study Automatic Cache Update Conclusions and Future Work

2


Outline       


3


Stack-Based Approach 









In SBA a query language is treated as a special kind of programming language. Evaluation of queries is similar to evaluation of expressions in programming languages. In the approach each name appearing in the query is bound to a run-time entity according to the scope of its name. Scopes are managed through Environment Stack (ENVS). Approach can be applied to arbitrary model of data (object, object-relational, XML). SBA has its own query language SBQL (Stack-Based Query Language).

4


Query Language - SBQL 

In SBQL a query is:  Literal, name of variable, function, view e.g. 2, „Smith”, a, Dept  σ q, where q is a query and σ is an unary operator  q θ q where q , q are queries, and θ is a binary operator 1 2 1 2



More complex queries are created from the simpler ones. Example queries in SBQL: 2 + 2, Book, Book.title, Book where count(author) > 2 Extension of SBQL: imperative statements (e.g. update, delete, insert, etc.), procedures.





5


Outline       


6


Cached Queries 









Redundant data structures stored at database server side (like indices) – available for all clients. Automatically created as a side effect of standard query evaluation process. A pair: compiled query syntax tree and materialized query results (augmented with additional data for maintenance purposes). Cached queries with selection operation only (with operator where) are the generalization of indices. Similar to materialized views, but the views are manually added and the number of cached queries could be millions. 7


Optimization Method 









Using of cached queries is totally transparent for query programmer and his code. New query syntax tree is scanned for a subtree equivalent to any cached query syntax tree – found subtree is replaced with a function call which returns the cached query results. Using of cached results is quick and independently of query complexity and actual database state. Query normalization and decomposition are ways to increase a probability of utilization of the cached results. Automatic cache update after database modifications is needed for keeping query results up-to-date (only influenced cached queries). 8


Query Normalization 





Avoidance of placing in the cache two queries syntactically different but with the same semantics. Query syntax tree modification preserving original query result. Main normalization methods: 

operand sorting: bb



operator ordering: a-b+c-d → a+c-b-d



auxiliary name unification: Emp as e1 → Emp as aux1



object name unification, for example using only lower case letters in the names of objects 9


Query Decomposition 

 

Factoring out simpler independent queries for high reuse ability. Simpler query is simply updateable. Main decomposition methods: 

factoring out nested independent subqueries: Emp where salary < (Emp where name = ”Smith”).salary







factoring out aggregation queries (as cached virtual subobjects): Dept join avg(employs.Emp.salary) omitting ending path expressions (quickly referenced in object DBs): (Dept where count(employs) > 1).boss.Emp.salary query segmentation using set algebra and logical transformations: (q where p1 or p2) → (q where p1) ∪ (q where p2)

10


Outline       


11


Query Cache Registry 











Cached queries are stored in the cache registry, uniquely identified and managed by cache manager. Additional query index for fast access and search capabilities – linear hashing table with single text key being normalized text form of a query. Two registry storing places: physical (for often used queries) and volatile (temporary, for new cached queries). Registry parameters configured by database administrator: min. query usage count, max. result size, min. execution time, max. cache size, percent of cache usage size, etc. Optimal resource (cache disk space) management using statistics stored for any consecutive cached query – MRU lists maintained for removing rarely used query results from the cache. 12 Automatic result update after database changes.


Outline       


13


Optimizer Architecture Query

1

Client

Parser 2

3

Query syntax tree

1. Application requests a query.

6

4

Static evaluator and type checker Static ENVS Static QRES

Interpreter

Otimizer Cache optimizer

ENVS QRES

5

7

Local data

Server

Query cache manager

Object management

Database: metabase, object store, query cache registry, indices, ...

Transaction and procedure processing

14



1

Client

Parser 2

3

Query syntax tree

6

4


2. Parser transforms the query into query syntax tree.

Interpreter


ENVS QRES

5

7

Local data

Server

Query cache manager

Object management



15



1

Client

Parser 2

3

Query syntax tree

6

4


Interpreter


ENVS QRES

5

7

Local data

Server

Query cache manager

3. The query is statically evaluated (using static ENVS, QRES and server-side metabase) for type checking and inserting additional query elements (implicit dereferences, casts, result signatures, etc.).

Object management



16



1

Client

Parser 2

3

Query syntax tree

6

4


Interpreter


4. The query is sent to optimizer. Query optimizer is a client-side module.

ENVS QRES

5

7

Local data

Server

Query cache manager

Object management



17



1

Client

Parser 2

3

Query syntax tree

6

4


Interpreter


ENVS QRES

5

7

Local data

Server

Query cache manager

Object management



5. Cache optimizer normalizes and decomposes the query. Query text form is sent to server-side cache manager for query matching. If matched, cache manager returns query identifier to the optimizer, else adds new cached query. Optimizer modifies query tree by a call of cache 18 function.



1

Client

Parser 2

3

Query syntax tree

6

4


Interpreter


ENVS QRES

5

7

Local data

Server

Query cache manager

6. A query execution plan is compiled and sent to the query interpreter. Queries are evaluated on client-side requesting necessary data from database server.

Object management



19



1

Client

Parser 2

3

Query syntax tree

6

4


Interpreter


ENVS QRES

5

7

Local data

Server

Query cache manager

Object management



7. Query interpreter evaluates the query. In case it meets a cache function call, it requests to server for appropriate cached query results (identified by the function parameter value). If the requested cached query is new (without results cached), it evaluates them and sends to the cache 20 registry.


Outline       


21


Exemplary Object Database Person [0..*] name: string birthday: date age(): integer

Dept [0..*] dname: string employs [0..*]

boss

works_in Student [0..*]

Emp [0..*]

year: integer grades [0..*]: integer

job: string salary: real rating: real prev_job [0..*]

avgGrade(): real receives [1..*]

received_by [1..*]

supervises [0..*]

supervised_by Training [0..*] subject: string duration: integer

company: string years: string manages [0..1]

22


Exemplary Optimization Case 

Cached query Q1: Emp join works_in.Dept



New query: (Emp join works_in.Dept).(name, dname)







After the new query decomposition (cutting out ending path expressions) the cached query could be matched. In object DBs path expressions are very quickly evaluated thanks to referential data model. New query is modified during optimization process by replacing matched subtree with a cache function call parametrized by a identifier of the cached query Q1: CacheQ1.(name, dname) 23


Query Tree Transformation (Emp join works_in.Dept ).(name, dname)

Start

Start

.

. struct

join Emp works_in

.

name

dname

struct

cacheQ1 name

dname

Dept Input tree

Output tree

24


Outline       


25


Maintenance of Cached Results 









Immediately after database modification (using update trigger) or deferred (just before next result request or after a group of changes). Smart recognition of a subset of cached queries influenced by a database update (others are eliminated – elimination method reducing update time). Often or with much time consumption updated queries are removed from the cache registry. Each cached query is stored together with its sufficient subschema describing a part of database schema (stored in metabase) necessary to process the query. Similar subschemas are generated for each database update operations (create, insert, update, delete). 26

SOFSEM 2010, January 23–29, 2010, Špindlerův Mlýn, Czech Republic Query Optimization through Cached Queries for Object-Oriented Query Language SBQL Student

grades

0..*

name

0..*

0..*

Emp

0..*

1

job

string

integer year

Database schema graph metabase

Person

1

string

birthday

integer

1

salary

date

avgGrade

1

1

real

age

void → real

1

1

rating

void → integer

1

real

receives 1..*

prev_job

0..*

company

supervises 0..*

1

string Training

0..*

years works_in

subject

1

1

string

1

string duration

Dept

1

0..*

manages 0..1

integer received_by

dname

1..*

1

string supervised_by

1

employs

0..*

boss

1

27


Subschema Definitions 

Subschema function (subQ) for a query q returns:



a set of identifiers of schema nodes containing object names mentioned in query q Subschema function (subU) for an update u returns: 

a set of identifiers of schema nodes containing object names influenced by update u (created, inserted, updated or deleted) together with names of their subobjects and superobjects (from base classes) Cached queries with subschemas disjoint with a subschema generated for the current update are eliminated from cached result correction (when the intersection of subschemas is an empty set). 



28


Elimination Example 

Cached query q: Emp where (prev_job.company = “ABC”) subQ(q) = {Emp, prev_job, company}



Update u1: delete Emp.prev_job where company = “ABC” subU(u1) = {prev_job, company, years} subU(u1) ∩ subQ(q) ≠ ∅



After u1 query q should be corrected. Update u2: delete (Emp where count(prev_job) > 0). supervises.Training where count(received_by) < 8 subU(u2) = {Training, subject, duration, received_by, supervised_by, receives, supervises} subU(u1) ∩ subQ(q) = ∅

After u2 the results of query q have been unchanged. 29


Subschema Index 







Association list in form of the inverted file for fast subschema comparison (the fastest search structure for set operations with relative small domain). Main structure is a directory of all distinct values of indexed sets (object name identifiers) tied with occurrence lists (one list for one identifier). An occurrence list for a name identifier (sorted and compressed) consists of identifiers of all cached queries with subschemas containing this identifier. All queries with identifiers belonging to the occurrence lists tied with name identifiers being elements of subschema sufficient for an update are designated for correction. 30


Incremental Cache Update 







Results of cached queries (not eliminated after database update occurred) are reevaluated or corrected incrementally by removing such subresults, which were generated from modified part of a database and evaluating the results again on that part of data. Some kinds of queries cannot be updated incrementally, such as aggregates or nested queries (most of them are decomposed by the optimizer). Storing query results divided into parts derived from different root objects (sum of all the parts is the result). Removing results derived from root objects with access to deleted or updated data and then, reevaluating a query on database with root objects with access to 31 new or updated data.


Outline       


32


Conclusions and Future Work 







Query result caching can be used to enhance performance of query processing. Optimization solutions are implemented for SBQL language into ODRA (Object Database for Rapid Application development) project of SBA OODBMS built from scratch: (http://sbql.pl/various/ODRA/ODRA_manual.html) Experiments showed that in many cases, specially for complex queries, responses were over 100 times faster. Future research on result caching will include: 





taking into account some additional SBA and SBQL features, such as object roles and updatable object views methods for reusing of some parts of cached results or results of many cached queries combined together extending caching solutions for distributed environment and virtual 33 grid database repositories

SOFSEM 2010 January 23–29, 2010, Špindlerův Mlýn, Czech Republic

Thank You for your attention!

Query Optimization through Cached Queries for Object-Oriented

Optimization of Queries Invoking Views by Query

Algebraic Query Optimization for Distributed Top-k Queries - CiteSeerX

Scalable Multi-Query Optimization for Exploratory Queries ... - DBLab

improving browsing experience through query optimization and ...

A Distributed Stream Query Optimization Framework through ...

Query Language for Complex Similarity Queries

Testing ObjectOriented Software

general framework for optimization of distributed queries

using genetic algorithms for boolean queries optimization

Query Execution and Optimization Query Execution: Parameters ...

Distributed Query Optimization by Query Trading

Multidatabase Query Optimization - CiteSeerX

Chapter 13: Query Optimization

Query Optimization - Semantic Scholar

Sensor Queries: Algebraic Optimization for Time

query optimization - Semantic Scholar

Dynamic Query Re-Optimization

Query Optimization Through the Looking Glass, and What We ... - TUM

Query Optimization - CiteSeerX

Multiobjective Query Optimization - CiteSeerX

Adaptive Query Optimization - Oracle

Schema-based query optimization for XQuery queries - IFIS Uni LÃ¼beck

Heuristic query optimization for query multiple table ...

Query Optimization through Cached Queries for Object-Oriented ...

Query Optimization through Cached Queries for Object-Oriented ...

Suggest Documents