Database System Architectures

Transaction Server System

A typical transaction-server system today consists of multiple processes accessing data in shared memory.

Server processes: These are processes that receive user queries (transactions), execute them, and send the results

back.

Lock manager process: This process implements lock manager functionality, which includes lock grant, lock release,

and deadlock detection.

Database writer process: There are one or more processes that output modified buffer blocks back to disk on a

continuous basis.

Log writer process: This process outputs log records from the log record buffer to stable storage.

Checkpoint process: This process performs periodic checkpoints. It consults log to determine those transactions

that need to redone or undone.

Process monitor process: This process monitors other processes, and if any of them fails, it takes recovery actions

for the process.

What is a Distributed Database System?

We define a distributed database as a collection of multiple, logically interrelated databases distributed over

a computer network. A distributed database management system (distributed DBMS) is then defined as the

software system that permits the management of the distributed database and makes the distribution

transparent to the users.

Peer-to-Peer Distributed Systems

9

Promises of DDBSs

Transparent management of distributed and replicated data.

Reliable access to data through distributed transactions

Improved performance and

Easier system expansion. Transparent Management of Distributed and Replicated Data Reliability through Distributed Transactions Improved Performance Easier System Expansion

Complications Introduced by DDBS

1. Data may be replicated in a distributed environment. A distributed database can be designed so

that the entire database, or portions of it, reside at different sites of a computer network.

2. If some sites fail or if some communication links fail while an update is being executed, the system

must make sure that the effects will be reflected on the data residing at the failing or unreachable

sites as soon as the system can recover from the failure.

3. The exchange of messages and the additional computation required to achieve inter-site coordination are a form of overhead that does not arise in centralized systems.

4. As data in a distributed DBMS are located at multiple sites, the probability of security lapses increases. Further, all communications between different sites in a distributed DBMS are conveyed through the network, so the underlying network has to be made secure to maintain system security.

5. Since each site cannot have instantaneous information on the actions currently being carried out at the other sites, the synchronization of transactions on multiple sites is considerably harder than for a centralized system.

Correctness Rules for Data Fragmentation

To ensure no loss of information and no redundancy of data, there are three different rules that must be considered

during fragmentation.

Completeness

If a relation instance R is decomposed into fragments R1, R2, . . . .Rn, each data item in R must appear in at least one

of the fragments. It is necessary in fragmentation to ensure that there is no loss of data during data fragmentation.

Reconstruction

If relation R is decomposed into fragments R1, R2, . . . .Rn, it must be possible to define a relational operation that

will reconstruct the relation R from fragments R1, R2, . . . .Rn. This rule ensures that constrains defined on the data

are preserved during data fragmentation.

To ensure no loss of information and no redundancy of data, there are three different rules that must be considered

during fragmentation.

Disjointness

If a relation R is decomposed into fragments R1, R2, . . . .Rn and if a data item is found in the fragment Ri, then it must

not appear in any other fragments. This rule ensures minimal data redundancy.

In case of vertical fragmentation, primary key attribute must be repeated to allow reconstruction. Therefore, in case

of vertical fragmentation, disjointness is defined only on non-primary key attributes of a relation.

Example (Horizontal Fragmentation)

P1: σproject-type = “inside”

(Project)

P2: σproject-type = “abroad

Example (Horizontal Fragmentation)

These horizontal fragments satisfy all the correctness rules of fragmentation as shown below.

Completeness: Each tuple in the relation Project appears either in fragment P1 or P2. Thus, it satisfies completeness

rule for fragmentation.

Reconstruction: The Project relation can be reconstructed from the horizontal fragments P1 and P2 by using the

union operation of relational algebra, which ensures the reconstruction rule.

Thus, P1 P2 = Project.

Disjointness: The fragments P1 and P2 are disjoint, since there can be no such project whose project type is both

“inside” and “abroad”.

Example (Vertical Fragmentation)

Example (Vertical Fragmentation)

These vertical fragments also ensure the correctness rules of fragmentation as shown below.

Completeness: Each tuple in the relation Project appears either in fragment V1 or V2 which satisfies completeness

rule for fragmentation.

Reconstruction: The Project relation can be reconstructed from the vertical fragments V1 and V2 by using the

natural join operation of relational algebra, which ensures the reconstruction rule.

Thus, V1 ⋈ V2 = Project.

Disjointness: The fragments V1 and V2 are disjoint, except for the primary key project-id, which is repeated in both

fragments and is necessary for reconstruction.

Distributed Database System Design Issues

Distributed Database Design

Distributed Directory Management

Distributed Query Processing

Distributed Concurrency Control

Distributed Deadlock Management

Reliability of Distributed DBMS

Replication

Relationship among Problems

Components of a Distributed DBMS

Major two components:

User Processor: Handles the interaction with users and

Data Processor: Deals with the storage.

Multidatabase System (MDBS) Architecture

