A distributed database is a database in which storage devices are not all
attached to a common processing unit such as the CPU, controlled by a
distributed database management system. It may be stored in multiple computers,
located in the same physical location; or may be dispersed over a network of
interconnected computers. Unlike parallel systems, in which the
processors are tightly coupled and constitute a single database system, a
distributed database system consists of loosely coupled sites that share no
physical components. System administrators can distribute
collections of data across multiple physical locations. A distributed
database can reside on network servers on the Internet, on corporate intranets
or extranets, or on other company networks. Because they store data across
multiple computers, distributed databases can improve performance at
end-user worksites by allowing transactions to be processed on many
machines, instead of being limited to one.
Two processes ensures that the distributed databases remain up-to-date
and current: replication and duplication.
Replication involves using specialized software that looks for changes in the
distributive database. Once the changes have been identified, the replication
process makes all the databases look the same. The replication process can be
complex and time-consuming depending on the size and number of the distributed
databases. This process can also require a lot of time and computer resources.
Duplication, on the other hand, has less complexity. It basically identifies one
database as a master and then duplicates that database. The duplication process
is normally done at a set time after hours. This is to ensure that each
distributed location has the same data. In the duplication process, users may
change only the master database. This ensures that local data will not be
overwritten. Both replication and duplication can
keep the data current in all distributive locations.
Besides distributed database replication and fragmentation, there are many other
distributed database design technologies. For example, local
autonomy, synchronous and asynchronous distributed database technologies. These
technologies' implementations can and do depend on the needs of the business and
the sensitivity/confidentiality of the data stored in the database, and hence
the price the business is willing to spend on ensuring data security,
consistency and integrity. When discussing access to distributed
databases, Microsoft favors the term distributed query, which it defines in
protocol-specific manner as "[a]ny SELECT, INSERT, UPDATE, or DELETE
statement that references tables and rowsets from one or more external OLE DB
data sources". Oracle provides a more language-centric view in which
distributed queries and distributed transactions form part of distributed
SQL. Today the distributed DBMS market is
evolving dramatically, with new, innovative entrants and incumbents
supporting the growing use of unstructured data and NoSQL DBMS
engines, as well as XML databases and NewSQL databases. These databases are
increasingly supporting distributed database architecture that provides high
availability and fault tolerance through replication and scale out ability. Some
examples are Aerospike, Cassandra, Clusterpoint, ClustrixDB, Couchbase,
Druid, FoundationDB, NuoDB, Riak and OrientDB. The block chain technology
popularised by bitcoin is an implementation of a distributed
database. Architecture
A database user accesses the distributed database through:
Local applications applications which do not require data
from other sites. Global applications
applications which do require data from other sites.
A homogeneous distributed database has identical software and hardware running
all databases instances, and may appear through a single interface as if it were
a single database. A heterogeneous distributed database may have different
hardware, operating systems, database management systems, and even data models
for different databases. = Homogeneous Distributed Databases
Management System= In homogeneous distributed database all
sites have identical software and are aware of each other and agree to
cooperate in processing user requests. Each site surrenders part of its
autonomy in terms of right to change schema or software. A homogeneous DDBMS
appears to the user as a single system. The homogeneous system is much easier to
design and manage. The following conditions must be satisfied for
homogeneous database: The operating system is used, at each
location must be same or compatible. The data structures used at each
location must be same or compatible. The database application used at each
location must be same or compatible. = Heterogeneous DDBMS=
In a heterogeneous distributed database, different sites may use different schema
and software. Difference in schema is a major problem for query processing and
transaction processing. Sites may not be aware of each other and may provide only
limited facilities for cooperation in transaction processing. In heterogeneous
systems, different nodes may have different hardware & software and data
structures at various nodes or locations are also incompatible. Different
computers and operating systems, database applications or data models may
be used at each of the locations. For example, one location may have the
latest relational database management technology, while another location may
store data using conventional files or old version of database management
system. Similarly, one location may have the Windows NT operating system, while
another may have UNIX. Heterogeneous systems are usually used when individual
sites use their own hardware and software. On heterogeneous system,
translations are required to allow communication between different sites.
In this system, the users must be able to make requests in a database language
at their local sites. Usually the SQL database language is used for this
purpose. If the hardware is different, then the translation is straightforward,
in which computer codes and word-length is changed. The heterogeneous system is
often not technically or economically feasible. In this system, a user at one
location may be able to read but not update the data at another location.
Important considerations Care with a distributed database must be
taken to ensure the following: The distribution is transparent — users
must be able to interact with the system as if it were one logical system. This
applies to the system's performance, and methods of access among other things.
Transactions are transparent — each transaction must maintain database
integrity across multiple databases. Transactions must also be divided into
sub-transactions, each sub-transaction affecting one database system.
There are two principal approaches to store a relation r in a distributed
database system: A) Replication
B) Fragmentation/Partitioning A) Replication: In replication, the
system maintains several identical replicas of the same relation r in
different sites. Data is more available in this scheme.
Parallelism is increased when read request is served.
Increases overhead on update operations as each site containing the replica
needed to be updated in order to maintain consistency.
Multi-datacenter replication provides geographical diversity, like in
Clusterpoint or Riak. B) Fragmentation: The relation r is
fragmented into several relations r1, r2, r3....rn in such a way that the
actual relation could be reconstructed from the fragments and then the
fragments are scattered to different locations. There are basically two
schemes of fragmentation: Horizontal fragmentation - splits the
relation by assigning each tuple of r to one or more fragments.
Vertical fragmentation - splits the relation by decomposing the schema R of
relation r. A distributed database can be run by
independent or even competing parties as, for example, in bitcoin or Hasq.
Advantages Management of distributed data with
different levels of transparency like network transparency, fragmentation
transparency, replication transparency, etc.
Increase reliability and availability Easier expansion
Reflects organizational structure — database fragments potentially stored
within the departments they relate to Local autonomy or site autonomy — a
department can control the data about them
Protection of valuable data — if there were ever a catastrophic event such as a
fire, all of the data would not be in one place, but distributed in multiple
locations Improved performance — data is located
near the site of greatest demand, and the database systems themselves are
parallelized, allowing load on the databases to be balanced among servers.
Economics — it may cost less to create a network of smaller computers with the
power of a single large computer Modularity — systems can be modified,
added and removed from the distributed database without affecting other modules
Reliable transactions - due to replication of the database
Hardware, operating-system, network, fragmentation, DBMS, replication and
location independence Continuous operation, even if some nodes
go offline Distributed query processing can improve
performance Single-site failure does not affect
performance of system. For those systems that support full
distributed transactions, operations enjoy the ACID properties:
A-atomicity, the transaction takes place as a whole or not at all
C-consistency, maps one consistent DB state to another
I-isolation, each transaction sees a consistent DB
D-durability, the results of a transaction must survive system failures
The Merge Replication Method is popularly used to consolidate the data
between databases. Disadvantages
Complexity — DBAs may have to do extra work to ensure that the distributed
nature of the system is transparent. Extra work must also be done to maintain
multiple disparate systems, instead of one big one. Extra database design work
must also be done to account for the disconnected nature of the database —
for example, joins become prohibitively expensive when performed across multiple
systems. Economics — increased complexity and a
more extensive infrastructure means extra labour costs
Security — remote database fragments must be secured, and they are not
centralized so the remote sites must be secured as well. The infrastructure must
also be secured. Difficult to maintain integrity — but in
a distributed database, enforcing integrity over a network may require too
much of the network's resources to be feasible
Inexperience — distributed databases are difficult to work with, and in such a
young field there is not much readily available experience in "proper"
practice Lack of standards — there are no tools
or methodologies yet to help users convert a centralized DBMS into a
distributed DBMS Database design more complex — In
addition to traditional database design challenges, the design of a distributed
database has to consider fragmentation of data, allocation of fragments to
specific sites and data replication Additional software is required
Operating system should support distributed environment
Concurrency control poses a major issue. It can be solved by locking and
timestamping. Distributed access to data
Analysis of distributed data See also
Centralized database Data grid
Distributed data store Distributed cache
Routing protocol External links
Distributed Database References
M. T. Özsu and P. Valduriez, Principles of Distributed Databases, Springer, ISBN
978-1-4419-8833-1 Elmasri and Navathe, Fundamentals of
database systems, Addison-Wesley Longman, ISBN 0-201-54263-3
Oracle Database Administrator's Guide 10g,
racle.comB14117_01b10739/ds_concepts.htm