CP363 : Distributed Databases

A distributed computing system consists of a number of processing elements connected by a computer network. Tasks are distributed amongst these components. A distributed database (DDB) is a group of interconnected databases spread over a network, and a distributed database management system (DDBMS) is system software that manages a DDB To a user, a distributed database looks the same as a centralized database.

Types of multiprocessor system architecture:

shared memory architecture

• multiple processors share primary and secondary (disk) memory

shared disk architecture

• multiple processors share disks

shared nothing architecture

• multiple processors share only a network bus
• (in this case all processing elements are the same type)

In more widely-spread architectures multiple servers are connected by a communication network. The various servers need not be of the same type, merely share the same DDBMS.

Why distributed database?

Data distributed amongst many sites is more likely to be always available, and may be closer to where it is needed most. Ttransactions too are distributed amongst many sites, thus spreading the load. Some transactions may have various elements run in parallel (subqueries, for example). Expansion is easier in terms of adding more data, processors, or increasing data size.

Database must be transparent in a number of ways:

• location transparency: tasks operate independent of where data they operate on is located, and where task is issued
• naming transparency: named objects can be accessed from anywhere in the network; names are unique
• replication transparency: copies of data may be stored at multiple sites for better availability, performance, and reliability
• fragmentation transparency: user unaware of fragmentation of data
  • horizontal fragmentation - tables are split up by tuples according to particular rules. Derived horizontal fragmentation applies to tables related to original fragmented tables by foreign keys
  • vertical fragmentation - tables are split up according to attributes. Each fragment must contain the primary key in order to be able to reconstruct original tuples. Such duplicated primary keys are invisible to the user.
  • mixed fragmentation - distributed database may apply both horizontal and vertical fragmentation to the same table
  • fragments may or may not be disjoint, i.e. fragments contain no common tuples or attributes (with the exception of primary keys)

Issues:

Distributed systems add a great deal of overhead that must be dealt with for the system to work properly.

• keeping track of data
• distributed query processing
• distributed transaction management
• replicated data management
• distributed database recovery
• security
• distributed catalog management

Replication

fully replicated distributed database: entire database is copied to multiple sites - great for availability and reliability, not so great for updates

non-redundant allocations: no data is repeated between sites, i.e. all fragments are disjoint

partial replication: some fragments may be replicated at some sites. Especially prevalent where mobile workers need access to data in the field; sales people, insurance claims adjustors, financial planners

Optimizing fragment allocation is a difficult problem in optimization. Where is data most likely updated? Where is it most likely accessed? How important is 100% up time? How fast/easy is communication between systems?

Types of Distributed Database Systems

homogenous - all servers and software are of the same type

heterogenous - not the above

local autonomy - implies direct access by local transactions to a server allowed

Federated Database Management System (FDBS)

A heterogenous database system. Needs a global schema manager to coordinate all of the disparate data elements together.

multidatabase system

Also hetergenous, but does not have a global schema manager - constructs one on the fly as needed by an application.

Concurrency Control and Recovery in Distributed Databases

Problems unique to a distributed environment:

• multiple copies of data items - consistency between copies must be enforced
• individual site failure - database should continue to operate even with individual site failures
• communication link failure - database should continue to operate even with individual link failures
• distributed commit - commits must deal with site and link failures
• distributed deadlock - deadlocks may occur amongst several sites