Docstoc

Distributed Databases - PowerPoint

Document Sample
Distributed Databases - PowerPoint Powered By Docstoc
					Distributed Databases


       by Chien-Pin Hsu
       CS157B Section 1
         Nov 11, 2004


        Dr. Sin-Min Lee
       Distributed Database System

A distributed database system consists of
 loosely coupled sites that share no physical
 component
Appears to user as a single system
Database systems that run on each site are
 independent of each other
Processing maybe done at a site other than the
 initiator of request
 Homogenous Distributed Database
           Systems


 All sites have identical software
 They are aware of each other and agree to
 cooperate in processing user requests
 It appears to user as a single system
   An Homogenous Distributed Database
           Systems example




 A distributed system connects three databases: hq, mfg, and sales
 An application can simultaneously access or modify the data in
  several databases in a single distributed environment.
              What can we do?

A single query from a Manufacturing client on
 local database mfg can retrieve joined data from
 the products table on the local database and the
 dept table on the remote hq database.
 For a client application, the location and
 platform of the databases are transparent.
             Makes life easier!!

For example, if you are connected to database
 mfg but want to access data on database hq,
 creating a synonym on mfg for the remote dept
 table enables you to issue this query:
           SELECT *
           FROM         dept
In this way, a distributed system gives the
 appearance of native data access.
 Users on mfg do not have to know that the data
 they access resides on remote databases.
Heterogeneous Distributed Database
            System

   In a heterogeneous distributed
    database system, at least one of the
    databases uses different schemas and
    software.

     A database system having different schema may
      cause a major problem for query processing.
     A database system having different software may
      cause a major problem for transaction processing.
           Distributed Data Storage

 Replication
  – System maintains multiple copies of data, stored in
    different sites, for faster retrieval and fault tolerance.
 Fragmentation
  – Relation is partitioned into several fragments stored in
    distinct sites


Replication and fragmentation can be combined
  • Relation is partitioned into several fragments: system
    maintains several identical replicas of each such
    fragment.
      Advantages of Replication

Availability: failure of site containing relation
 r does not result in unavailability of r is
 replicas exist.
Parallelism: queries on r may be processed
 by several nodes in parallel.
Reduced data transfer: relation r is available
 locally at each site containing a replica of r.
    Disadvantages of Replication

Increased cost of updates: each replica of
 relation r must be updated.
Increased complexity of concurrency
 control: concurrent updates to distinct
 replicas may lead to inconsistent data unless
 special concurrency control mechanisms are
 implemented.
  • One solution: choose one copy as primary copy
    and apply concurrency control operations on
    primary copy.
               Fragmentation

 Data can be distributed by storing individual
 tables at different sites
 Data can also be distributed by decomposing a
 table and storing portions at different sites –
 called Fragmentation
 Fragmentation can be horizontal or vertical
            Why use Fragmentation?

 Usage - in general applications use views so it’s appropriate to
  work with subsets
 Efficiency - data stored close to where it is most frequently used
 Parallelism - a transaction can divided into several sub-queries to
  increase degree of concurrency
 Security - data more secure - only stored where it is needed



Disadvantages:
Performance - may be slower
Integrity - more difficult
        Horizontal Fragmentation



Each fragment, Ti , of table T contains a
 subset of the rows
Each tuple of T is assigned to one or more
 fragments.
Horizontal fragmentation is lossless
      Horizontal Fragmentation Example




 A bank account schema has a relation
   Account-schema = (branch-name, account-number, balance).
 It fragments the relation by location and stores each fragment
  locally: rows with branch-name = `Hillside` are stored in the Hillside
  in a fragment
             Vertical Fragmentation

 Each fragment, Ti, of T contains a subset of the
  columns, each column is in at least one fragment,
  and each fragment includes the key:
             Ti = attr_listi (T)
           T = T1        T2 …..    Tn

    All schemas must contain a common candidate key (or
     superkey) to ensure lossless join property.
    A special attribute, the tuple-id attribute may be added to
     each schema to serve as a candidate key.
      Vertical Fragmentation Example




A employee-info schema has a relation
  employee-info schema = (designation, name,
 Employee-id, salary).
It fragments the relation to put information in two
 tables for security concern.
                Commit Protocols

 Commit protocols are used to ensure
 atomicity across sites

   Atomicity states that database modifications must
    follow an “all or nothing” rule.
   a transaction which executes at multiple sites must
    either be committed at all the sites, or aborted at all
    the sites.
 The Two-Phase Commit (2 PC) Protocol
What is this?

   Two-phase commit is a transaction protocol designed
    for the complications that arise with distributed
    resource managers.
   Two-phase commit technology is used for hotel and
    airline reservations, stock market transactions,
    banking applications, and credit card systems.
   With a two-phase commit protocol, the distributed
    transaction manager employs a coordinator to
    manage the individual resource managers. The
    commit process proceeds as follows:
      Phase1: Obtaining a Decision

Step 1  Coordinator asks all participants
 to prepare to commit transaction Ti.

   Ci adds the records <prepare T> to the log
    and forces log to stable storage (a log is a file
    which maintains a record of all changes to the
    database)

   sends prepare T messages to all sites where
    T executed
         Phase1: Making a Decision

Step 2  Upon receiving message, transaction
 manager at site determines if it can commit the
 transaction
   if not:
       add a record <no T> to the log and send abort T
      message to Ci
   if the transaction can be committed, then:
      1). add the record <ready T> to the log
      2). force all records for T to stable storage
      3). send ready T message to Ci
      Phase 2: Recording the Decision

 Step 1  T can be committed of Ci received a ready T
  message from all the participating sites: otherwise T
  must be aborted.

 Step 2  Coordinator adds a decision record, <commit
  T> or <abort T>, to the log and forces record onto stable
  storage. Once the record is in stable storage, it cannot
  be revoked (even if failures occur)

 Step 3  Coordinator sends a message to each
  participant informing it of the decision (commit or abort)

 Step 4  Participants take appropriate action locally.
Two-Phase Commit Diagram
           Costs and Limitations

There have been two performance issues
 with two phase commit:
  – If one database server is unavailable, none of
    the servers gets the updates.
  – This is correctable through network tuning
    and correctly building the data distribution
    through database optimization techniques.

				
DOCUMENT INFO