Multidatabase systems (MDBS) represent the case where individual DBMSs (whether distributed or not) are fully

autonomous and have no concept of cooperation;

They may not even “know” of each other’s existence or how to talk to each other.

MDBS Architecture

Fig.: MDBS Architecture with a GCS

LIS1 LIS

n . . . .

LCS1 LCS

n

. . . .

LES11

LES12

LES13

LESn1

LESn2

LESn3

GES1 GES

2 GES

3

GCS

MDBS Architecture

1. Users of a local DBMS define their own views on the local database and do not need to change their

applications if they do not want to access data from another database. This is again an issue of

autonomy.

2. Designing the global conceptual schema in multidatabase systems involves the integration of either

the local conceptual schemas or the local external schemas.

3. Once the GCS has been designed, views over the global schema can be defined for users who require

global access. It is not necessary for the GES and GCS to be defined using the same data model and

language; whether they do or not determines whether the system is homogeneous or heterogeneous.

Functional Aspects Provided by Parallel Database Systems

Ideally, a parallel database system should have the following functional aspects.

High-performance: This can be obtained through several complementary solutions: database-oriented operating

system support, parallelism, optimization, and load balancing.

High-availability: Because a parallel database system consists of many similar components, it can exploit data

replication to increase database availability.

Extensibility: It is the ability of smooth expansion of the system by adding processing and storage power to the

system. Ideally, the parallel database system should provide two extensibility advantages:

Linear Speedup and

Linear Scaleup.

Linear Speedup refers to a linear increase in performance for a constant database size and linear increase in

processing and storage power.

Linear Scaleup refers to a sustained performance for a linear increase in both database size and processing and

storage power.

Parallel Architectures

There are three basic parallel computer architectures depending on how main memory or disk is shared:

I. Shared-memory,

II. Shared-disk and

III. Shared-nothing.

Shared-Memory

In the shared-memory approach any processor has access to any memory module or disk unit through a fast

interconnect (e.g. a high-speed bus). All the processors are under the control of a single operating system.

Shared-Memory

Advantages: simplicity and load balancing

Problems: high cost, limited extensibility and low availability.

Example: XPRS, DBS3, and Volcano.

Components of Parallel DBM Architecture

It has three major components or subsystems.

Session Manager: It performs the connections and disconnections between the client processes and the two other

subsystems.

Transaction Manager: It receives client transactions related to query compilation and execution. It can access the

database directory that holds all meta-information about data and programs. Depending on the transaction, it

activates the various compilation phases, triggers query execution, and returns the results as well as error codes to

the client application.

Components of Parallel DBM Architecture

Data Manager: It provides all the low-level functions needed to run compiled queries in parallel.

Data Partitioning Techniques

There are three basic strategies for data partitioning:

• Round-robin,

• Hash and

• Range partitioning.

Data Partitioning Techniques

Round-robin partitioning is the simplest strategy. It ensures uniform data distribution. With n partitions, the ith

tuple in insertion order is assigned to partition (i mod n).

Hash partitioning applies a hash function to some attribute that yields the partition number. This strategy allows

exact-match queries on the selection attribute to be processed by exactly one node and all other queries to be

processed by all the nodes in parallel.

Range partitioning distributes tuples based on the value intervals of some attribute. It is well-suited for range

queries. However, range partitioning can result in high variation in partition size.

Indexing and Hashing

Hash File Organization In a hash file organization, we obtain the address of the disk block, also called the bucket containing

a desired record directly by computing a function on the search-key value of the record.

Let K denote the set of all search-key values, and let B denote the set of all bucket addresses. A hash

function h is a function from K to B. Let h denote a hash function.

To insert a record with search key Ki, we compute h(Ki), which gives the address of the bucket for

that record. Assume for now that there is space in the bucket to store the record. Then, the record

is stored in that bucket.

Hash File Organization: An Example

Let us choose a hash function for the account file using the search key branch_name.

Suppose we have 26 buckets and we define a hash function that maps names beginning with the

ith letter of the alphabet to the ith bucket.

This hash function has the virtue of simplicity, but it fails to provide a uniform distribution, since we

expect more branch names to begin with such letters as B and R than Q and X.

Hash Indices Hashing can be used not only for file organization, but also for index-structure creation. We

construct a hash index as follows. We apply a hash function on a search key to identify a bucket,

and store the key and its associated pointers in the bucket.Hash Indices

DDBMS

Transparency – It refers to the separation of the high-level semantics of a system from lower-level implementation

issues. In a distributed system, it hides the implementation details from users of the system.

– The user believes that he/she is working with a centralized database system and that all the

complexities of a distributed database system are either hidden or transparent to the user.

– Four main categories of transparencies:

• Distribution transparency

• Transaction transparency

• Performance transparency

• DBMS transparency

A Model for Transaction Management in DDBMS – Access to the various data items in a distributed system is usually accomplished through

transactions which must preserve the ACID properties. There are two types of transaction that we

