university of virginia qos in real-time data services and stream processing sang h. son department...

University of Virginia

QoS in Real-Time Data Services and Stream

ProcessingSang H. Son

Department of Computer Science

University of VirginiaCharlottesville, Virginia 22904

[email protected]


Outline• Introduction to real-time systems and data

services• Trends in real-time system applications• Example applications and benefits• QoS management in real-time data services

– QoS management architectures and metrics– Differentiated services– Replication (full and dynamic)– Derived data

• Stream data• Challenges and research issues• Summary


• Input– current state (view) update– tasks to be performed by real-time applications

• Output– actions to change real world situation– information to be delivered by certain

deadlines

Real

WorldReal-Time

Applications

Input

Output


Real-Time Systems• Real-time systems

– timeliness, freshness, and predictability– typically embedded in a large complex system– explicit/implicit timing constraints (soft, firm, hard)

• A large number of applications– aerospace and defense systems, nuclear systems,

robotics, process control, agile manufacturing, network and traffic management, multimedia computing, web-based information services, interactive graphics, wireless sensor networks, and medical systems

• Rapid growth in research and development– workshops, symposia, journals– standards (POSIX, RT-Linux, RT-CORBA, RT-Java,

…)


Trends in Real-Time Applications

• Soft real-time requirements rather than hard ones– much wider applications– relates well with the notion of QoS– soft is harder to deal with than hard

• Operate in unpredictable environments– WCET too pessimistic or high variance in execution

time– unbounded arrival rate; overload unavoidable

• Need to support multi-dimensional requirements– real-time, security, fault-tolerance, power, size, cost– conflicting resource requirements and system

architecture• Embedded and integrated with the physical world• QoS becomes a key concern


Example Application: E-Business

• Performance-critical applications in unpredictable environments– open systems on the Internet: e-business servers, web hosting– data-driven systems: real-time databases, smart spaces

arrival rate?resource requirement?

delay?congested?

User population?Processing power?

Service delay?

Throughput?Differentiatio

n?

Resources?


Example Application: Interactive Rendering

• Interactive rendering of large-scale geometric objects• Important in many areas:

– scientific and medical visualization– architectural and industrial CAD– training (military, police, pilot, …)– entertainment industry

• Challenge: 3-D models are getting bigger more rapidly than the computing engines are getting faster

• Approach: QoS management to satisfy the timeliness


Courtesy General Dynamics, Electric Boat Div.

Big Models: Submarine Torpedo Room

1994: 700,000 polygons


Big Models: Coal-fired Power Plant

1997:13 million polygons


Big Models:Double Eagle Container Ship

2000:82 million polygons

Courtesy Newport News Shipbuilding


Big Models:The Digital Michelangelo

Project2000 (David):56 million polygons

2001 (St. Matthew):372 million polygons

Cou

rtes

y D

igita

l Mic

hela

ngel

o P

roje

ct


Application: Embedded Systems

• Aircraft control

• Wristwatch

• Cell phones

• Internet appliances

• Process Control

• Air Traffic Control

• 64 Processors in automobiles

• Smart Spaces

• Intelligent highways

• Sensor/Actuator/CPU clouds with mobile entities

• Smart dust


Looking into Future Internet“… in the thirty-odd years since its invention,

new uses and abuses, along with the realities that come with being a fully commercial enterprise, are pushing the Internet into realms that its original design neither anticipated nor easily accommodates.”

--- NSF Workshop Report 2005

• Current Internet limitations– Architectural limitations, and things are

getting worse– Ossification – very hard to make changes,

from the research community’s point of view


NSF FIND/GENI

• New paradigm• Architectures for network and protocol• Distributed systems and services

• Emerging disruptive technologies– Sensors and sensor networks– Mobile wireless devices– …


Emerging Applications for FIND

• Digital living 2010– Users will be surrounded by ubiquitous devices,

sensors, and systems, connected by Internet– Cell phones, PDA, laptops, car, smart buildings

and homes … • Networked embedded systems

– Intelligent highway systems– Critical infrastructures (e.g., power grids)

• NEON: National ecological observatory network• Key element:

– Connecting the physical world with cyber world


Cyber-Physical Systems

BodyNetworks

Road and Street Networks

Battlefield Surveillance

VehicleNetworks

IndustrialNetworks

BuildingNetworks

Environmental Monitoring


Implications on Future Internet • New Internet architecture must accommodate

evolving diverse components and technologies– Diverse devices: cell phones, PDA, laptops,

sensors– Different wireless communication

technologies• Need to consider multiple/competing goals

– Timeliness and throughput– Priority and fairness– Reliability and security– Fault-tolerance and delay-tolerance

• Key requirement: Real-time and QoS


Real-Time Data Services• Critical in real-time applications

– real-time computing needs to process data:

real-world applications require timely access to data that may have temporal property

