Temporal and RealTime Databases A Survey by Gultekin

Temporal and Real-Time Databases: A Survey by Gultekin Ozsoyoglu and Richard T. Snodgrass Presentation by Didi Yao

Introduction l Survey two areas that can benefit from cross infusion: temporal and real-time DBs l Temporal: time-varying info l Real-time: transactions w/ time constraints l Both can benefit from one another

Real-Time Databases l Transactions have deadlines and timing constraints l Time constraints on: queries, insertions, deletions, updates, database integrity l More work has been done on temporal than real-time DBs (600 temporal papers, 150 real-time papers)

The Time Domain l 2 structures: linear and branching l Densities of the time line: – Discrete models – Dense models – Continuous models l Most naturals reals or rationals reals (no gaps) proposals for adding temporal to relational data models use discrete

The Time Domain (cont. ) l Relative (unanchored): 3 PM, Nov 9, 2000 l Relative has direction l Absolute (anchored): 3 hours l Absolute, in a way, is also relative

The Time Domain (cont. ) l Valid time – When a fact was true in reality – Bounded or unbounded l Transaction time – When a fact was stored – Grows monotonically l Others: user-defined time, decision time l Indeterminacy- “don’t know exactly when”

Time in Real-Time DBs l Valid time – Used for data that have real-world counterparts l Transaction time – Transactions affecting real-time systems – Never aborted or rolled back l Does not assume future, linear, bounded l Does not deal with temporal indeterminacy

Temporal Data Models (relational) l Time support in conventional DBs is only user-defined time: Date, Timestamp l Table I (temporal relational data models): – 14 “valid time” models – 3 “transaction time” models – 9 “valid and transaction time” models l “Valid time” wins

Temporal Data Models (OO) l Table II (temporal OO data models): – 3 “valid” models – 5 “transaction” models – 4 “both” models

Valid Time (Temporal Model) l Single chronon – Event timestamp l Interval – Interval timestamp l Valid-time – Set of intervals

Transaction Time (Temporal Model) l Often used to support versioning which allows user-supplied identifiers to be attached to versions. l Versioning support generally implies OO. l Conclusion to temporal data models: a coordinated suite of data models can best achieve temporal goals

Real-time Data Models l Relational model is used for real-time DBs l OO model may benefit real-time DBs: – rich data semantics, complex objects, encapsulation, methods, messages l However, timeliness the added complexity affects real-

Temporal Query Languages l User-defined time supported by most DBs l 3 approaches to supporting Valid-time: – Use relational or OO model directly – Include general extensions to data model and query languages (only used on OO query languages) – add new constructs and temporal operators

Temporal Query Languages l Transaction-time is used for rollbacks and versioning (extension and schema) l Extension versioning (tuples, object instances or attributes are versioned) – Use model directly, general extensions, or modify data model and language l Schema versioning (object definition versioned) – Multiple schemas in effect

Real-Time Data and Transaction Properties Hard transaction: missing a deadline is disastrous l Soft transaction: missing a deadline will not kill you l Factors that affect real-time transactions: – Transaction arrival pattern: periodic, sporadic – Data access type: random, round-robin – Knowing whether an item will be accessed beforehand – Knowing the CPU and I/O usage beforehand l

Real-Time Properties (cont. ) l It is not possible to have both external consistency AND integrity constraint sat. l External consistency may: – Lead to triggers (more coolant) – Require aborts (abort objects from furnace) l Internal consistency may need resolution through new transactions. l Cooperate, not compete

Conventional vs. Real-Time l Conventional DBs: – Fair in data and resource allocation – Use response time and throughput as measures l Real-Time DBs: – Timely transaction execution – Fairness is secondary – Use % of non-missed deadlines as a measure – Transactions prioritized on deadlines

Real-Time Consistency l Absolute data consistency l Relative data consistency – A set of data items that are relatively consistent to each other

Real-Time Query Languages l none

Architectural Issues Temporal query optimization is more involved than conventional query opt. l Predicates are harder to optimize – Joins with more inequalities are frequent l Time advances in one direction – Natural clustering on sort order l Methods to optimize query: l – Replace algebraic expression with a more efficient, equivalent one – Change access method of an operator – Change implementation of an operator

Architectural Issues (cont. ) l Temporal joins: proposed extensions to nested loop and merge joins l Temporal indices are important because of the size of temporal data but no work has been done to empirically compare them

Architectural Issues (cont. ) l Transaction processing – Adapt existing concurrency control and transaction management to support transaction time – Timestamp at the end of transaction l Processing transaction with hard deadlines – Arrival patterns, items to be accessed, CPU, I/O access times must all be known

Architectural Issues (cont. ) l Processing transaction with soft deadlines – Priority assignment policies: l Earliest-deadline-first, least-slack-time-first, etc… l Concurrency control protocols – Lock-based protocols – Timestamp-ordering protocols (timestamp start) – Optimistic concurrency control protocols (timestamp end)

Architectural Issues (cont. ) l Lock-based protocols – Transaction blocks or aborts depending on transactions priority l Priority inheritance approach – Lower-priority transaction inherits a higher priority in order to block l Priority abort approach – Higher-priority request can cause lower-priority transaction to abort

Architectural Issues (cont. ) l Timestamp-ordering protocols – Timestamps transaction start – Early conflict resolution – Suffers from priority inversion l Optimistic concurrency control protocols – Timestamps transaction end – Nonblocking and deadlock-free – Aborts and restart wastes resources

Architectural Issues (cont. ) l Stored data manager structures – Reverse chaining, accession lists, clustering, stacking, cellular chaining l Buffering for real-time scheduling – Priority-LRU, priority-DBMIN l Scheduling disk I/O for real-time processing – FD-SCAN decides scanning direction by location I/O request with earliest deadline

Conclusion Temporal relational database (25 years) l Temporal OO database (15 years) l Real-time databases (since 1986) l Accomplishments l – No data model is good enough, need suite of models – Real-time and temporal people are interacting and starting to use the same language l Needs – Real-time models that capture semantic knowledge – Too many temporal data models, not many real-time models and no real-time query language – Performance is still a challenge