1 / 20

Real-Time Distributed Databases

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. Increase Understanding of Real-Time Distributed Database Systems.

redford
Download Presentation

Real-Time Distributed Databases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

  5. 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.

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

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

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

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

  10. Pessimistic Concurrency Control • 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

  11. Optimistic Concurrency Control • 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

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

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

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

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

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

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

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

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

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

More Related