– many applications become sophisticated in their data needs: efficient access to real-time data

– applications require different levels of quality (QoS) for diverse classes of tasks and operations

• Function of real-time data services– accessing data from the environment,

processing it in the context of information (static or dynamic), for providing timely, context-aware, and temporally correct response


QoS Management in Real-Time Data• Motivation

– increasing demands for real-time data services• web-based information services and e-business• sensor networks• location-aware services in mobile networks

– temporary overload and service degradation inevitable

• Service quality: QoS parameters– timeliness– data freshness– degree of imprecision – behavior in transient state: overshoot, settling

time– data completeness in stream data


System Overview

Temporal Data Non-Temporal Data

Incoming sensor data values

Real-TimeTransactionsAnd Queries

. . .

PersistentData Stream

Queries…

SystemUpdates

Real-Time Databases

Site 1

Site 3

Site 2

…

…

Persistentqueryresults

Quality-of-Service Manager


Objectives and Approaches

• Soft guarantees for QoS• Approaches

– feedback control• controller design and parameter tuning • admission control

– adaptive update policy• conflict between timeliness & freshness• dynamic balancing between updates and

transactions– differentiated services

• absolute/relative miss ratios


Feedback Control

Controller ActuatorProcess

Sensorfeedback

reference(set point)

controlled variable

control input


Timeliness Specification

Settling time

Overshoot

Miss ratio

Time

Reference

%

Steady StateTransient State

Steady state error


Data Freshness

Database Freshness:Set of continuous data

Perceived Freshness:Set of continuous data accessed by timely transactions

Database


Architecture for Feedback Control

U. ThresholdManager

U. ThresholdManager

MR/Util.Controllers

MR/Util.Controllers

QoS ManagerQoS Manager

…

…

AdmissionControl

AdmissionControl

UserTransactions

UpdateStreams

Ready Queue

TransactionHandler

TransactionHandler

…

DispatchAbort/Restart

Block Queue

Monitored Data

U

Unew


Update Policies

• Temporal data objects– Immediate update: aggressive

approach– On-demand update: lazy approach– Update adaptation


Immediate Update

• Advantages:– Fresh temporal data– Ready-to-use temporal data

• Disadvantages:– Costly (esp. in distributed environments)– Blocking user transactions processing


On-demand Update

• Advantages:– Saving system resources

• Disadvantages:– Temporal data access delay – Usually OK in centralized system; NOT

acceptable in distributed environments– Stale data in the database


Adaptive Update Policy

• Adaptive update policy– resolve scheduling conflicts between sensor

updates and application transactions– determine when to switch update strategy and

which data objects should be updated by aggressive/lazy approach

– update utility defined by access update ratio (AUR)

– AUR[Oi]= access frequency[i] / update frequency[i] for a sensor data object Oi


Update Adaptation

• Update strategy determined by system workload and access frequency

– With low workload• abundant CPU time; apply immediate

update to all data– With high workload

• frequently accessed data: immediate update• rarely accessed data: on-demand update


Advantages of Adaptation

• Reduced resource usage (compared to immediate update)

• Reduced data access delays (compared to on-demand update)

• Maintain good performance when data access has highly dynamic and/or skewed patterns


Access Update Ratio (AUR)

• Measure access frequency

• Use immediate update on hot data; on-demand update on cold data

AUR=Access Frequency

Update Frequency

Max AUR

Min AUR

UAT

Hot Data(High AUR)

Cold Data(Low AUR)

Imme-diate

UpdateAUR = 1 Adaptation Upper Bound

On-DemandUpdate


Update Adaptation• Update Adaptation Threshold (UAT)

– Threshold for choosing update method• For a data item:

If AUR >= UAT, use immediate update

If AUR < UAT, use on-demand update– Change UAT based on system workload

• With light workload, UAT = 0; (immediate update for all data items)

• With high workload, 0<UAT<1; (on-demand update for cold data items)

– Higher workload -> higher UAT value


Update Policy Adaptations

D = Dimm

Dimm

Dimm

UAT < 1

AUR =1

Dod

Dod

Underutilized State Moderately loaded State Overloaded State

UAT


Service Differentiation

• Classify transactions according to their importance– premium, basic, and best-effort service classes– provide different QoS to each class– guarantee a certain degree of timeliness and

freshness• Performance specification (QoS-spec)

– per-class miss ratio in stable and transient states

– perceived data freshness: freshness of data accessed by timely transactions

– CPU utilization


QoS Specification (QoS-spec)

• A stringent QoS requirements:– Average MR0 1%– MR0 overshoot 1.3% – Settling time 100sec– Average MR1 5%– MR2 = best-effort– Perceived freshness 98%– Utilization 80%


Differentiated Service Architecture

QoDManager

UpdateScheduler

U

Adapted Update Policy

AdmissionController

Ready Queue

Update Streams

UserTransasctions

