We have implemented Soft Real-Time DBMS prototype called ZDBMS. Using this prototype we have investigated performance for commonly used policies EDF, LSF and for new transaction handling policy SPF oriented for using in cases when transactions have different static priorities. The results represent these policies performance for equal sets of experiments.
At present more and more industrial applications interacts in real time. Some of them are manipulating with large amounts of information. So they need in realtime databases and appropriate transaction handling. There is a wide area of industrial applications concerned with process control and SCADA systems which need in specialized real-time database servers. These systems have some distinctive features such as: - lifecycle is divided into two parts — design-time and work time;
- database clients have limited subset of SQL query templates, and these templates are constant in worktime part;
- sensor and system transactions have different static priorities which reflects subsequent transaction semantics;
- user transactions usually takes much longer time then sensor and system ones;
These features exert influence on transaction handling of Real-Time Database Management System (RT DBMS) used with SCADA system. Traditional works on RT DBMS scheduling policies considers transaction and data consistency taking into account only transaction deadlines and data deadlines. We propose new transaction handling policy which takes into account transaction flow irregularity represented by different static transactions priorities.
Another problem is that some critical (high-priority) sensor or system transactions fails due-to long user query transactions are executed on database server. We decided to use the mechanism of precompiled materialized views for remote database clients. Although influence of materialized views on system performance is not investigated in this paper materialized views management subsystem is the part of client system architecture.
In this paper we describe Soft Real-Time DBMS prototype architecture which implements model for investigating transaction handling policies. In performance evaluation distributed system is used to minimize influence clients (transaction generators) on database server performance.
There are a lot of works concerned with transaction handling policies so we will mention only papers which results have influenced on this work. Common transaction handling aspects in Real-Time DBMS were considered in [1, 2, 4]. Issues with Timing constraints were described in [3]. Works [5] and [6] are concerns with practical implementation of real-time transaction handling. Real-Time DBMS peculiarity is that research in this area tightly correlated with investigations in area of temporal and active database management systems. Survey on active databases represented in [7] while temporal DBMS is fully described in [8]. During developing query subsystem we investigated commonly used query optimization techniques (represented in [9]). Modern line of investigations in multi-query optimizations which used in materialized views support subsystem represented in [10].
Supported transaction model is based on composite transactions which can be divided into subset of microtransactions (atomic transactions such as add row, modify row, etc.). If atomic transaction fails all composite transaction is being revoked.
Transaction taxonomy represented in Figure 1. It
describes transactions RT transactions which can appear
in typical SCADA system and respectively in
appropriate Real-Time DBMS.
wmicro = x, d , p, m, ta , trvi , texec , tend , (
Implemented experiment system contains two types of RT DBMS prototype applications:
- dedicated server — RT DBMS server which handles clients requests
- transaction generator — this application emulates clients activity and combines pure transaction generator with RT DBMS server to handle queries to materialized views (materialized views influence is not evaluated in this paper).
Both application types are based on common system architecture represented in illustration below (Figure 2). Main components are: Network Manager, Transaction Decomposer, Query Manager, Priority Manager, Transaction Scheduler, Transaction Pool and DBobjects Manager
Network Manager handles all communication between current server and over applications. Communication is based on own protocol, which supports control packets and transaction packets. This protocol is datagram protocol based upon UDP protocol. Network Manager stores its own settings (clients/servers map, datagram resend policy etc) in XML configuration file which can be loaded from the disk or sent throw the LAN by using special control packet.
Transaction decomposer receives waiting transaction from the Network Manager queue, decomposes transaction into atomic transactions and passes microtransactions subset either to Query Manager (for user queries) or to Transaction Scheduler queue. Transaction scheduler is component which handles all atomic transactions sets and assigns them into unoccupied threads from transaction thread pool. Transaction Scheduler has special thread used for synchronization — all scheduling actions are performed within this thread to avoid resource management deadlocks.
All atomic transaction sets are waiting for their assignment in queue. In each scheduling step Transaction Scheduler checks this queue for failed transactions to return failed transaction back to the client.
When assigning transaction to the thread Transaction scheduler uses priority returned by Priority Manager in compliance with current transaction handling policy.
Transaction Pool is a set of threads capable of transaction executing. When transaction is assigned to the subsequent thread this thread locks object need for the first atomic transaction in the set. For locking Db object two-phase locking method used. First Lock is made by synchronization thread of Transaction Scheduler and second phase is performed by transaction executing thread. In execution step transaction is checked for data consistency and is aborted if deadline or data-deadline achieved. So all the transaction scheduling policies has data consistency check, but – DC suffix is omitted.
Objects Manager is the component which represents InMemory database. It supports the following object types: tables; indexes (B-tree index); hashes; materialized views;
All objects represented in block-list (or paged) structure. Access to each object can be locked on pagelevel. Each object has a set of temporal attributes used in priority handling. Let X is object in RT DBMS then it has the following attributes:
LUT(X) — last update time of the X object — this time is calculated automatically by system;
RVI(X) — relative validity interval — this value is set to each object at the design time. It represents time interval in which object keeps its validity;
AVI ( X ) — Absolute Validity Interval is the time interval which can be calculated as follows:
AVI ( X ) = [LUT ( X ), LUT ( X ) + RVI ( X )] (
All transaction handling (scheduling) policies are based
on transaction model represented in (
— transaction deadline is defined as
DL(T ) = ta + min(RVI (d ), trvi ) , (
—data deadline depends on temporal
DL(T ) follows:
DDL(T )
object properties:
DDL(T ) = AVI ( x) = LUT ( x) + RVI ( x) (
ETT (T ) — execution transaction time is defined as follows::
ETT (T ) = now() − texec , (
SF (T ) — slack factor is a parameter which takes into account estimated amount of time to transaction deadline. Slack factor is defined as follows:
SF (T ) = DL(T ) − (now() + EET (T )) . (
— proposed function which combines
traditional priority handling policies (EDF, EDDF,
LSF). We define this function as :
PR(T ) = PREDF (T ) × (1 − μ ) +
μ
SF (T ) − 1
, (
and μ are tuning parameters and used to handle which policy should be used at current moment.
To include semantic priority to this policy combining functions we introduce priority comparison function PRc defined as:
PRc (T1 , T2 ) = β × SIGN ( p(T1 ) − p(T2 )) +
(1 − β )× SIGN (PR(T1 ) − PR(T2 ))
, (
1,if v >= 0 SIGN (v) = 0,if v < 0
— sign function.
As result we have a set of functions which can be used to combine different transaction handling policies at the same time by using tuning parameters α ,β , μ .
EDF — Earliest Deadline First — this scheduling
policy is historically first. It takes into account only
transaction deadlines. Tuning parameters for it
according to (
Other tuning parameters are β < 0.5,μ = 0 .
HH — Half-Half approach — another way to
compromise between transaction and data deadline.
Here α is defined as:
ETT (T ) ETT (T )
,
EET (T ) EET (T )
α =
1, ETT (T ) > 0.5
EET (T )
≤ 0.5
(
Performance evaluation in this paper is devoted to comparison of proposed SPF policy with EDF and LSF policies. All policies are used with data consistency check, so we omit –DC suffix.
Experiment system has two PC connected through 100 Mbit Ethernet. One PC was used for dedicated server and another one for transaction generator. Dedicated server had test database with 20 tables (each table with 10000 rows, RVI(X)=100ms). Server had transaction pool with 10 threads. Transaction generator had 10 generation threads each generates 2 transactions (with static priority 100 and 500) per time. Generation period varies from 10 to 300 ms. Generated transactions are uniformly distributed within generation period. Relative validity interval for transaction data is t rvi =40ms. Each generated transaction contains 1000 atomic transactions of ModifyRow type.
For each generation period there was 10 test with 1000 transactions generated. After each test application was reloaded. For each test average miss ratio was calculated (miss ration = failed count / total count) and average miss ratio for high-priority (500) and lowpriority (100) transactions. Tables 1 and 2 contain performance evaluation results for each policy represented with total miss ratio (Table 1) and miss ratio for high-priority transactions (Table 2). Figure 3 contains appropriate diagram.
As further work we consider more experiments with scheduling policies with evaluating SPF policy performance in dependence of β tuning parameters. Another direction of further experiments is investigating of materialized views using influence on common system performance. This work is concerned with tuning parameters and scheduling policy for clientside server, which handles materialized views. And as final part we propose the experiments on computational system which simulates real SCADA system with appropriate database structure and hosts configuration.