need to consider.

• The local transactions are those that access and update data in only local database.

• The global transactions are those that access and update data in several local databases.

Ensuring the ACID properties of local transactions can be done easily. However, for global transactions, this task is

much more complicated, since several sites are participating in execution. A model for transaction management at

each site of a distributed system is shown below.

Fig. A Model for Transaction Management at each site in a DDBMS

– It consists of two sub-modules:

• Transaction Manager (TM) and

• Transaction Coordinator (TC)

Concurrency Control Anomalies

Different anomalies can arise due to concurrent access of data:

– Lost update anomaly – This occurs when a successful completed update operation made by one

transaction is overridden by another transaction.

– Uncommitted dependency – This problem occurs when one transaction allows other transactions

to read its data before it has committed and then decides to abort.

– Inconsistent analysis anomaly – The problem occurs when a transaction reads several values from

the database but a second transaction updates some of them during the execution of the first.

– Phantom read anomaly – This anomaly occurs when a transaction performs some operation on the

database based on a selection predicate, another transaction inserts new tuples satisfying that

predicate into the same database. This is known as phantom read.

– Multiple-copy consistency problem – This occurs when data items are replicated and stored at

different sites. To maintain the consistency, when a replicated data item is updated at one site, all

other copies must be updated. Otherwise, the database becomes inconsistent.

Two-Phase Locking (2PL) Protocol

The 2PL protocol states that no transaction should acquire a lock after it releases one of its lock.

According to this protocol, the life time of each transaction is divided into two phases:

Growing phase and

Shrinking phase.

In growing phase, a transaction can obtain locks on data items and can access data items, but it can not release any

locks.

In shrinking phase, a transaction can release locks but cannot acquire any new locks after that. Thus, the ending of

growing phase of a transaction determines the beginning of the shrinking phase of that transaction. It is not

necessary for each transaction to acquire all locks simultaneously and then start processing. Normally, each

transaction obtains some locks initially, does some processing and then requests for new additional locks that are

required. However, it never releases any lock until it has reached a stage where no more locks are required. If up-

gradation and down-gradation are allowed, then up-gradation of locks can take place in the growing phase, whereas

down-gradation of locks can occur in the shrinking phase.

Distributed Deadlock Prevention Method

Wait-die is a non-preemptive deadlock prevention technique based on timestamp values of transactions:

In this technique, when one transaction is about to block and is waiting for a lock on a data item that is

already locked by another transaction, timestamp values of both the transactions are checked to give priority to the

older transaction. If a younger transaction is holding the lock on data item then the older transaction is allowed to

wait, but if an older transaction is holding the lock, the younger transaction is aborted and restarted with the same

timestamp value. This forces the wait-for graph to be directed from the older to the younger transactions, making

cyclic restarts impossible. For example, if the transaction Ti requests a lock on a data item that is already locked by

the transaction Tj, then Ti is permitted to wait only if Ti has a lower timestamp value than Tj. On the other hand, if Ti

is younger than Tj, then Ti is aborted and restarted with the same timestamp value.

Wound-Wait is an alternative preemptive deadlock prevention technique by which cyclic restarts can be avoided.

In this method, if a younger transaction requests for a lock on a data item that is already held by an older

transaction, the younger transaction is allowed to wait until the older transaction releases the corresponding lock.

In this case, the wait-for graph flows from the younger to the older transactions, and cyclic restart is again avoided.

For instance, if the transaction Ti requests a lock on a data item that is already locked by the transaction Tj, then Ti

is permitted to wait only if Ti has a higher timestamp value than Tj, otherwise, the transaction Tj is aborted and the

lock is granted to the transaction Ti.

Centralized Deadlock detection

In Centralized Deadlock detection method, a single site is chosen as Deadlock Detection Coordinator (DDC)

for the entire distributed system. The DDC is responsible for constructing the GWFG for system. Each lock manager

in the distributed database transmits its LWFG to the DDC periodically. The DDC constructs the GWFG from these

LWFGs and checks for cycles in it. The occurrence of a global deadlock situation is detected if there are one or more

cycles in the GWFG. The DDC must break each cycle in the GWFG by selecting the transactions to be rolled back and

restarted to recover from a deadlock situation. The information regarding the transactions that are to be rolled back

and restarted must be transmitted to the corresponding lock managers by the deadlock detection coordinator.

Centralized Deadlock detection

– The centralized deadlock detection approach is very simple, but it has several drawbacks.

– This method is less reliable, as the failure of the central site makes the deadlock detection

impossible.

– The communication cost is very high in the case, as other sites in the distributed system send their

LWFGs to the central site.

– Another disadvantage of centralized deadlock detection technique is that false detection of

deadlocks can occur, for which the deadlock recovery procedure may be initiated, although no

deadlock has occurred. In this method, unnecessary rollbacks and restarts of transactions may also

result owing to phantom deadlocks.