Transaction Handler

CC FM Sch.

Block Queue

Monitor

Terminated

Miss Ratio 0

Abort/Restart

Blocked

Preempt

Freshness

Dispatched

U new

Q 0

Q 1

Q 2

MR Controller 0

MR Controller 1

. . .

. . .

Util. Controller

. . .

Miss Ratio 1

Utilization

UtilizationThresholdManager


Performance Evaluation

• Can performance requirements (QoS-spec) be supported?– unpredictable load and data access patterns

• Workload variables– AppLoad (applied load)– EstErr (execution time estimation error)– HSS (hot spot size)– HCR (highest class ratio)

= #class 0 transactions / #all transactions


Workload Variables

• AppLoad (Applied Load)– load applied to the database before any

admission control and QoS adaptation is done – apply increasing loads ranging 70% - 200%

• EstErr (Execution Time Estimation Error)– AET EET * (1 + EstErr)– high EstErr difficulty in scheduling and

resource management– increase EstErr from 0 to 1


Baselines

• Basic-IMU– service differentiation by fixed priority

scheduling– admission control– immediate updates

• Basic-ODU– similar to Basic-IMU– on-demand updates


Average MR0 for Increasing HCR(AppLoad = 200%, EstErr = 1, Uniform Access Pattern)

0

5

10

15

20

25

30

35

40

45

20 40 60 80 100

Highest Class Ratio (%)

Av

era

ge

MR

0 (

%)

Basic-IMUBasic-ODUQMF-Diff


Transient MR0 and MR1 (HCR= 80%, AppLoad = 200%, EstErr = 1, Uniform)

0

5

10

15

20

25

Time (sec)

Tra

ns

ien

t M

iss

Ra

tio

(%

)

MR0

MR1


QoS Differentiation Example Image Compression

High quality image

74 KB (GIF)

Degraded image

8.4 KB (JPEG)

Provide degraded image to lower class during overload


QoS Management of Replicated Data

Part I: Full Replication


Motivation

• Increasing demand for distributed real-time data services– Inherently distributed real-time systems

• stock exchange systems, embedded databases in automobiles, wireless sensor networks and ubiquitous computing.

– Many systems are moving to distributed platform

• to handle increased workloads• other reasons, e.g. fault-tolerance and self-

healing•example: ship control system


Submarine Control Systems

P. Ericsson. An operational ship control system in a virtual environment. In Undersea Defense Technology Europe Conference, 2003.


Challenges

• Transaction timing requirements • Data freshness requirements • Uneven workload distribution • Time-varying transaction workload• Access skew


Temporal Data Replication

• Locally available fresh copies– help meet transaction deadlines– better data freshness

• Different replication approaches– full replication and partial replication– dynamic replication and static replication


System Model for Full Replication

RTDB1

RTDB6

RTDB2

RTDB5

RTDB3

RTDB4

Temporal Data Primary Copy (node 4)

Temporal Data Replicas (node 1, 2, 3, 5, 6)

Non-temporal DataTemporal data is fully replicated to help meet transaction deadlines

LAN


Transaction Model

• Firm deadline• Two types:

– System update transactions• write operation from sensor input

– User/application transactions• multiple service classes• sequential execution


System Architecture

RTDB

MonitorMR & UtilController

Global Load Balancer

AdmissionController

Transactions System Performance Info


Algorithm OutlineCollect_and_Exchange_System_Performance_Data();

If( MR>MRSpec ) {if( Workload_not_balanced()) {

Adjust_Transferred_Workload (); Reduce_Admitted_Transaction();

}else {

Reduce_Admitted_Transaction();}

}else {

Reduce_Transferred_Workload();Increase_Admitted_Transaction();

}


Integration with Local Controller

• LTF adjustment phase added

Database System

AdmissionController

SystemPerformance

Monitor

Min

AdmissionAdjustment

Miss RatioController

UtilizationController

Local⊿UUtil

Local⊿UMR

MRi

Utili

IncomingTransactions

LTFAdjust-ment

⊿UTarget


Simulation SettingParameter Value

MR0 Weight 4

MR1 Weight 2

MR2 Weight 0.1

MRI MD Threshold 0.1

PLTF 0.02

ILTF 0.02

γ 0.9

Parameter Value

Node # 8

Network OP Delay (0.05 – 1.2) ms/s

Temp Data # 200/Node

Temp Data Size Uniform ( 1- 128 )bytes

Temp Data AVI Uniform (0.5 - 5) seconds

Non-temp Data # 10,000/Node

Non-temp Data Size Uniform (1 - 1024) bytes

Parameter Value

Tran Service Class 3

OP Time 0.2 – 2 ms

Temp OP # (1 - 8) / Tran

Non-temp OP # (2 - 4) / Tran

Transaction SF 10

Temporal Data Skew

20%

Non-temp Data Skew

20%

