Distributed Databases. Distributed Database Systems. CISC437/637, Lecture #21 Ben Cartere?e

Transcription

1 Distributed Databases CISC437/637, Lecture #21 Ben Cartere?e Copyright Ben Cartere?e 1 Distributed Database Systems A distributed database consists of loosely coupled sites with no shared physical components A DBMS runs at each site, independent of the others Contrast with a parallel DBMS: a single parent process that can use many CPUs TransacPons may access data at one or more sites Copyright Ben Cartere?e 2 1

2 Homogeneous vs Heterogeneous Distributed databases can be either homogeneous or heterogeneous Homogeneous: Same DBMS sosware running at each site Sites know about each other and agree to cooperate in processing requests Sites give up control over sosware and schema Appears as a single system to a user Heterogeneous: Different DBMS sosware at each site Possibly incompapble schema across sites Sites may not be aware of each other Copyright Ben Cartere?e 3 Classical View of Distributed DBs Two properpes were considered desirable: Distributed data independence users should not have to know where the data is Distributed transac3on atomicity users should be able to submit transacpons that access data across sites just like purely local transacpons In pracpce, these properpes are not always easy to support, and may not even be desirable Distributed DBs is an evolving topic The right way depends heavily on what the uses are Copyright Ben Cartere?e 4 2

3 Distributed DB Architectures Client- server DBMS servers manage data and execute transacpons independently Clients submit a query to a single server Collabora3ng server DBMS servers cooperate in execupng transacpons spanning servers One server receives a query; determines best distributed processing plan across server Middleware systems One server is capable of distribupng queries; the rest are completely local Copyright Ben Cartere?e 5 DistribuPng Data RelaPons will be stored on disks across sites RelaPons can be fragmented (parpponed) in different ways, but not re- parpponed during querying Horizontal fragmenta3on: full rows stored at different sites Ver3cal fragmenta3on: full columns stored at different sites RelaPons can be replicated at more than one site For increased availability of data and faster query evaluapon Synchronous vs asynchronous determines how current the replicants are Copyright Ben Cartere?e 6 3

4 Distributed DB Catalog Processing distributed queries requires keeping track of how data is distributed Replicas of fragments must be uniquely idenpfiable across sites A global naming scheme can work in homogeneous seengs, but not if local control is required Instead, use a two- field naming scheme: <local name, origin site, [replica id]> stored at origin site Global replica name To find a relapon, look into its origin site catalog Copyright Ben Cartere?e 7 Simple Distributed Queries SelecPng from a single relapon Consider three cases: Horizontally fragmented: querying may require formulapng two subqueries then unioning results VerPcally fragmented: the enpre relapon must be reconstructed before the query can be evaluated Full replicapon: the query can be executed at any one site Any fragmentapon requires sending data over a network, which adds to processing Pme Copyright Ben Cartere?e 8 4

5 Distributed Joins Distributed joins could be very expensive Two simple strategies: Fetch as needed Nested- loop join, transmieng records from one site to another as necessary Network transmission costs dominate, even if indexes can be leveraged Ship to one site Send all the relapons to a single site, then compute join Copyright Ben Cartere?e 9 Semijoin User@site 1 requests join of R1@S1, R2@S2 Three steps: 1. At S1, project R1 to common columns; send to S2 2. At S2, compute natural join of R2 and projecpon of R1 to produce the reduc3on of R2 w.r.t. R1 3. Send the reducpon of R2 back to S1 to complete join Trades cost of compupng and sending projecpons/reducpons for cost of sending full relapon Copyright Ben Cartere?e 10 5

6 Bloomjoin Similar to semijoin, but use bit vectors of length k Steps: At S1, hash common column values into range [0, k- 1]; send resulpng bit vector to S2 At S2, hash each record s join column values into same range; if bit j in received vector is 0, discard record This is the reducpon of S2 w.r.t. S1 Send remaining records back to S1 to be joined Bit vectors can be very small, but collisions are possible Copyright Ben Cartere?e 11 Distributed Query OpPmizaPon Again want to consider all plans and pick the cheapest Three new considerapons: CommunicaPon costs Local site autonomy New distributed join algorithms Query site constructs a global plan along with suggespons for local plans at each site Individual sites are free to change their plans Copyright Ben Cartere?e 12 6

7 Distributed Updates ReplicaPon entails redundancy And therefore possibility of update anomalies Two types of replicapon: Synchronous, in which all copies of the data are updated before the transacpon commits Asynchronous, in which copies of data are periodically updated Asynchronous is more efficient, but requires users to know about the data distribupon Copyright Ben Cartere?e 13 Synchronous ReplicaPon Two algorithms: Vo3ng a modifying transacpon does not update every copy, just a majority When a transacpon executes a read, it reads enough replicapons to guarantee it has the most recent data Expensive due to many reads Read- any write- all modifying transacpons update every copy A reading transacpon can read any copy May be feasible if updates are rare When locking is considered, things get messy Copyright Ben Cartere?e 14 7

8 Asynchronous ReplicaPon Two approaches: In peer- to- peer, one or more copies are designated as masters that can be updated Changes to masters propagate to the secondary copies Different master copies can be modified simultaneously, introducing inconsistencies Conflict resolupon needed to keep data consistent In primary site replicapon, there is only one master that can be updated Capture changes to the master using a snapshot of the relapon Apply changes to secondary copies by sending snapshots periodically Copyright Ben Cartere?e 15 Distributed TransacPons A transacpon submi?ed at one site may be decomposed into subtransac3ons that run on other sites Concurrency control and recovery must take into account the subtransacpons Copyright Ben Cartere?e 16 8

9 Distributed Locking Managing locks on objects across many sites Important for distributed updapng Three approaches: Centralized one site keeps track of all locks Vulnerable to site failure; removes local autonomy Primary copy all locking handled by the site with the primary copy Reading a secondary copy requires two locks: primary copy lock and local lock Fully distributed locking performed by site All sites locked for wripng Copyright Ben Cartere?e 17 Distributed Recovery Allowing recovery across sites is more complicated: New kinds of failures: network connecpons, remote sites For a transacpon to commit, all of its subtransacpons must commit This requires a commit protocol TransacPon logs are maintained at each site Commit protocol acpons are logged with everything else Copyright Ben Cartere?e 18 9

10 Two- Phase Commit (2PC) TransacPon is submi?ed to site 1 (the coordinator) SubtransacPons go to other sites (the subordinates) When it s Pme to commit: Coordinator sends prepare message to subordinates Subordinate writes a prepare log record or abort (if necessary) to local log, then sends yes or no to coordinator If coordinator receives a no, it writes an abort log record and tells all subordinates to abort If coordinator receives all yeses, it writes a commit log record and tells all subordinates to commit Subordinates do what they re told (wripng commit or abort ) and send acks Coordinator writes an end log record aser receiving all acks All log entries include the coordinator ID Coordinator s log records include all subordinate IDs Copyright Ben Cartere?e 19 RestarPng ASer Failure If the log contains a commit or abort record for transacpon T but no end record, must redo or undo If the site is the coordinator, keep sending commit / abort messages unpl ack s received If log has a prepare but not commit or abort, the site is subordinate Keep contacpng coordinator to determine status If no prepare, abort and undo T Unless coordinator wait for subordinate messages Copyright Ben Cartere?e 20 10