Transparency

Distribution Transparency

• Distribution transparency allows user to perceive database as single, logical entity.

• If DDBMS exhibits distribution transparency, user does not need to know:

• Data is fragmented (fragmentation transparency),.

• Location of data items (location transparency).

• Otherwise call this local mapping transparency.

• With replication transparency, user is unaware of replication of fragments.

Naming Transparency:

• Each item in a DDB must have a unique name.

• DDBMS must ensure that no two sites create a database object with same name.

• One solution is to create central name server. However, this results in:

• loss of some local autonomy;

• central site may become a bottleneck;

• low availability; if the central site fails, remaining sites cannot create any new objects.

• Alternative solution - prefix object with identifier of site that created it.

• For example, Branch created at site S₁ might be named S1.BRANCH.

• Also need to identify each fragment and its copies.

• Thus, copy 2 of fragment 3 of Branch created at site S₁ might be referred to as S1.BRANCH.F3.C2.

• However, this results in loss of distribution transparency.

• An approach that resolves these problems uses aliases for each database object.

• Thus, S1.BRANCH.F3.C2 might be known as LocalBranch by user at site S₁.

• DDBMS has task of mapping an alias to appropriate database object.

Transaction Transparency:

• Ensures that all distributed transactions maintain distributed database’s integrity and consistency.

• Distributed transaction accesses data stored at more than one location.

• Each transaction is divided into number of subtransactions, one for each site that has to be accessed.

• DDBMS must ensure the indivisibility of both the global transaction and each of the subtransactions.

Concurrency Transparency:

• All transactions must execute independently and be logically consistent with results obtained if transactions executed one at a time, in some arbitrary serial order.

• Same fundamental principles as for centralized DBMS.

• DDBMS must ensure both global and local transactions do not interfere with each other.

• Similarly, DDBMS must ensure consistency of all subtransactions of global transaction.

Performance Transparency:

• DDBMS must perform as if it were a centralized DBMS.

• DDBMS should not suffer any performance degradation due to distributed architecture.

• DDBMS should determine most cost-effective strategy to execute a request.

Read More

Distributed Transactions

Distributed Transactions

• A distributed transaction is a transaction that updates data on two or more networked computer systems. Distributed transactions extend the benefits of transactions to applications that must update distributed data. Implementing robust distributed applications is difficult because these applications are subject to multiple failures, including failure of the client, the server, and the network connection between the client and server. In the absence of distributed transactions, the application program itself must detect and recover from these failures.

• For distributed transactions, each computer has a local transaction manager. When a transaction does work at multiple computers, the transaction managers interact with other transaction managers via either a superior or subordinate relationship. These relationships are relevant only for a particular transaction.

• Each transaction manager performs all the enlistment, prepare, commit, and abort calls for its enlisted resource managers (usually those that reside on that particular computer). Resource managers manage persistent or durable data and work in cooperation with the DTC to guarantee atomicity and isolation to an application.

Distributed update propagation

• Update propagation in a distributed database is problematic because of the fact that there may be more than one copy of a piece of data because of replication, and data may be split up because of partitioning. Any updates to data performed by any user must be propagated to all copies throughout the database. The use of snapshots is one technique for implementing this.

Distributed concurrency control

• Concurrency control in distributed databases can be done in several ways. Locking and timestamping are two techniques which can be used, but timestamping is generally preferred.

• The problems of concurrency control in a distributed DBMS are more severe than in a centralized DBMS because of the fact that data may be replicated and partitioned. If a user wants unique access to a piece of data, for example to perform an update or a read, the DBMS must be able to guarantee unique access to that data, which is difficult if there are copies throughout the sites in the distributed database.

Distributed Queries Optimization

• In a distributed database the optimization of queries by the DBMS itself is critical to the efficient performance of the overall system. Query optimization must take into account the extra communication costs of moving data from site to site, but can use whatever replicated copies of data are closest, to execute a query. Thus it is a more complex operation than query optimization in centralized databases.

Query optimization overview

• Query optimization is essential if a DBMS is to achieve acceptable performance and efficiency. Relational database systems based on the relational model and relational algebra have the strength that their relational expressions are at a sufficiently high level so query optimization is feasible in the first place; in non-relational systems, user requests are low level and optimization is done manually by the user - the system cannot help. Hence systems which implement optimization have several advantages over systems that do not.

• The optimization process itself involves several stages, which involves the implementation of the relational operators. A different approach to query optimization, called semantic optimization has recently been suggested.

• This technique may be used in combination with the other optimization techniques and uses constraints specified on the database schema. Consider the SQL query:

SELECT E.LNAME FROM EMPLOYEE E M WHERE E.SSN = M.SSN AND E.SALARY > M.SALARY This query retrieves the names of employees who earn more than their supervisors.