Class 0 Ratio 33%

Class 1 Ratio 33%

Class 2 Ratio 34%

Remote Data Ratio 20%

Exe Time Est Error Normal (20%, 10%)

Average Arrival Rate

660 Tran / s (Poisson)

Arrival Rate Burst 300%


Algorithms

• Best effort: – System operates in best-effort manner– All incoming transactions are admitted

• Local control only:– With local controller only

• FB-GLB: – Feedback-based controller with global load

balancer


Performance Evaluation Outline

• Performance of Load Balancing Algorithm• Performance During Normal Operation• Performance with Transaction Burst• Performance with Message Loss


Load Balancing Function

0

0.1

0.2

0.3

0.4

0.5

0.6

50 100 150 200 250 300

Mean D

evia

tion o

f M

RI

Time (seconds)

FB-GLBBest EffortHigher MRI mean deviation

means unbalanced workload Without load balancer, the

workloads are not balanced

With load balancer, the workloads are balanced.


Normal Operation

0

0.2

0.4

0.6

0.8

1

50 100 150 200 250 300

Mis

s R

atio

Util

izatio

n

Time (seconds)

MR 0MR 1MR 2

Utilization

MR0 ------ & MR1 ------ are kept near 0.

System Utilization is kept around

95%


Handling Transaction Burst

0

0.2

0.4

0.6

0.8

1

50 100 150 200 250 300

Mean R

atio

Time (seconds)

Best Effort

MR0MR1

0

0.2

0.4

0.6

0.8

1

50 100 150 200 250 300

Mean R

atio

Time (seconds)

FB-GLB(Overhloaded Node)

MR0MR1

0

0.2

0.4

0.6

0.8

1

50 100 150 200 250 300

Mean R

atio

Time (seconds)

Local Control Only

MR0MR1

550

600

650

700

750

800

50 100 150 200 250 300

Thro

ughput tr

an/s

ec

Time (seconds)

Throughput of the Whole System

FB-GLBLocal Control Only

Best Effort


Summary of Full Replication

• Growing need for real-time data services in distributed environment

• Replication is an effective method for managing QoS in distributed real-time databases

• Performance evaluation shows– adapts to workload fluctuations– provides specified QoS and overload protection


Part II: Dynamic Partial Replication


Challenges and Approaches

• Additional challenge: scalability• On-demand Real-time DEcentralized Replication

(ORDER) Algorithm• ORDER with Resource Sharing (ORDER-RS)


System Model

• Firm deadline transactions

• Temporal data (sensor data) and non-temporal data items.

• Primary copy and replicated copy (replica)

Site 1

Site 0

Site 3

Site 2

Primary Copies

Primary Site

Replicas

Primary CopiesReplicas

Replication


Transaction Scheduling• Transaction classification

– System update transactions• Sensor data update transactions• Replica update transactions

– User transactions• Incoming application transactions

• Transaction scheduling – Sensor data update transactions

-> Replica update transactions

-> User transactions


Transaction Model

• Periodic Transactions

{TID; TD; ExecTime; SF; DS}

TID: Transaction identification

TD: Transaction duration

Exec Time: Transaction execution time

SF: Slack factor

DS: Data access set


Transaction Data Specification

• Transactions specify their data needs

DataObject {SiteID; DataType; DataID; FR}

SiteID: Database identification

DataType: Data type

DataID: Data item identification

FR: Freshness requirements


Data Update Frequency

• Base Update Frequency (BUF):– Update frequency at the primary copy – The maximum update frequency of a data

item• Extended Update Frequency (EUF):

– Update frequency at replicas– EUF is determined by transaction data needs– EUF varies for different replicas

• Active and Dormant Replicas


ORDER Algorithm

Notations

• Current_EUF(i, x): The Current extended update frequency for temporal data i from site x.

• New_EUF(i, x): The new transaction’s requested update frequency for temporal data i from site x.

• Current_CT(i, x): The current closing time of the replica for temporal data i from site x.

• TD: The requested duration of incoming transaction.


ORDER AlgorithmON Transaction Arrival

