Real Time Databases

Reviews
Real Time Databases Group Members: Gajendran Mahendran Kajitha Balasundaram Vithiya Perampalam Suganthini Nanthanan Group Number: #13 Date: March 26, 2008 Outline Introduction  Conventional Vs. Real-Time Databases  Preservation of Data Consistency  Timing Constraints & Deadlines  Future of Real-Time Databases Q&A  Conventional Databases  Designed for ensuring that data integrity is maintained for permanent/persistent data and that concurrent transaction execution is correct. ACID Properties  Cannot deal with changes that are very rapid and dynamic as they contain persistent data mostly UNAFFECTED by time  Real-Time Database Systems (RTDBS)   Consists of two areas: Real-Time Systems & Database Systems Real-Time Systems (RTSs) – Timing requirements for task execution times – Processing data items whose values and validity change in time  Database Systems (DBSs) – Data volumes processed by the systems -> organized mechanism for storing, managing and retrieving information – Requirement Concerns: durability, security and consistency of the processed data  RTDBS is the INTEGRATION of features of RTSs and DBSs RTDBS - II  RTDBS is designed for: – Processing transactions having timing constraints associated with them – Accessing data items whose values and validity change in time – Supporting data descriptions, data correctness and integrity maintenance methods, efficient data access and management techniques – Guaranteeing the correct execution of transactions in spite of concurrency and failures!!!   Timeliness is more important than correctness Correctness can be traded for timeliness by relaxing the ACID properties. Objectives of RTDBS  Objectives: – Gathering data from the environment, processing it in the context of information acquired in the past, for providing timely and temporally correct response  Correctness Requirements: – Time constraints on transactions  How “fast” a system responds to a request – Time constraints on data  How “fresh” the data read is – Database consistency constraints Why Time Constraints on Transactions?  Dictate the behavior of the environment  specification of rates and times of I/O of the system Requirements on reaction times  basically dictating the responsiveness of the system Need to maintain temporal consistency of data A   transaction value depends on completion time!!! Types of Time Constraints  Based on type of time constraints: – – Periodic - Every 10 secs Sample wind velocity - Every 20 secs Update robot position Aperiodic - If temperature > 1000 within 10 secs add coolant to reactor  Based on Value: – – – Hard: must execute before deadline Firm: abort if not completed by deadline Soft: diminished value if completed after deadline Deadlines & Timing Constraint Violations  Three categories of time constraint violations can be distinguished:  Soft Deadline: Result useful even after deadline, though value is reduced  Firm Deadline: No value after deadline, but no penalty is accrued Hard Deadline: Penalty is accrued - negative, leading to a catastrophe  Examples of Time Constraints using Event-Condition-Action (ECA) Rules Time constraints can be specified using ECA rules:  ON (10 seconds after “initiating landing preparations”) IF (steps not completed) DO (within 5 seconds “abort landing”)  ON (deadline of “object recognition”) IF (action not completed) DO (“increase importance, adjust deadlines”) Real-Time (Temporal) Data  Arrives from continuously changing environment  Data items reflect the state of the environment – – – – Data from sensors - e.g., temperature and pressure Derived data - e.g., rate of reaction Input to actuators - e.g., amount of chemicals, coolant Archival data - e.g., history of (interactions with) environment  Has observed time and validity interval  Users of temporal data need to see temporally valid views of the data (state of the environment)  When must the data be temporally consistent? – ideally, at all times – in practice, only when they are used by transactions!!! Time Constraints on Data  Data perceived by the controlling system must be consistent with the actual data  how closely is the data read by a transaction models the environment?  Requirements: 1. Timely monitoring of the environment 2. Timely processing of sensed information 3. Timely derivation of needed data  Temporal Consistency Measurement: – absolute consistency: freshness of data between actual state and its representation – relative consistency: correlation among data accessed by a transaction Time Constraints on Data - II  Absolute consistency is measured by Absolute Validity Interval (AVI): state of environment and image in DB – Given: (value, avi, ts)  current time – ts <= avi  Relative consistency is measured by Relative Validity Interval (RVI): data used to derive other data – Given: (value, avi, ts) and (value’, avi’, ts’)  |ts – ts’| <= rvi Time Constraints on Data - III Example:  Data object is specified by:  (value, absolute validity interval, time-stamp)    Interested in temperature and pressure with RVI of 5 Let current time = 100 temperature = (347, 10, 95) and pressure = (50, 20, 98)  temporally consistent  temperature = (347, 10, 98) and pressure = (50, 20, 91)  temporally inconsistent Database Consistency  Concurrency Control: – Control of interaction among concurrent transactions to preserve database consistency Coordinating read & write transactions to shared data in DBSs  Concurrency control protocols for DBS Vs. RTDBS  Concurrency Control  Popular Concurrency Control: Serializability – Sequence of DB Operations = serial transaction schedule  serializable Limits degree of multiprogramming Introduces blocking and restarts of transactions But data is short lived!!! Approaches to Concurrency  Key Issue of System Degradation in RTDBSs:  aborts and restarts of transactions.  caused by concurrency control protocols trying to resolve conflicts between transactions   Lock-Based Protocols (i.e. 2PL) Optimistic Concurrency Control (OCC) Protocols Lock-Based Protocol Locks are used to synchronize concurrent actions  Two-Phase Locking (2PL)  – all locking operations precedes the first unlock operation in the transaction – expanding phase (locks are acquired) – shrinking phase (locks are released) – suffers from deadlock – priority inversion UNSATISFACTORY for RTDBS Dead-Lock Goal: Largest number of transactions can meet their deadline Abort transaction that has already passed  Abort transaction with longest deadline  Abort transaction that is least critical  Priority Inversion High priority tasks are blocked by low priority tasks  Impacts real-time scheduling algorithms (ineffective)  Solutions:  – Wait Promote – High Priority (aborts)  Leads to cyclic restart – Conditional Restart (measure the slack time)  No single strategy excels  Depends on applications, avail. of resources & cost of transaction restart! OCC Protocol - I  3 Phases: 1. Read 2. Validate 3. Write   Rules: Given: T1 be serialized before T2 1. R/W rule: Data Items to be written by T1 should not have already been read by T2 2. W/W rule: T1’s write should not overwrite T2’s writes OCC Protocol - Validation  Check for Rule Violations: 1. T1 completes execution before T2 starts (no interleaving) 2. W of T1 does not intersect R of T2 (R/W) 3. T1 finishes W before T2 starts validation (W/W) Conflict Resolution if Rule is violated!  Validation fails!  (broadcasting commit, etc.) Applications military command and control Aerospace systems  aircraft control  traffic control  telecommunication and computer network management  telephone directory service systems  computer integrated manufacturing (CIM)  factory automation and robotics  workflow systems  medical monitoring  stock arbitrage systems  multimedia systems   References         References [1] Azer, B., Kwei-Jay, L., Sang, H.S., “Real-Time Database Systems: Issues and Applications”, Kluwer Academic Pub., 1997. [2] Kam-Yiu, L., Tei-Wei, L., “Real-Time Database Systems: Architecture and Techniques”, Kluwer Academic Pub., 2001. [3] Norman, W.P., “Active Rules in Database Systems”, Springer., 1998. [4] Piotr Krzyzagorski., “Concurrency Control in Real-Time Systems”, 2005. http://www.edbt2000.uni-konstanz.de/phdworkshop/papers/Krzyzagorski.pdf [5] Matthew, R.L., Young-Kuk, K., Sang, H.S., “Managing Contention and Timing Constraints in a Real-Time Database System”, Univeristy of Virginia, Charlottesville, 1995 IEEE [6] http://ieeexplore.ieee.org/iel3/3569/10678/00495222.pdf Question & Answer

Related docs
Real-Time Databases
Views: 17  |  Downloads: 1
Time in Databases
Views: 0  |  Downloads: 0
Real-Time Databases and Data Services
Views: 11  |  Downloads: 0
Panel. Real-Time Databases
Views: 0  |  Downloads: 0
Temporal and Real-Time Databases A survey
Views: 1  |  Downloads: 0
Real-Time-is-Not-an-Option
Views: 4  |  Downloads: 0
Real-time-Simulation
Views: 10  |  Downloads: 1
Time Series Databases
Views: 20  |  Downloads: 4
Databases on the Internet
Views: 3  |  Downloads: 0
premium docs
Other docs by One Seven