Manually managing individual data, without database support, is hard and compu- ... Using the QoS metrics as a basis for QoS management, we develop a.
QoS-Aware Real-Time Data Management A Dissertation Presented to the faculty of the School of Engineering and Applied Science University of Virginia
In Partial Fulfillment of the requirements for the Degree Doctor of Philosophy Computer Science
by
Kyoung-Don Kang May 2003
c Copyright May 2003 Kyoung-Don Kang All rights reserved
Approvals This dissertation is submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy Computer Science
Kyoung-Don Kang
Approved:
Sang H. Son (Advisor)
John A. Stankovic (Chair)
John L. Pfaltz
Tarek F. Abdelzaher
Gang Tao (Minor Representative)
Accepted by the School of Engineering and Applied Science:
Richard W. Miksad (Dean)
May 2003
Abstract
Various real-time applications such as agile manufacturing and traffic control deal with a large amount of data. Manually managing individual data, without database support, is hard and computationally expensive. Real-time data services are also becoming increasingly important in relatively new applications such as e-commerce and online stock trading which require databases to process trade requests within their deadlines, i.e., before the market status changes, using fresh data reflecting the current market state. Conventional (non-real-time) databases are not designed to support timing and data freshness constraints, and therefore, they show poor performance in these applications. For these reasons, we investigate a new research problem, i.e., QoS management in real-time databases, to support the required deadline miss ratio and data freshness even in the presence of unpredictable workloads and data access patterns. This dissertation presents solutions for QoS-aware real-time data management in a stepwise manner. First, we define several QoS metrics, including novel data freshness metrics, to let a database administrator specify the required quality of real-time data services in terms of deadline miss ratio and data freshness. Using the QoS metrics as a basis for QoS management, we develop a novel QoS management architecture that applies feedback control, flexible freshness management, and admission control schemes to support the required deadline miss ratio and data freshness. We also design workloads for our simulation study considering real-time data semantics observed in NYSE trade traces unlike most existing real-time database research, dealing with purely artificial workloads. Based on performance evaluation results, we show that our approach achieves a near zero deadline miss ratio and perfect data freshness. Second, we extend our QoS management architecture to support service differentiation in real-time databases. Existing real-time database re-
iv
v search for service differentiation neither supports any miss ratio bound nor considers data freshness issues. In contrast, our approach can guarantee differentiated miss ratio bounds among several service classes, while supporting the required data freshness. We extend the feedback-based miss ratio control, apply fixed priority scheduling and concurrency control, and consider two alternative admission control policies for service differentiation. Finally, we present a secure real-time transaction processing architecture in the context of multi-level security model. Our approach is novel in that it can support both database security property and real-time performance guarantees. Mandatory access control is supported to prevent illegal direct/indirect information transfer between different security levels, and the required deadline miss ratio is guaranteed even given dynamic workloads. As a result, real-time transactions can be processed in a secure and timely manner.
Acknowledgments
First, I thank the committee. Professors Son and Stankovic have co-advised me giving helpful insights. I like to thank Professor Stankovic again because he has also served as the committee chair. Professor Abdelzaher taught me fundamentals of QoS management in World Wide Web and real-time systems. Professor Pfaltz continuously encouraged me to pursue a Ph.D. In addition, his data mining class was a real fun to me. Professor Tao patiently taught me basic control theory. I appreciate many colleague students in the department, especially T. J. Highley, E-Ching Lee, John Haskins, and Nicolas Christin, for helping me survive the graduate school. Without them, the department could have been a dull place to me. I want to thank my friends who I have met in Charlottesville. I would like to give special thanks to Sang Jin Lee, Dong Soon Im, Joo Heon Lee, Sung Ju Ko, and Jin Il Kim for their friendship and many helpful tips as successful researchers and junior professors. I also like to appreciate Professor Kwan Woo Ryu who initially encouraged me to study in the United States. He has been my life-time mentor since I first met him in 1990. Finally, I deeply appreciate my wife Mi Jin and son Dong Hoon for their never-ending love and support. I appreciate my parents and parents in law. I would like to thank Mi Yun, my sister in law, and her husband Dae Hun Suh for their great support. I also miss my brother Tae Ho.
vi
Contents
1
2
3
4
Introduction
1
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.5
Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Real-Time Database Model and Quality of Real-Time Data Service Metrics
10
2.1
Real-Time Database Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2
ACID Properties and Correctness of Transactions . . . . . . . . . . . . . . . . . .
11
2.3
QoS Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Providing Timeliness and Freshness Guarantees in Real-Time Databases
17
3.1
Flexible Freshness Management: QMF-1 . . . . . . . . . . . . . . . . . . . . . .
18
3.2
Flexible Freshness Management: QMF-2 . . . . . . . . . . . . . . . . . . . . . .
23
3.3
Architecture for QoS Management of Real-Time Data Services
. . . . . . . . . .
27
3.4
Performance Evaluation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.5
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Service Differentiation in Real-Time Databases
56
4.1
Performance Metrics and QoS Specification . . . . . . . . . . . . . . . . . . . . .
57
4.2
Differentiated Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
59
vii
Contents
5
6
7
viii
4.3
Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Secure Real-Time Transaction Processing with Timeliness Guarantees
80
5.1
Database Security Model and Performance Metrics . . . . . . . . . . . . . . . . .
82
5.2
Architecture for Security and Timeliness Guarantees . . . . . . . . . . . . . . . .
84
5.3
Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Related Work
105
6.1
Real-Time Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2
QoS Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.3
Performance Trade-Off in Real-Time Databases . . . . . . . . . . . . . . . . . . . 109
6.4
Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.5
Database Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.6
Feedback Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.7
Database Self-Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.8
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Conclusions and Future Work
115
7.1
Key Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
List of Figures
1.1
Transaction Processing Unaware of Timing Constraints . . . . . . . . . . . . . . .
2
2.1
Example of a User Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
Definition of Overshoot (V ) and Settling Time (T ) in Real-Time Databases . . . . .
14
2.3
Data Freshness Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.1
Update Policy Adaptations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.2
QoD Degradation in QMF-2 under Overload Conditions . . . . . . . . . . . . . .
26
3.3
Real-Time Data Management Architecture for QoS Guarantees . . . . . . . . . . .
28
3.4
QoS Management for Miss Ratio and Freshness Guarantees . . . . . . . . . . . . .
30
3.5
Miss Ratio/Utilization Controllers . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.6
Average Miss Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.7
Average Perceived Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.8
Average Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.9
Average Miss Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.10 Average Perceived Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.11 Average Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.12 Transient Performance of QMF-1 (EstErr = 1, AppLoad = 200%) . . . . . . . . . .
48
3.13 Average Performance of QMF-2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.14 Transient Performance of QMF-2 (Fixed-QoD = 0.5) . . . . . . . . . . . . . . . .
51
3.15 Transient Performance of QMF-2 (Fixed-QoD = 1) . . . . . . . . . . . . . . . . .
52
3.16 Average Performance of QMF-1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
ix
List of Figures
x
3.17 Average Performance of QMF-2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.18 Average Performance of Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.19 Transient Performance of QMF-1 (EstErr = 1, AppLoad = 200%, HSS = 10%) . . .
53
3.20 Transient Performance of QMF-2 (EstErr = 1, AppLoad = 200%, HSS = 10%) . . .
53
4.1
QoS Specification for Service Differentiation . . . . . . . . . . . . . . . . . . . .
58
4.2
Real-Time Database Architecture for Service Differentiation . . . . . . . . . . . .
60
4.3
Miss Ratio Differentiation and Target Freshness Support . . . . . . . . . . . . . .
61
4.4
Miss Ratio and Utilization Controllers . . . . . . . . . . . . . . . . . . . . . . . .
62
4.5
Average Miss Ratio for Basic-IMU . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.6
Average Miss Ratio for Basic-ODU . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.7
Average Miss Ratio for QMF-Diff . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.8
Average Perceived Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.9
Average Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.10 Average Miss Ratio for Basic-IMU . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.11 Average Miss Ratio for Basic-ODU . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.12 Average Miss Ratio for QMF-Diff . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.13 Average Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.14 Transient MR1 for Basic-ODU and QMF-Diff . . . . . . . . . . . . . . . . . . . .
73
4.15 Average Miss Ratio for Class 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.16 Average Miss Ratio for Class 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.17 Average Miss Ratio for Class 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.18 Average Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.19 Transient MR0 and MR1 in Experiment Set 3 (Fair Admission Control) . . . . . . .
77
4.20 Transient MR0 and MR1 in Experiment Set 3 (Prioritized Admission Control) . . .
77
4.21 Transient MR0 and MR1 in Experiment Set 4 (Uniform Access Pattern)
. . . . . .
77
4.22 Transient MR0 and MR1 in Experiment Set 4 (HSS = 10%) . . . . . . . . . . . . .
77
5.1
83
Access Restrictions in the Bell-LaPadula Model . . . . . . . . . . . . . . . . . . .
List of Figures
xi
5.2
STAR Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.3
Miss Ratio/Utilization Controllers . . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.4
Average Miss Ratio for Open . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.5
Average Miss Ratio for Open-AC . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.6
Average Miss Ratio for Covert-AC . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.7
Average Miss Ratio for STAR . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.8
Average Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.9
Average Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.10 Transient MR0 and MR1 for STAR . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.11 Transient MR0 and MR1 for STAR (PID Control) . . . . . . . . . . . . . . . . . .
97
5.12 Average MR0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
5.13 Average MR1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
5.14 Average Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
5.15 Transient Miss Ratio for STAR . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
5.16 Average Miss Ratio for STAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.17 Transient Miss Ratio for STAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.18 Transient Miss Ratio for STAR (PID Control) . . . . . . . . . . . . . . . . . . . . 101 5.19 Average Miss Ratio for STAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.20 Transient Miss Ratio for STAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.21 Transient Miss Ratio for STAR (PID Control) . . . . . . . . . . . . . . . . . . . . 103
List of Tables
1.1
Average Inter-Trade Times for S&P 500 Stock Items . . . . . . . . . . . . . . . .
7
3.1
Simulation Settings for Data and Updates . . . . . . . . . . . . . . . . . . . . . .
37
3.2
Simulation Settings for User Transactions . . . . . . . . . . . . . . . . . . . . . .
38
3.3
Fixed-QoD vs. Update Workload . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.4
Presented Sets of Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.1
Presented Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.1
Simulation Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.2
Load Relieved by QoS degradation . . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.3
Presented Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
xii
Chapter 1 Introduction
1.1 Motivation The demand for real-time data services is increasing in many important applications including e-commerce, online stock trading, agile manufacturing, sensor data fusion, traffic control, and telecommunications network management. In these applications, transactions should be processed within their deadlines, i.e., before the market or automated manufacturing status changes, using fresh (temporally consistent) sensor data1 that reflect the current real-world status such as current stock prices or manufacturing status. Deadline misses in these applications could lead to the loss of profit or product quality due to possible changes in the market or manufacturing state. For example, the $420 million revenue loss in e-commerce had been reported in 1999 due to the late, i.e., nonreal-time, transaction processing [7]. Further, databases may process transactions using outdated information when the data temporal consistency is violated. Existing (non-real-time) databases do not directly support timing constraints and data temporal consistency [78]. For example, consider Figure 1.1. Transaction A starts at time 1 and locks data item X at time 3. It has a deadline at 20 and has an execution time of 10. Transaction B, which has an execution time of 2 and a deadline at 7, arrives at time 3 and tries to read X. Existing database protocols will block transaction B. As a result, transaction B misses its deadline at time 7. Observe 1 In
this dissertation, we do not restrict the notion of sensor data to the data provided by physical sensors. Instead, we consider a broad meaning of sensor data. Any data item, whose value reflects the time-varying real-world status, is considered a sensor data item.
1
Chapter 1. Introduction
Time 1 TA D= 30
2
2 3 4 5 W(X)
6 7 8 9 1011 ...
R(X) Deadline Miss TB D= 7
Figure 1.1: Transaction Processing Unaware of Timing Constraints that both A and B could have met their deadlines if transaction A is preempted at time 3 to let transaction B, with an earlier deadline, execute first. Therefore, time-cognizant scheduling and concurrency control protocols are necessary for real-time transaction processing. Also, sensor data should be maintained fresh. For these reasons, Lockheed Martin found that they could not use a commercial database system for military real-time applications, and implemented a real-time database system called Eaglespeed. TimesTen, Probita, Polyhedra in the UK, NEC in Japan, and ClusterRa in Norway have also implemented real-time databases for similar reasons. Even though the need for real-time data services has been demonstrated, these and other real-time database systems are only initial attempts with many remaining issues such as timeliness and data freshness guarantee issues that we investigate in this dissertation.
1.2 Problems Real-time databases need to process transactions within their deadlines using fresh data, but meeting these fundamental requirements is very challenging for several reasons:
User service requests and data access patterns are not known a priori, but can vary widely based on the market, manufacturing, or network status. For example, transactions in stock trading may read varying sets of stock prices, and perform different arithmetic/logical oper-
Chapter 1. Introduction
3
ations considering the current market status. Therefore, it is very hard, if at all possible, to predict precise workloads and reserve computational resources needed for real-time transaction processing.
Real-time transactions can compete for computing resources and/or contend over data. Transactions can be rolled back or restarted due to data and resource conflicts; high data and resource contention may result in many deadline misses.
Timeliness and freshness requirements can conflict [8]. By preferring user requests to updates, timeliness is improved; however, data freshness is degraded. Alternatively, the freshness increases if updates receive a higher priority. Thus, it is hard to meet timing and data freshness constraints simultaneously.
We also consider the problem of secure real-time transaction processing in which transactions can be processed in a secure and timely manner. Unfortunately, database security requirements and timing constraints can conflict in the multi-level security model [10,75,76], which is used to enforce the mandatory access control in most secure databases such as Sybase Secure SQL Server [80], Trusted Oracle [58], and Informix-OnLine/Secure [33]. Preventing illegal information transfer between transactions belonging to different security levels might increase the miss ratio. Alternatively, the miss ratio can be improved at the cost of potential compromise of database security. (A detailed discussion is given in Chapter 5.)
1.3 Approach The main objective of this dissertation research is providing guarantees on deadline miss ratio, data freshness, and certain security property even in the presence of conflicting requirements (i.e., timeliness vs. data freshness or security requirements) and unpredictable workloads and data access patterns, which may cause varying degrees of data/resource contention. To achieve these goals, we have taken a pioneering approach that maps the real-time data management problem to a QoS management problem. Although real-time databases and QoS man-
Chapter 1. Introduction
4
agement issues have been studied separately, database QoS management issues have hardly been explored possibly due to many challenges as discussed before. As a result, a database system, which often shows unpredictable performance, can become a performance bottleneck in information systems?the backbone of the digital infrastructure. Using our QoS-aware approach, which can guarantee the required QoS in real-time database applications such as e-commerce, both clients and service providers can be satisfied by receiving required services and getting rewards for services. In this dissertation, we investigate several important problems to guarantee the required quality of real-time data services, in terms of timeliness, freshness, and security as discussed in the following section.
1.4 Contributions The key contributions are (1) defining quality of real-time data metrics to form the basis for QoS management in real-time databases, (2) developing flexible freshness management schemes and a QoS management architecture that can achieve the near-optimal miss ratio and data freshness, comparable to a clairvoyant oracle (discussed in Section 1.4.2), (3) developing a service differentiation architecture that can guarantee the required data freshness and differentiated miss ratio bounds among several service classes, (4) developing a transaction processing mechanism that can support both the required miss ratio and database security property, and (5) designing workloads considering real-time data freshness semantics unlike most existing real-time database research. To our best knowledge, our QoS management architecture and service differentiation scheme are the first in real-time database research, which can provide guarantees on data freshness and (differentiated bounds on) miss ratio even in the presence of unpredictable workloads and data access patterns. Further, no existing real-time database work supports both security property and real-time performance guarantees as we do. More details of our contributions are given in the following subsections.
Chapter 1. Introduction
5
1.4.1 QoS Metrics Appropriate QoS metrics are essential to directly represent and support the user required QoS. In this dissertation, we present several QoS metrics to let a DBA (database administrator) specify the required quality of real-time data services in terms of deadline miss ratio and novel data freshness metrics.2 We apply not only average but also transient miss ratio metrics to support the consistent real-time database performance even when the system is in the transient state. We also introduce novel notions of perceived freshness, QoD (Quality of Data), and flexible validity intervals to dynamically balance potentially conflicting miss ratio and data freshness requirements. We define the data freshness metrics based on the observation that the entire data in a real-time database may not always have to be maintained fresh as long as users perceive the desired data freshness. Therefore, these freshness metrics provide a foundation for flexible data freshness management. (A detailed discussion about data freshness metrics is given in Chapter 2.)
1.4.2 QoS Management Architecture Using the QoS metrics, we have developed a QoS management architecture to guarantee the required miss ratio and data freshness in real-time main memory databases. We apply a feedbackbased approach to control the miss ratio to be below the required average and transient thresholds. In our approach, the system behavior can be dynamically adapted in the feedback control loop using admission control and flexible freshness management schemes that can adjust the data freshness, if necessary to meet the required average/transient miss ratio, as long as the required freshness is not violated. Our data freshness metrics and flexible freshness management schemes are novel in the sense that the existing data freshness (temporal consistency) metric and database update policy, well accepted in the real-time database research such as [8, 41, 66, 87], are fixed and not adaptable regardless of the current system status. For performance comparisons, we have devised several baselines which model the widely accepted transaction processing schemes including the best existing algorithms for miss ratio and 2 We consider the database security a correctness criterion, which is all or nothing, rather than a performance metrics that can be traded off, if necessary. A detailed discussion is given in Chapter 5.
Chapter 1. Introduction
6
freshness trade-off. We have also developed a theoretical oracle which can achieve the optimal miss ratio and data freshness by taking advantage of a complete future knowledge of data accesses. The oracle schedules an update only if any transaction will access the corresponding data item before the next update. In this way, it can minimize the update workload while providing a perfect data freshness perceived by user transactions (described in detail in Section 3.4.2). In a simulation study, our QoS management architecture showed a significant performance improvement compared to the baselines. Further, our approach has achieved the near optimal miss ratio and data freshness, comparable to the clairvoyant oracle.
1.4.3 Service Differentiation In many real-time data service applications, transactions can be classified according to their relative importance, e.g., premium, business, and economy classes in e-commerce. By providing preferred services to the higher priority class(es), e.g., premium class, limited system resources can be effectively utilized, especially under overload conditions. Consequently, the profit (product quality) in e-commerce (agile manufacturing) could increase. Nevertheless, service differentiation issues have hardly been studied in real-time databases. In addition, an existing service differentiation work neither supports upper bounds on miss ratio nor considers data freshness. To handle this problem, we classify transactions into several classes according to their relative importance, and define differentiated miss ratio metrics to let a DBA specify the degree of required service differentiation in terms of miss ratio. We have extended the feedback-based miss ratio control scheme to support differentiated miss ratio bounds among several service classes. Our approach can also provide the required data freshness even given dynamic workloads and data access patterns.
1.4.4 Secure Real-Time Transaction Processing We have developed a novel approach to support secure real-time transaction processing in the context of multi-level security model. Security is critical for the success of real-time data services. Improper management of critical data, e.g., business data or C 3 I information, may lead to the failure
Chapter 1. Introduction
7
of an entire system. At the same time, real-time transactions should be processed within their deadlines. Current solutions focus on either preventing information leakage between different security levels, or compromising security to improve the real-time performance. In contrast, our approach bridges the gap between timeliness and security requirements; it does not only support the security property, but also gives real-time performance guarantees. Using our approach, for example, e-commerce users do not have to worry about unbounded deadline misses or illegal disclosure of sensitive information.
1.4.5 Data Freshness Semantics Real-time databases usually monitor the current real-world state using periodic updates, e.g., periodic sensor readings and stock price tracking. Therefore, the frequency of sensor data updates should be determined considering the rate at which the real-world status changes (or may change) [66]. Table 1.1: Average Inter-Trade Times for S&P 500 Stock Items Stock Item Average Time
Item1
Item2
Item3
Item4
Item5
Item6
189ms
4.41sec
8.84sec
16.89sec
22.03sec
25.99sec
Existing real-time database work such as [8, 41, 66, 87] do not consider actual data freshness semantics, mainly determined by the update frequency, for performance evaluation. Although some real-time applications (e.g., online stock trading) use commercial databases such as TimesTen [81], data freshness semantics are not open to the public. This is a serious problem in real-time database research, especially for workload generation. Our work alleviate the problem by analyzing the freshness semantics of stock prices. More specifically, we have studied the real-time NYSE trade traces streamed into the Bridge Center for Financial Markets at the University of Virginia. From 06/03/02 to 06/26/02, we measured the average time between two consecutive trades for tens of S&P 500 stock items. In Table 1.1, most representative ones are presented. (The other stock items not presented in Table 1.1 showed similar
Chapter 1. Introduction
8
inter-trade times.) As shown in Table 1.1, the shortest average inter-trade time observed is 189ms for Item1 , while the longest one observed is 26sec for Item6 .3 From this study, we determined the range of sensor update periods for our simulation. For each sensor data object Oi , its update period Pi is uniformly selected in a range (100ms, 50sec). The shortest update period selected for our experiments, i.e., 100ms, is approximately one half of the average inter-trade time of Item1 shown in Table 1.1. In contrast, the longest update period, i.e., 50sec, is approximately twice the average inter-trade time of Item6 to model a wider range of update periods. As a whole, our approach can provide real-time data services for many important applications by guaranteeing the required miss ratio and data freshness. For example, our approach can help stock trading and agile manufacturing achieve the desired profit or product quality by supporting the required QoS. Our service differentiation scheme can provide basic support to maximize the profit or product quality, especially under overload, by preferring high priority class transactions that can bring relatively large rewards. Also, using our approach real-time transactions can be processed in a timely and secure manner enforcing the mandatory access control.
1.5 Organization The rest of this dissertation is organized as follows. In Chapter 2, we discuss our real-time database model and QoS metrics. Chapter 3 presents our flexible freshness management schemes and QoS management architecture that can support the required miss ratio and data freshness. In a simulation study, the performance of our approach is compared to several baseline approaches for various workloads and access patterns. Chapter 4 presents our differentiated miss ratio metrics and service differentiation scheme. The performance of our approach is evaluated over a large range of workloads and access patterns. Chapter 5 presents our secure real-time transaction processing mechanism. Interactions and interference between timeliness and security requirements are discussed. Sets of simulation studies are performed to show the applicability of our approach. Related work is 3 We
have deleted the actual stock symbols for privacy purposes.
Chapter 1. Introduction
9
discussed in Chapter 6. Finally, Chapter 7 concludes the dissertation, and discusses the avenues for future work.
Chapter 2 Real-Time Database Model and Quality of Real-Time Data Service Metrics
In this chapter, we describe the database model, real-time transaction types, and deadline semantics that are adopted considering their applicability for QoS management in real-time databases. We also describe our QoS metrics.
2.1 Real-Time Database Model We consider a main memory database model, in which the CPU is considered the main system resource. Main memory databases are appropriate for real-time applications in which transactions have deadlines [21]. Main memory databases have been increasingly applied to real-time data management such as stock trading, e-commerce, and voice/data networking due to decreasing main memory cost and their relatively high performance [8, 63, 81]. In this dissertation, we classify transactions as either user transactions or sensor updates. Periodic updates capture the continuously changing real-world state. Based on the current real-world state reflected in the real-time database, e.g., current stock prices, user transactions execute arithmetic, logical operations to take an action, e.g., sell or buy stock items, as shown in Figure 2.1. As another example, process control transactions in agile manufacturing may issue control commands, if necessary, considering the current process state, which is periodically monitored by periodic
10
Chapter 2. Real-Time Database Model and Quality of Real-Time Data Service Metrics
11
sensor updates.
Begin transaction Read a stock price S1 Read a stock price S2 ................................ Read a stock price SN Compute average price variation (%) Sell stock items 1 ? N if the average price is increased by more than 10% Commit End transaction
Figure 2.1: Example of a User Transaction
We apply firm deadline semantics, in which transactions add value to the system only if they finish within their deadlines. Firm deadline semantics are common in many real-time database applications. A late commit of a real-time transaction may incur the loss of profit or product quality, resulting in wasted system resources, due to possible changes in the market or manufacturing status.
2.2 ACID Properties and Correctness of Transactions To protect data against concurrent transaction execution and possible system failures, a database should ensure four properties of transactions, called ACID (Atomicity, Consistency, Isolation, and Durability) properties [24, 65].
Atomicity: Each transaction execution should be atomic; that is, either all operations in one transaction are carried out or none are. A database management system should eliminate the
Chapter 2. Real-Time Database Model and Quality of Real-Time Data Service Metrics
12
effects of incomplete transactions when recovering from a system crash.
Consistency: Each individual transaction, run without concurrent executions of other transactions, should preserve the consistency of the database. For example, a fund transfer between bank accounts should not change the total amount of money in the accounts. Therefore, users and application programs are responsible for maintaining consistency.
Isolation: Transactions should be isolated from other concurrently running transactions even though their executions can interleave. To achieve the isolation, concurrent transactions should be serializable; that is, concurrent execution of transactions must be equal to some serial execution of the transactions.
Durability: Once a transaction is completed successfully, its effects should persist even if the system crashes.
Atomicity and durability properties are usually supported by logging and recovery. The logging and recovery schemes are well studied in main memory databases,1 and implemented in commercial systems such as [63, 81] for high performance transaction processing. Therefore, we assume that efficient logging and recovery, which do not severely affect the performance of the front-end main memory database processing real-time transactions, are supported (possibly via a special I/O processor and a backup copy of the database in a stable storage). The isolation property can be supported by concurrency control [65]. For concurrency control, we use two phase locking high priority (2PL-HP) [1, 32], in which a low priority transaction is aborted and restarted upon a conflict. We selected 2PL-HP, since it is free of priority inversion while supporting the isolation property. Without priority inversion, 2PL-HP can provide basic support for service differentiation and security property (discussed in Chapters 4 and 5.) Other real-time concurrency control techniques such as the ones presented in [2,25–27,31,55] allow priority inversions, or apply optimistic concurrency control techniques that are rarely applied to real systems. Further, 1 Refer to [21]
for a good introduction. In [72], real-time logging and recovery protocols are presented. The presented protocols can recover critical data within predictable time bounds using logs stored in non-volatile RAM during normal operation.
Chapter 2. Real-Time Database Model and Quality of Real-Time Data Service Metrics
13
2PL-HP is deadlock-free since data conflicts are immediately resolved based on transaction priorities.2 Therefore, there is no need for computationally expensive deadlock detection. (A more detailed discussion of real-time concurrency control policies is given in Chapter 6). Generally, a group of transactions are considered correct if they are serializable [65, 67]. Although serializability is the most-widely accepted correctness criterion, it is not sufficient to specify the correctness of real-time transactions that have timing and data freshness constraints as well. Therefore, we consider transactions correct only if they finish within their deadlines using fresh data while meeting the serializability requirement. In Chapter 3, we give a detailed discussion of our database architecture including transaction scheduling, data freshness checking, and concurrency control schemes to support serializability and timing/freshness constraints.
2.3 QoS Metrics We define average/transient miss ratio and novel data freshness metrics to specify the required quality of real-time data services as follows.
2.3.1 Deadline Miss Ratio The deadline miss ratio is one of the most important performance metrics in real-time applications. For admitted transactions, the deadline miss ratio is3 : MR = 100
#Tardy (%) #Tardy + #Timely
where #Tardy and #Timely represent the number of transactions that have missed and met their deadlines, respectively. A DBA can specify a tolerable miss ratio threshold, e.g., 1%, for a specific real-time database application. As discussed before, database workloads and data access patterns might vary dynamically. For this reason, we assume that some deadline misses are inevitable and a 2 When two transactions have the same priority possibly due to the same deadline, we give a preference to the one which arrived earlier to resolve the conflict. 3 In Chapter 3, we show that our approach significantly improves the real-time database throughput compared to several baseline approaches that do not apply admission control, while supporting the required miss ratio and data freshness.
Chapter 2. Real-Time Database Model and Quality of Real-Time Data Service Metrics
14
single deadline miss does not incur a catastrophic consequence. We consider a few deadline misses tolerable unless they exceed the threshold specified by a DBA. Miss Ratio (%)
Miss Ratio Threshold
V
( MR )
t
Time (sec)
T
Figure 2.2: Definition of Overshoot (V ) and Settling Time (T ) in Real-Time Databases Long-term performance metrics, e.g., average miss ratio, are not sufficient to specify the required performance of dynamic systems whose performance could change significantly in a relatively short time interval [52, 68]. For this reason, transient performance metrics such as overshoot and settling time shown in Figure 2.2 are adopted from control theory to specify the required performance of real-time systems [52]:
Overshoot (V ) is the worst-case system performance in the transient system state. In this dissertation, it is considered the highest miss ratio over the miss ratio threshold (MRt ) in the transient state.
Settling time (T ) is the time for a transient miss ratio overshoot to decay. After T , the realtime database should enter the steady state, in which the miss ratio is within the range (0, MRt + 0:01 MRt ).
2.3.2 Data Validity Intervals and Freshness Metrics In real-time databases, validity intervals are used to maintain the temporal consistency between the real-world state and sensor data in the database [66]. A sensor data object Oi is considered fresh (temporally consistent), if (current time ? timestamp(Oi )
avi(Oi )) where avi(Oi ) is the absolute
Chapter 2. Real-Time Database Model and Quality of Real-Time Data Service Metrics
15
validity interval of Oi .4 For Oi , we set the update period Pi = 0:5 avi(Oi ) to support the sensor data freshness, similar to [66]. To specify and manage the data freshness (i.e., temporal consistency), we consider two key freshness metrics, namely database freshness and perceived freshness.
Perceived Freshness Sensor Data Accessed by Timely Transactions
Entire Sensor Data
Database Freshness
Figure 2.3: Data Freshness Metrics
Database Freshness: Database freshness, also called QoD (Quality of Data) in this dissertation, is the ratio of fresh (sensor) data to the entire data in a real-time database as shown in Figure 2.3.
Perceived Freshness (PF): In contrast to database freshness, perceived freshness is defined for the data accessed by timely transactions as shown in Figure 2.3. Let Naccessed represent the number of all data accessed by timely transactions. Also, let N f resh stand for the number
4 Real-time databases may include derived data such as stock composite indexes that are derived from several stock prices. In this dissertation, we do not consider the derived data management and relative validity intervals. We reserve derived data management for future work.
Chapter 2. Real-Time Database Model and Quality of Real-Time Data Service Metrics
16
of fresh data accessed by timely transactions. Perceived Freshness = 100
N f resh (%) Naccessed
Since we apply firm deadline semantics, we guarantee data freshness in terms of perceived freshness. As long as the target perceived freshness is guaranteed, the QoD (database freshness) can be traded off, if necessary, to improve the miss ratio under overload. This approach can be effective considering potentially high update workloads, e.g., stock price updates during the peak trade time [8], which may cause many deadline misses. In the remainder of this dissertation, we use and extend the QoS metrics described in this chapter.
Chapter 3 Providing Timeliness and Freshness Guarantees in Real-Time Databases
In this chapter, we present a novel real-time main memory database architecture called QMF (a QoS management architecture for Miss ratio and Freshness guarantees). A key advantage of QMF is that QMF can provide QoS guarantees (in terms miss ratio and data freshness) for admitted transactions even in the presence of unpredictable workloads and data access patterns. To support the required QoS, QMF dynamically adjusts the system behavior in the feedback control loop using admission control and flexible freshness management. We present an adaptive update policy to maintain the freshness in a cost-effective manner using the notion of perceived freshness discussed in Chapter 2. Initially, all data are updated immediately when their new sensor readings arrive. Under overload, some sensor data can be updated on demand, if necessary, to improve the miss ratio (as long as the target perceived freshness is supported). The adaptive update policy can effectively balance conflicting timeliness and freshness requirements. However, it has a potential disadvantage. Some stale data accesses could be allowed to meet transaction deadlines although the chances are small.1 When a data object is updated on demand, a real-time transaction accessing that data may have to use an old version of the data (outdated since the last on-demand update) to meet its deadline [8]. 1 In
Section 3.4 we show that we can support 98% target perceived freshness and 1% miss ratio threshold using the adaptive update policy (with the feedback-based miss ratio control and admission control schemes). This approach is acceptable for some applications in which a stale data access is undesirable, but not fatal, e.g., when a transaction can extrapolate current values from the stale data. However, it is still more desirable to maintain data as fresh as possible.
17
Chapter 3. Providing Timeliness and Freshness Guarantees in Real-Time Databases
18
To prevent potential deadline misses (or stale data accesses) due to the delay for on-demand updates, we present an alternative approach, in which all data are updated immediately. In this approach, we introduce novel notions of QoD and flexible validity intervals, which refines the database freshness metrics discussed in Chapter 2, to manage the freshness. We also provide several QoD parameters to let a DBA specify the acceptable range of QoD. When overloaded, update periods of some sensor data can be relaxed within the acceptable range of QoD to reduce the update workload, if necessary. However, sensor data are always maintained fresh in terms of flexible validity intervals. Therefore, the age of sensor data is always bounded. (A detailed discussion is given in Section 3.2.) To demonstrate the applicability of QMF, we have performed a simulation study for a large range of workloads and data access patterns. Based on performance evaluation results, we show that QMF can support stringent QoS requirements. In contrast, several baseline approaches, which model widely accepted transaction processing mechanisms, fail to support the specified miss ratio and/or data freshness. We also compare the performance of our approach to the clairvoyant oracle. The rest of this chapter is organized as follows. Two alternative approaches, which can flexibly manage the data freshness, are presented in Sections 3.1 and 3.2. In the remainder of this chapter, we follow a convention that classifies QMF as QMF-1 or QMF-2 according to the freshness management scheme. In Section 3.3, our QoS management architecture is described. Section 3.4 presents the performance evaluation results. Finally, Section 3.5 summarizes the chapter.
3.1 Flexible Freshness Management: QMF-1 In this section, we describe a cost-benefit model for sensor data updates. Using this model and data freshness metrics introduced in Chapter 2, we present an adaptive update policy called QMF-1.
3.1.1 Cost-Benefit Model for Updates To balance the update and transaction workload efficiently, we introduce a cost-benefit model for sensor data updates as follows. The cost is defined as the update frequency of a sensor data object.
Chapter 3. Providing Timeliness and Freshness Guarantees in Real-Time Databases
19
Intuitively, the more frequent is the update, the higher is the cost. We assume that the frequency of periodic updates is known to the database system.2 To consider the benefit, access frequency is measured for each data object. Updating a frequently accessed data can produce a relatively high benefit. To quantify the cost-benefit relationship, we define Access Update Ratio (AUR) for a sensor data object Oi , which represents the importance of being fresh:
AUR[i] =
Access Frequency[i] Update Frequency[i]
(3.1)
Unfortunately, the access frequency may have a large deviation from one sampling period to another. To smooth the potentially large deviation, we take a moving average of the access frequency (AF) for Oi in the kth sampling period: SAFk [i] = a SAFk?1 [i] + (1 ? a) AFk [i]
(3.2)
where 0 a 1. As the value of a gets closer to 0, only the recent access frequencies are considered to compute the moving average. In contrast, the wider horizon will be considered to compute the moving average as a gets closer to 1. Since the Update Frequency[i] of Oi in a sampling period is known, we can compute AUR for Oi :
AUR[i] =
SAF [i] Update Frequency[i]
(3.3)
1, the benefit of updating Oi is worth the cost, since Oi is accessed at least as frequently as it is updated. For simplicity, let us call a data item hot if its AUR 1. Otherwise, we If AUR[i]
call it cold. Note that the notion of AUR does not depend on a specific access pattern or popularity model. It can be derived simply from the update and access frequency for each data object. Therefore, it 2 We can also apply our cost-benefit model to aperiodic updates by monitoring the update frequency, similar to the access frequency monitoring (discussed in the remainder of this subsection). However, in this dissertation we only consider periodic updates that are commonly adopted in real-time databases to support the temporal consistency of sensor data [41, 66, 87].
Chapter 3. Providing Timeliness and Freshness Guarantees in Real-Time Databases
20
greatly simplifies our cost-benefit model, and makes the model robust against the potential unpredictability in data access patterns.
3.1.2 Adaptive Update Policy From the cost-benefit model, we observe that it is reasonable to update hot data immediately. If a hot data item is out-of-date when accessed, a multitude of transactions may miss their deadlines waiting for the update. Alternatively, it may not be necessary to immediately update cold data when overloaded. Only a few transactions may miss their deadlines waiting for the update. Under overload, we can save the CPU utilization by updating some cold data on demand. (Cold data could always be updated on demand regardless of the current system load. However, that approach may increase the response time of transactions accessing cold data.)
Dimm
Dimm AUR =1
D = Dimm
(a) Initial State
AUR < 1
Dod
Dod
(b) Moderately Loaded State
(c) Overloaded State
Figure 3.1: Update Policy Adaptations For example, consider Figure 3.1 in which D represents the set of all sensor data in the database. Dimm is the set of data updated immediately, while Dod stands for the set of data updated on demand. Since a data object is updated either immediately or on demand in our approach, D = Dimm and Dimm
TD
od =
SD
od
Ø. Initially, every data is updated immediately. As the load increases, a larger
fraction of cold data objects is updated on demand. We call this QoD degradation because lazy updates reduce the QoD (i.e., database freshness). In contrast, we need to switch the update policy back to the immediate one for some cold data when the target perceived freshness is violated. We call this QoD upgrade. A detailed description of QoD upgrade and degradation is given in the following subsections.
Chapter 3. Providing Timeliness and Freshness Guarantees in Real-Time Databases 3.1.2.1
21
QoD Degradation: Miss Ratio Adjustment
By degrading the QoD, we can reduce the update workload. A remaining question is how to estimate the CPU utilization saved from the QoD degradation. The CPU utilization saved due to a QoD degradation for a data object Oi is approximately: δWi = AET (Oi ) [Update Frequency[i] ? SAF [i]]
(3.4)
where AET (Oi ) is the average execution time to update Oi . Note that AET (Oi ) can be measured either online or offline without a significant error since each sensor update is known a priori and fixed in our real-time database model. In our approach, feedback controllers compute the workload adjustment, called ∆W , required to support the specified miss ratio. When the current miss ratio is over the specified threshold, e.g., 1%, ∆W becomes negative to request the workload reduction. When ∆W
0). A key issue in QoD upgrade is avoiding a
potential miss ratio overshoot in the next sampling period, while improving the perceived freshness as needed at the same time. For this purpose, we define the perceived freshness error and derive the upgrade bound as follows. Given a target perceived freshness PFt , the current perceived freshness PF can be measured in a sampling period. The perceived freshness error in a sampling period is:
8 > < 0 if PF PFt ; PFerror = > : PFt ? PF if PF < PFt :
(3.6)
A non-zero PFerror indicates that on-demand updates have failed to provide the target perceived freshness in the current sampling period. Therefore, some of these data, especially ones having relatively high AUR values, should be updated immediately in the next sampling period. The freshness can be improved approximately in proportion to the number of data moved from Dod to Dimm . We derive an upgrade bound K in terms of the number of data whose update policy will be upgraded. Let D0imm represent the set of data to be updated immediately in the next sampling period after the upgrade. The upgrade bound is determined in proportion to the current PFerror and the cardinality of the set Dod : K = jD0imm j?jDimm j PFerror jDod j To upgrade the QoD for Oi
2
(
(3.7)
D0imm ? Dimm ), the extra CPU utilization of δWi in Eq. 3.4 is
required to switch the update policy of Oi back to the immediate policy. Due to the approximation and unpredictable workloads/access patterns, our QoD adaptation may not be precise. However, the target miss ratio and freshness can be achieved by continuously adjusting the QoD based on the miss ratio measured in the feedback loop.
Chapter 3. Providing Timeliness and Freshness Guarantees in Real-Time Databases
23
3.2 Flexible Freshness Management: QMF-2 In this section, we consider an alternative approach for freshness management called QMF-2. Novel notions of QoD and flexible validity intervals are discussed. A detailed description of QoD parameters and flexible freshness management is given. We also give a QoS specification that will be used to illustrate the applicability of QMF against unpredictable workloads and access patterns.
3.2.1 Quality of Data and Flexible Validity Intervals In QMF-2, all sensor data are updated immediately to avoid the possible deadline misses or stale data accesses due to on-demand updates as discussed before. When overloaded, the update periods (instead of the corresponding update policy) of relatively less critical sensor data, e.g., data with low AUR values in stock trading or slow moving friendly helicopters in target tracking, can be increased to improve the miss ratio. 3 In QMF-2, we assume that the relative importance of data such as AUR is available to a DBA working for a specific application, e.g., a financial trading or target tracking. This is a reasonable assumption, since a DBA dealing with a specific application (rather than real-time database developers) usually have better understandings about application specific data semantics. For example, the AUR of stock prices can be available (or measured) at least to distinguish between hot and cold data. Also, friend and enemy aircraft can receive different importance in target tracking especially given a complex combat scenario.4 Given this assumption, we define the current QoD when there are N sensor data objects in a real-time database:
QoD =
100 N
" N
Pi ∑ Pimin i=1 new
# (%)
When there is no QoD degradation, the QoD = 100% since Pinew
= Pimin
(3.8)
for every sensor data object
Oi in the database. The QoD decreases as Pinew increases. Using this metric, we can measure the 3 Task
period adjustment is previously studied to improve the miss ratio in real-time (non-database) systems such as [46, 48]. However, database issues such as data freshness are not considered in these work. 4 Ideally, precise rankings of data importance can optimize the QoD by degrading the QoD of the least critical data item first, if necessary. However, our approach can still manage the QoD in a flexible manner even given an approximate information of data importance (at the cost of possibly suboptimal QoD).
Chapter 3. Providing Timeliness and Freshness Guarantees in Real-Time Databases
24
current QoD for sensor data in real-time databases. To maintain the freshness of a sensor data item after a possible QoD degradation, we define a notion of flexible validity intervals ( f vi). The traditional notion of absolute validity intervals is not applicable to maintain the freshness in QMF-2 since the update period can be adapted. Initially, f vi = avi for all data. Under overload, the update period Pi for a less critical data object Oi can be relaxed. After the QoD degradation for Oi , we set f vinew (Oi ) = 2 Pinew to maintain the freshness of Oi by updating it at every Pinew . Accordingly, Oi is considered fresh if (current
time ? timestamp(Oi ) f vinew (Oi )). Since all sensor data are maintained fresh in terms of
(flexible) validity intervals, QMF-2 supports the 100% perceived freshness; that is, the age of each sensor data is always bounded by fvi. Therefore, the QoD defined in Eq. 3.8 is the only freshness metric in QMF-2.
3.2.2 QoD Parameters A DBA, who is aware of application specific real-time data semantics, can specify the required QoD using the following QoD parameters.
Ddegr : A DBA can specify a certain set of sensor data Ddegr , e.g., the set of data with AUR