If ( ExistActiveReplica(i, x) ) { if (Current_EUF(i, x) >= New_EUF(i, x)) //Use Current EUF

else { //Use the New_EUF Current_EUF(i, x) = New_EUF(i, x); //Set new replica closing time Current_CT(i, x) = Current_Time + TD; } Register_Active_Replica (Current_EUF(i, x), Current_CT(i, x)); }


ORDER Algorithmelse {

//There is no active replica

Create_Active_Replica (i, x);

Current_EUF(i, x) = New_EUF(i, x);

Current_CT(i, x) = Current_Time + TD;

Register_Active_Replica (Current_EUF(i, x),

Current_CT(i, x));

}


ORDER Algorithm (Continued)

On Transaction Departure

Find_Max_EUF(i, x): Find the maximum requested EUF for temporal data i from site x.

Find_TD(): Find the transaction expiring time corresponding to the requested update

frequency.


ORDER Algorithm (on Departure)If( ExistActiveReplica(i, x) ) { //There exist an active replica

if(Current_EUF(i, x) >EUF(i, x)) //Nothing to do here.

else { //Use the maximum requested EUF Current_EUF(i, x) = Find_Max_EUF(i, x); //Set the replica closing time Current_CT(i, x) = Find_TD (Current_EUF(i, x)); Register_Active_Replica (Current_EUF(i, x),

Current_CT(i, x)); } }


Simulation Setting for ORDER

Parameter Value

Node # 10

Temp Data # 500/Node

Temp Data Base Update Frequency

Uniform (0.1 - 1) sec

Replica Creation and Deletion Overhead

0.5 ms

Transaction Period 0.5 - 2 sec

Transaction Duration 20 sec

Temporal Data Operation # 1 – 8 /Tran

Remote Data Ratio 20%

Non-temporal Data Operation # 0 – 2 /Tran

Transaction Slack Factor 5

Freshness Requirement 1 - 3 BUF


Simulation Results

0

0.2

0.4

0.6

0.8

1

20 40 60 80 100 120 140 160 180 200

Mis

s R

atio

Utilization

Transaction Arrival Rate (tran/s (per site))

MR (FullReplication)MR (NoReplication)

MR (ORDER)Util (FullReplication)Util (NoReplication)

Util (ORDER)


With Different Remote Data Ratios

0

0.2

0.4

0.6

0.8

1

20 40 60 80 100 120 140 160 180 200

Mis

s R

atio

Util

izatio

n

Transaction Arrival Rate (tran/s (per site))

MR (FullReplication, Remote Data Ratio = 20%)MR (NoReplication, Remote Data Ratio = 20%)

MR (ORDER, Remote Data Ratio = 20%)MR (FullReplication, Remote Data Ratio = 50%)MR (NoReplication, Remote Data Ratio = 50%)

MR (ORDER, Remote Data Ratio = 50%)With the additional transaction data

needs information, the ORDER

algorithm is more robust to the remote

data ratio change


Summary of Dynamic Replication

• Data services in distributed real-time applications• Dynamic partial replication control algorithm

called ORDER• ORDER with replica sharing (ORDER-RS) for large-

scale systems• Good system performance with the data access

information from the transactions


Future Work on Dynamic Replication

• Dynamic real-time data dissemination using a combination of push and pull policy

• An architecture for dissemination hierarchy for large-scale distributed applications

• Exploit data similarity and imprecision tolerance of transactions to reduce the workload while satisfying the value consistency

• Extension to handle aperiodic transactions


Data Classification

Base Data Derived Data

Temporal Data Temporal base data (e.g. sensor data)

Temporal derived data

Non-temporal Data

Non-temporal base data

Non-temporal derived data


Base Data and Derived Data

Real-time Database

Trans-action

Non-temporal BaseData.

(Static Config)

TemporalDerived Data

Temporal BaseData

(Sensor Data)

UpdatesNon-temporal BaseData

(User-Specific Data)

TemporalDerived Data

(User-SpecificViews)

Trans-action

SensorData

… ...

Non-temporalDerived

Data


Example: Base Data and Derived Data

Real-time Database

Dell IBM OracleSy-

base … ...

DatabaseIndustry

Index

PCIndustry

Index… ...

Base Data Set of Base Data Set ofPC Industry Index Database Industry Index

Derived Data(User Specific Viewsand Trading Plans)

Base Data(Real-time

Stock Quotes)


System Model

• Distributed main-memory real-time databases• Firm-deadline transactions• Sequential execution• Scheduling priority

– Temporal base data update ->

Temporal derived data update ->

User transactions– EDF within same transaction type


Update Policies

• Temporal base data– Immediately updated

• Temporal derived data– Immediate update– On-demand update– Update adaptation


Problem with On-Demand Update

Server

Server

Satellite dish

Server

T1

TDD1

TDD2

TDD3

…

Satellite dish

Satellite dishStale

Stale

Stale

…

TBD1

TBD2

TBD3

…

Fresh

Stale

Stale

…

TBD1

TBD2

TBD4

TBD5

…

Stale

Stale

…

Satellite dish

TBD3

Satellite dish

TBD4

TBD5

Fresh

T2

Fresh

Fresh

Fresh

Fresh

FreshTDD1 (TBD1, 2)

TDD2 (TBD3, 4, 5)

T1,T2: User transactionsTDD: temporal derived dataTBD: temporal base dataLong

Delay

LongDelay

LongDelay


Evaluation: Simulation Settings

Node Number 8End to End Transmission Delay (50 - 1200) micro seconds

Temporal Data # 1000 /NodeTemporal Data Size Uniform (1 - 128) bytesTemporal Data AVI Uniform (1 - 2 ) seconds

Non-temporal Data # 10,000 /NodeNon-temporal Data Size Uniform (1 - 1024) bytes

Parameter Value

Derived Data Size 2 - 6 base data items

Base DataTemporal Data Ratio

0.75

Derived Data # 500/Node

Base DataRemote Data Ratio

0.2

Operation Time 0.2 - 2 msTemporal Data OP # 1 - 4 /tran

Non-temporal Data OP # 1 - 2/tranDerived Data OP # 1 - 2/tran

Transaction Slack Factor 5Temporal Data Access Skew 20%Non-temporal Data Access

Skew10%

Parameter Value

Remote Data Ratio 20%Derived Data Access Skew 10%

On-demand Update Cost 0.1 ms


Evaluation: Algorithms

• Immediate update• On-demand update• Oracle• Update adaptation


Results: Different Slack Factors

SF = 3

Slack Factor = 5

SF = 100

0.2

0.4

0.6

0.8

1

100 200 300 400 500 600 700 800

Mis

s R

atio

Transaction Arrival Rate (tran/s)

MR (Immediate)MR (On-Demand)

MR (Adaptation)MR (Oracle)

0

0.2

0.4

0.6

0.8

1

100 200 300 400 500 600 700 800

Mis

s R

atio


Slack Factor = 3



0

0.2

0.4

0.6

0.8

1

100 200 300 400 500 600 700 800

Mis

s R

atio


Slack Factor = 10



With low system workload, our algorithm uses

immediate update.

With high system workload, our algorithm drops updates on cold data item to save CPU

time.

Our system performs better than immediate and on-

demand update algorithms with different slack factors


Results: Different Access Skews

0

0.2

0.4

0.6

0.8

1

100 200 300 400 500 600 700 800

Mis

s R

atio


Derived Data Access Skew = 0.05



0

0.2

0.4

0.6

0.8

1

100 200 300 400 500 600 700 800M

iss

Ra

tioTransaction Arrival Rate (tran/s)

Derived Data Access Skew = 0.2



When derived accesses are skewed, our algorithm drops immediate updates on cold data items, thus it has much

better performance than the immediate update.

When derived accesses are less skewed, our algorithm detects that and uses immediate update on most derived data. It thus performs much better than the on-demand update algorithm in this case.


Summary of Derived Data QoS

• On-demand derived data update not suitable for distributed environments

• Detailed evaluation of immediate and on-demand update strategies in distributed environments illustrate their deficiency

• New update adaptation algorithm based on access frequency


Where Are the Streams Coming From?

From the Ground …

In-pavement Crosswalk

Illumination

Bicycle Video Detection

Road Weather Information System

Real-Time Navigation

System

Real-time accident detection andresponse management


What is DSMS?

• Traditional DBMS

– Data stored in finite, persistent data storage.

• DSMS

– Continuous, unbounded, rapid, time-varying streams of data elements

Streaming DataResultQueries Result

Persistent Data Storage Continuous Queries


Query Plan

State1

Q1

Stream1 Stream2

⋈ State2

q1

q3

q2

Synopsis: Stores operator state

Operators:Basic processing units

Queues:FIFO buffers for tuples


Motivation for PQuery

• Several emerging applications need real-time performance guarantees– Application 1 -- Surveillance Sensor Networks:

identifying and tracking targets and intruders– Application 2 -- Medical Applications: patient

monitoring in intensive care units and assisted living facilities


Surveillance Systems

Query 1 : Select …Query 2 : ……

Sensor Readings

Data Stream Management SystemMonitoringQueryResults

E.g., Airport Surveillance Systems

Missing deadlines may mean missing the target in thesurveillance systems


Challenges

Providing effective data stream processing manager to support real-time requirements

• CPU: – Unpredictable incoming stream workloads– Query cost varies with stream contents

• Memory: – Variable size of intermediate results

• Others:– Networking, power, and other constraints


Continuous Query and Periodic Query

• Continuous Query (CQ)– Data-active, query-passive– Queries are “triggered” by input streams– Similar to event-based triggering systems

• Periodic Query (PQ)– Query-active, data passive– Queries are periodic, not triggered by input

data streams


Continuous Query and Periodic Query

Periodic QueryContinuous Query

Query Window

Continuous Query Results Periodic Query Results

Incoming Stream Data Tuple


Continuous Query• Query execution is “triggered” by incoming data

– Every new data tuple implies new query instance– Higher data rate incurs higher number of queries– System workload directly ties with incoming data

rates• Query timing requirements are not clearly specified• Hard to estimate run-time system workload and

response time• Query instances have no limit• Query semantic may change with system workload

– e.g. average value of a sliding window


Periodic Queries

• Clear timing requirements• Predictable query behavior• Easier to estimate system workload

– Fixed number of query instances• Fixed query semantics


Query Language Extension

• New Reserved Words:– STime: Starting time of a periodic query;– ETime: Ending time of a periodic query;– Period: Period of the query (if applicable);– Deadline: Query deadline (relative to the query

starting time);– Importance: Importance level of the query;


Quality-of-Service Metrics

• Data Completeness: the percentage of data tuples used in computing the query results during the overload.– A general measure to capture query result

quality– Load shedding reduces the data completeness

• Miss Ratio: the percentage of periodic queries that miss their deadlines


Feedback-based Control

• Data admission: Dropping incoming stream data tuples when the system is overloaded

• A feedback-based controller collects system performance data and controls the stream data admission process.

Miss RatioThreshold

PAC

MR

EMR

DSMSDataAC

DataStreams

PI Ctrl

Query Results


Implementation

• Scheduler: EDF scheduler

• Concurrency Control: timestamp-based

• Data Admission Control: different queries may have different data admission ratios


Algorithms• Stream:

– Continuous queries– Best-effort services

• RTStream:– Periodic queries– EDF scheduler

• RTStream-DAC-S:– RTStream with single data admission controller

• RTStream-DAC-M:– RTStream with multiple data admission

controllers (one for each service class)


Performance Evaluation: Synthetic Workloads

• 12 stream-to-stream join queries

• 24 stream-to-relation join queries

• 12 aggregation queries

Parameter Value

Total Memory 256 M

Page Size 4K

Page # per Queue 50

Stream # 12

Stream Rate 200 tuples / s

Query per Stream 4

Total Query # 48

Selection Selectivity 0.1

Stream-to-Stream Join Sel.

0.01

Stream-to-Relation Join Sel.

0.1

Query Period 1 - 4 sec

Query Deadline 1 - 4 sec

PMR 0.2

IMR 0.1

Data AC Period 1 sec

Experiment Time 300 sec


Experiment Results: Synthetic workload

Time (Seconds)

Workload

0 60 120 180 240 300

80%

160%

0

0.2

0.4

0.6

0.8

1

0 50 100 150 200 250 300

Mis

s R

atio

Da

ta C

om

ple

ten

ess

Time (seconds)

(b) Periodic Query Miss Ratio and Data Completeness

Miss Ratio (RTStream)Miss Ratio (RTStream-DAC-S)

Data Completeness (RTStream-DAC-S)

0

5

10

15

20

25

0 50 100 150 200 250 300

La

ten

cy (

seco

nd

s)

Time (seconds)

(a) Continuous Query Output Latency (Stream)

Average LatencyMax Latency

• Two workload bursts at 60th and 180th seconds


Service Differentiation

0

0.2

0.4

0.6

0.8

1

0 50 100 150 200 250 300

Mis

s R

atio

Time (seconds)

(a) Differentiated Services - RTStream

Class 0 Miss RatioClass 1 Miss RatioClass 2 Miss Ratio


Service Differentiation – cont.

0

0.2

0.4

0.6

0.8

1

0 50 100 150 200 250 300

Mis

s R

atio

Da

ta C

om

ple

ten

ess

Time (seconds)

(b) Differentiated Services - RTStream-DAC-S


Data Completeness


Service Differentiation – cont.

0

0.2

0.4

0.6

0.8

1

0 50 100 150 200 250 300

Mis

s R

atio

Da

ta C

om

ple

ten

ess

Time (seconds)

(c) Differentiated Services - RTStream-DAC-M


Class 0 Data CompletenessClass 1 Data CompletenessClass 2 Data Completeness


Network Monitoring Application

• 16 Network monitoring queries on two real network traces:– Traffic statistics

queries– Source-destination

traffic monitoring queries

– Application traffic monitoring queries

Parameter Value

Total Memory 256M

Page Size 4K

Page # per Queue 400

Stream # 2

Stream Rate 25000 tuples/ s

Query per Stream 8

Total Query # 16

Query Period 1 – 2 sec

Query Deadline 1 -2 sec

PMR 0.5

IMR 0.2

Data AC Period 1 sec

Experiment Time 90 sec


Experimental Results

20000

22000

24000

26000

28000

30000

0 10 20 30 40 50 60 70 80 90

Wo

rklo

ad

(tu

ple

s/se

c)

Time (seconds)

Network Trace Workload

Workload Interface 1Workload Interface 2

Heavy application-specific packets

Dropping 80% of incoming packets to alleviate the overload

Semantic dropping can be used to only drop packets or intermediate results of

the overloaded queries

Latency keeps increasing due to accumulated workloads

0

0.2

0.4

0.6

0.8

1

0 10 20 30 40 50 60 70 80 90

Mis

s R

atio

/ D

ata

Co

mp

lete

ne

ss

La

ten

cy

Time (seconds)

Network Traffic Monitoring Workload

Latency (Stream)Miss Ratio (RTStream-DAC-S)

Data Completeness (RTStream-DAC-S)


Summary of Stream Data Processing

• Everything, everywhere: Many emerging applications need real-time data stream processing services.

• Periodic query as an alternative query model for continuous query.

• A prototype called RTStream to support periodic queries.

• In experimental study, the data admission control mechanism performs well in trading data completeness for query miss ratios with both synthetic workload and real network monitoring workload.


Trends and Challenges

Trends

• Applications are becoming large, complex, and distributed

• Operate in a highly dynamic environment, yet requires predictable performance -- satisfy QoS

• Need to support multi-dimensional requirements

• Need to support more active features such as triggering mechanisms


Trends and Challenges (2) Trends

• Composable real-time components– architecture: how do components relate– abstractions/encapsulations of components– dynamic scheduling and resource management– tools for estimating/determining characteristics

• Large-scale distributed applications– acceptable QoS even with changing

environments• Testing and validation techniques• “People in industry want to use COTS!!”


Trends and Challenges (3) Changing operating environments

• Embedded Systems

– every embedded OS will require real-time scheduling and some form of real-time data management support

– massive volumes– ubiquitous and pervasive computing is everywhere

• Networks– convergence of telecom and data networks– exponentially-growing network services and

applications– must deal with proxies and cache to support

different QoS requirements


Trends and Challenges (4)

Requirements and Challenges

• ability to perform increasingly complex functions• light, small, and reliable• heterogeneity• efficient resource management• integration with other types of requirements

(security and fault-tolerance, …)• features to be unbundled such that only

necessary functions can be selected for specific applications


Future Research Areas for RTDB

• Real-time data/information centric view – as opposed to task centric view currently used

• Adaptive scheduling and decision making based on changing situation and incomplete workload and component profiles

• Interface and component libraries– open interfaces– dealing with semantic mismatches– micro and macro components

• Component-based tool sets• Configuration tools• Tools to specify and integrate requirements of real-time

and fault-tolerance


Future Research Areas (2)“New Requirements”

• Complex software must evolve• Software must be portable to other platforms

– develop once– verify once

• certification and verification is very expensive– port and integration should be automatic

• Flexible real-time data support– one-size-fits-all does not work – small with minimal functionality for embedded

systems while complete and full functionality for back-end server applications


Research Issues• Resource management and scheduling

– temporal consistency (especially relative validity) – interactions between hard/soft/non RT transactions– transient overload management– I/O and network scheduling – maximizes both concurrency and resource

utilization– support of different transaction types for flexible

scheduling: alternative, compensating, imprecise• Recovery

– availability (partial) of critical data during recovery– semantic-based logging and recovery


Research Issues (2)• Concurrency Control

– alternative correctness models (relaxing ACID properties)

– integrated and flexible schemes for concurrency control• Query languages for explicit specification of real-time

constraints -> RT-SQL• Distributed real-time databases and data services

– commit processing– distribution/replication of real-time data– recovery after site failure– predictable (bounded) communication delays– large-scale– in-network aggregation and multi-resolution repository


Research Issues (3)• Data models to support complex multimedia objects• Schemes to process a mixture of timing constraints

and complex transaction structures• Support for integrating requirements of security and

fault-tolerance with real-time constraints• Performance models and benchmarks• Support for more active features in real-time context

– techniques for bounding time in event detection, rule evaluation, rule processing mode, etc.

– associate timing constraints with triggering mechanisms

• Interaction with legacy/conventional systems


Summary• Most current real-time systems technology is based on

– predictable operating environments, known workload, WCET, wired networks, highly reliable nodes, no other conflicting requirements (e.g., power, security, FT, ..)

• Trends– soft RT, unpredictable environments, multidimensional

requirements, QoS, embedded and wireless, simple and unreliable nodes, aggregate behavior control, power management needed, ...

• New sets of solutions needed– QoS management in real-time databases and services– control system behavior: feedback, adaptation,

replication, differentiation, imprecision, trade-offs …


Exercise(1)

Sometimes a transaction that would have been aborted under the two-phase locking protocol can commit successfully under the optimistic protocol. Why is that? Develop a scenario in which a case of such transaction execution occurs. Does it mean that all RTDBS should use optimistic protocols? Discuss the drawbacks of optimistic approaches in terms of QoS management.


Exercise (2)

Explain why EDF does not work well in a heavily loaded real-time database systems, and propose how you can improve the success rate by adapting EDF. Will your new scheme work as well as EDF in lightly loaded database systems? Will it work well in real-time applications other than database systems? Is EDF a good scheme for managing QoS?


Exercise (3)

Generate examples of an application where it is permissible to relax one or more ACID properties of transactions in real-time database systems. Explain which components of RTDBS might be affected by changed properties. Discuss the relationship between the correctness criteria (such as ACID) and QoS management.

university of virginia qos in real-time data services and stream processing sang h. son department...

Documents