Real-Time Distributed Databases By: Chris Scardino CSC536 Monday, May 2, 2005

Goals of this Paper Real-Time Distributed Database Systems a relatively new area of research. Real-Time Distributed Database Systems a relatively new area of research. Increase Understanding of Real-Time Distributed Database Systems. Increase Understanding of Real-Time Distributed Database Systems. Present information about key factors of Real-Time Distributed Databases. Present information about key factors of Real-Time Distributed Databases.

Topics Hard vs. Soft RTDDBS Hard vs. Soft RTDDBS Concurrency Control in RTDDBS Concurrency Control in RTDDBS QoS and QoD through Replication QoS and QoD through Replication

Databases Database: Database: –A collection of related data with meaning Distributed Databases: Distributed Databases: –A database that consists of two or more data files located at different sites on a computer network.

Real-Time Distributed Databases Distributed Databases with the added constraint of completing operations within a certain amount of time to accurately reflect the outside world.

Real-Time Distributed Databases Strategies must suit system attributes Strategies must suit system attributes –Hard or Soft –Concurrency Control –Replication

Hard vs. Soft Hard Strict timing constraints Strict timing constraints Data and Service guaranteed Data and Service guaranteed Deadlines met to avoid catastrophe Deadlines met to avoid catastrophe Example: Example: –Control tower notifying planes where to land in inclement weather –Burglary System dispatch Soft Less strict timing constraints Less strict timing constraints Failure to meet deadlines not dangerous Failure to meet deadlines not dangerous Value of data declines after deadline. Value of data declines after deadline. –Example: Checkout line growing in a grocery store.

Concurrency Control Ensures data is accurate even in a distributed system Ensures data is accurate even in a distributed system Two main approaches: Two main approaches: –Prevent Collisions (Pessimistic) –Detect Collisions and Respond (Optimistic)

Pessimistic Concurrency Control Two-Phase Locking: Two-Phase Locking: –Transactions acquire locks on data –After transaction completed, locks are removed. –Ensures that data integrity isn’t compromised.

Pessimistic Concurrency Control Disadvantages to 2PL: Disadvantages to 2PL: –Don’t scale well to distributed systems –Difficult to maintain locks at different locations –Problems inherent to locking multiplied by number of sites

Optimistic Concurrency Control OCC: OCC: –Assumed that collisions won’t occur –Few or no read restrictions –Initial writing takes place on copy of data –Course of action can be decided based on collision

Optimistic Concurrency Control Disadvantages to OCC: Disadvantages to OCC: –The less servers, the more likely collisions –Collisions always cause rollbacks –Time wasted while restarting transactions

Variations on CC Neither OCC nor PCC perfect for RTDDBS Neither OCC nor PCC perfect for RTDDBS Variations/Augmentations frequent: Variations/Augmentations frequent: –DHP-2PL –OCC Wait-50

Replication Strategies in Real-Time Distributed Databases Replication Deadlines must be met Deadlines must be met Fault tolerance Fault tolerance Failure Transparency Failure Transparency Replication helps maintain Quality of Service and Data Freshness Replication helps maintain Quality of Service and Data Freshness

Full Replication All data replicated at multiple sites All data replicated at multiple sites –High fault tolerance –Failure transparency –Improved response times through querying local data

Full Replication Two Categories: –When replication takes place Eager or Lazy Replication Eager or Lazy Replication –Where the replication takes place Primary or Update-Anywhere Primary or Update-Anywhere

Full Replication: Eager vs. Lazy Update Eager Update Replicas updated as transaction happens. Replicas updated as transaction happens. High response times from clients. High response times from clients. Locked longer. Locked longer. High Overhead High Overhead Lazy Update Replicas updated after transaction committed. Replicas updated after transaction committed. Chance for inconsistency. Chance for inconsistency.

Full Replication: Update Anywhere vs. Primary Copy Update Anywhere Any replica can update other replicas. Any replica can update other replicas. Good for fault tolerance. Good for fault tolerance. High synching and update times. High synching and update times. Primary Copy One replica designated as “server”. One replica designated as “server”. Good for read-only transactions. Good for read-only transactions. Restarts at server mean long waits and missed deadlines. Restarts at server mean long waits and missed deadlines.

Alternative: Partial Replication JITRTR: Replicate as needed. JITRTR: Replicate as needed. Only parts of the database replicated to cut down on overhead. Only parts of the database replicated to cut down on overhead. Works best in static systems Works best in static systems

Conclusion Replication strategies must adapt to Real- Time systems. Replication strategies must adapt to Real- Time systems. Variations or Augmenting traditional algorithms necessary. Variations or Augmenting traditional algorithms necessary. Every RTDDB system has different requirements. Every RTDDB system has different requirements. No single excellent implementation for all systems. No single excellent implementation for all systems.