• Suppose we had a constraint on the database schema that states that no employee can earn more than their supervisor. If the semantic query optimizer checks for the existence of this constraint, then it need not execute the query at all. This may save considerable time if the checking for constraints can be done efficiently; however, searching through many constraints to find ones applicable to a given query can also be quite time consuming.

Timestamping

• Timestamping is a method of concurrency control where basically, all transactions are given a timestamp or unique date/time/site combination and the database management system uses one of a number of protocols to schedule transactions which require access to the same piece of data.

• While more complex to implement than locking, timestamping does avoid deadlock occurring by avoiding it in the first place

Read More

Data Fragmentation &Allocation

Data Fragmentation

• Relation may be divided into a number of sub-relations, which are then distributed.

Benefits:

• Usage

• Applications work with views rather than entire relations.

• Efficiency

• Data is stored close to where it is most frequently used.

• Data that is not needed by local applications is not stored.

• Parallelism

• With fragments as unit of distribution, transaction can be divided into several sub queries that operate on fragments.

• Security

• Data not required by local applications is not stored and so not available to unauthorized users.

Types of Fragmentation

• Four types of fragmentation:

• Horizontal.

• Vertical.

• Mixed.

• Derived.

• Other possibility is no fragmentation:

• If relation is small and not updated frequently, may be better not to fragment relation.

Data Allocation:

• Each fragment is stored at site with “optimal” distribution

• Four alternative strategies regarding placement of data:

• Centralized.

• Partitioned (or Fragmented).

• Complete Replication,

• Selective Replication.

• Centralized

• Consists of single database and DBMS stored at one site with users distributed across the network.

• Partitioned

• Database partitioned into disjoint fragments, each fragment assigned to one site.

• Complete Replication

• Consists of maintaining complete copy of database at each site.

• Selective Replication

• Combination of partitioning, replication, and centralization.

Read More

Distributed database

     A logically reticulated collection of shared information (and an outline of this data), physically distributed over a network.

A logically reticulated collection of shared information (and an outline of this data), physically distributed over a network.
Read more at http://smallseotools.com/article-rewriter/#XTJdjtUQ9LrUrlbo.99

A logically reticulated collection of shared information (and an outline of this data), physically distributed over a network.
Read more at http://smallseotools.com/article-rewriter/#XTJdjtUQ9LrUrlbo.99

Distributed software system

       Software system that allows the management of the distributed information and makes the distribution clear to users.
Distributed information system (DDBS) = DDB + DDBMS

Distributed database features:

• information hold on at variety of web sites, every web site logically single processor

• Sites square measure interconnected by a network instead of a digital computer configuration

• DDB is logically one information (although every web site may be a information site)

• DDBMS has full practicality of a software system

• To the user, the distributed information system ought to seem specifically sort of a non-distributed information system.

Distributed database advantages:

• Reduced Communication Overhead : Most information access is native, less costly and performs higher.

• Improved process Power : rather than one server handling the complete information, we tend to currently have a group of machines handling a similar information.

• Removal of Reliance on a Central web site

• Expandability

• native autonomy

The information is brought nearer to its users. this will impact a cultural modification because it permits doubtless bigger management over native information.

Distributed database disadvantages:

• complexness (greater potential for bugs in software)

• price (software development may be far more complicated and thus pricey. Also, exchange of messages and extra computations involve increased  overheads)

• distribution of management (no single information administrator controls the DDB)

• security (since the system is distributed the possibilities of security lapses square measure greater)

• troublesome to alter (since all sites have management of their own sites)

• lack of expertise (enough expertise isn't on the market in developing distributed systems)

DDBMS rules:

•     No reliance on a central web site
•     Continuous operation
•     Location independence
•     Fragmentation independence
•     Replication independence
•     Distributed question independence
•     Distributed dealings process
•     Hardware independence
•     OS independence
•     Network independence
•     information independence

Distributed database Issues:

•     information Fragmentation
•     information Allocation
•     information Replication
•     Distributed Catalogue Management
•     Distributed Transactions
•     Distributed Queries optimisation
•     Distributed update propagation
•     Distributed concurrency management

Read More

Parallel DBMS Concept

• A database management system that is implemented on a tightly coupled multiprocessor.

• seeks to improve performance through parallelization of various operations, such as data loading, index building and query evaluating।
WHY DO WE NEED it?

• More and More Data!

•We have databases that hold a high amount of data, in the order of 1012 bytes: 10,000,000,000,000 bytes!

• Faster and Faster Access!

• We have data applications that need to process data at very high speeds: 10,000s transactions per second!
SINGLE-PROCESSOR DBMS AREN’T UP TO THE JOB!

Read More

Database Problem

•Large volume of data

-> use disk and large main memory

• I/O bottleneck (or memory access bottleneck)

->Speed(disk) << speed(RAM) <

• Predictions

->processor speed growth : 50 % per year

->DRAM capacity growth : 4x every three years

->Disk throughput : 2x in the last ten years

Read More