Distributed Database Systems

• Luis Eduardo Bautista Villalpando, PhD is the instructor.
• Course page: https://rooster.uaa.mx/?page_id=132.
• Email: [email protected].

Lecture Outline

• A distributed DBMS intro.
• Distributed DBMS architecture.
• Background info.
• Distributed database design.
• Database integration.
• Semantic Data Control.
• Distributed query processing.
• Multidatabase query processing.
• Distributed transaction management.
• Data replication.
• Parallel database systems.
• Distributed object DBMS.
• Peer-to-peer data management.
• Web data management
• Current issues.

Introduction

• A Distributed Database System (DDBS) results from combining "Database Systems" and "Computer Network" technologies.
• Initially, each application defined and managed its own data via file systems.
• Now, data is centrally defined and administered through Database Management.
• Data independence means application programs aren't affected by logical or physical changes.
• Distributed Database systems motivation is integrating operational data without centralization.
• Computer network tech connects distributed operational tasks.

File Systems & Database Management Visuals

• File systems involve separate programs and data descriptions for each file, pointing to individual files.
• Database Management involves applications interacting with a DBMS, which manages description, manipulation, and control of data in a centralized database.

Motivation

• Database Technology allows for integration of Computer Networks leading to distributed database systems.
• Integration does not equal centralization.

Distributed Computing

• This involves autonomous processing elements, potentially heterogeneous, that are interconnected by a computer network for assigned tasks.
• Processing logic or elements are distributed.
• Function: Delegating various functions of a computer system to various pieces of hardware or software
• Data: The data used by a number of applications may be distributed to a number of processing sites.
• Control: Control of the execution of various tasks might be distributed instead of being performed by one computer system.
• Distributed processing aligns with today's organizational structures.
• It suits web applications, e-commerce, multimedia, manufacturing control systems, and cloud computing.
• Aids in handling large-scale data through divide and conquer.

Distributed Database System (DDBS)

• A DDBS is multiple logically interrelated databases distributed over a computer network.
• D-DBMS manages the DDB and makes distribution transparent to users.
• Distributed database system (DDBS) = DDB + D-DBMS

What a DDBS is NOT

• Not a "collection of files" individually stored at each node of a computer network.
• It's more than just physical distribution, depends on whether databases reside in the same computer or not.
• Nor a timesharing computer system.
• Nor a loosely or tightly coupled multiprocessor system.
• Not a database system residing at one network node as a centralized database.

Centralized vs. Distributed Databases

• Centralized DBMS on a Network = database on a network node
• Distributed DBMS Environment = multiple databases across multiple networks

Implicit Assumptions

• Data at multiple sites assumes each site has a single processor.
• Processors are networked, not a multiprocessor system.
• Distributed database must be a database and not a collection of files
• D-DBMS is a full-fledged DBMS and not a remote file or TP system.

Data Delivery

• Data delivery concerns data moving from storage to query location.
• Three dimensions exist in data delivery alternatives (DDA): delivery modes, frequency, and communication methods.
• Combining these dimensions creates a rich design space.

Data Delivery Alternatives

• Delivery modes

Pull-only

• Data is transferred when initiated by a client pulling data from a server.
• The server responds by locating requested information.
• New data/updates are carried out at the source without notifying clients unless explicitly polled.

Push-only

• The transfer of data from servers to clients is initiated by a server push without a specific request from clients.
• It is hard to know what data is of common interest, and when to send them to clients.
• Alternatives are periodic, irregular, or conditional.
• Server push relies on accurately predicting client needs (Broadcast/Multicast).

Hybrid

• Hybrid mode combines client-pull and server-push.
• Information transfer from servers to clients is first initiated by a client pull, and the subsequent transfer of updated information to clients is initiated by a server push.

Frequency

• Periodic delivery sends data from the server to clients at regular intervals (defined by system/clients).
• Pull and push can be done periodically and in a scheduled way.
• Conditional is delivering data when certain conditions are met by certain conditions installed by clients in their profiles.
• They can be event-condition-action rules.
• Used in hybrid or push-only systems.
• Ad-hoc/irregular delivery is mostly pull-based.
• Data is pulled when clients request it.
• Periodic pull occurs when clients use polling on a regular schedule.

Communication Methods

• Unicast: Server sends to one client using a delivery mode with frequency.
• One-to-many: Server sends to many clients, potentially using multicast/broadcast protocols.
• Not all combinations make sense. And is good for first-order characterization of the complexity of emerging distributed data management systems.

Distributed DBMS Promises

• Transparent management of distributed, fragmented, and replicated data.
• Improved reliability/availability through distributed transactions.
• Improved performance.
• Easier and more economical system expansion.

Transparency

• Transparency in systems separates high-level semantics from lower-level implementation, hiding details from users.
• The advantage is support for developing complex apps

Data Independence

• Data independence in the distributed environment:
• Network (distribution) transparency.
• Replication transparency.
• Fragmentation transparency:
  • Horizontal fragmentation: selection.
  • Vertical fragmentation: projection.

Types of Transparency

• Data independence is a core transparency form, concerning an application's immunity to data changes.
• Data definition occurs at 2 levels: logical structure (schema definition) and its physical structure (physical data description).
• Has logical data independence and physical data independence. -Refers to user application immunity to schema changes -Deals with hiding storage from user apps
• Network transparency protects users from network details, potentially hiding its existence.
• Location transparency ensures task commands are independent of data location & system running the task.
• Naming transparency provides a unique name for each database object.
• Replication transparency concerns management of replicated data copies.

Fragmentation Transparency

• Desirably, database relations are divided into smaller fragments treated as separate objects for performance, availability, and reliability.
• Fragmentation reduces replication effects by using data subsets.
• Horizontal fragmentation partitions relations into subsets of tuples (rows).
• Vertical fragmentation creates sub-relations defined by attribute subsets (columns).
• If database objects are fragmented, it is necessary to handle user queries on entire relations via sub-relations.
• A query processing strategy needs to be based on fragments rather than relations.
• A global query must translate to fragment queries to maintain transparency.

Reliability

• Distributed DBMS improve reliability by replicating components and eliminating single point of failure.
• Replicated components/data enhance DDMS reliability.
• A transaction is the consistent unit of computing, and is a sequence of database operations executed as a single action.
• Distributed transactions provide:
  • Concurrency transparency: Transforms a good database state to another good database state. -Failure atomicity: Occurs during failures across multiple concurrent transactions.

Distributed Transaction Support

• Requires implementation of -Distributed concurrency control protocols: Protocols that control simultaneous transactions in distributed databases. -Commit protocols: Protocols that are capable of perform commits operations and recovery unfinished transactions.
• Data replication suits read-intensive workloads, however, problematic for updates.
• Mechanism to improve reliability in big size distributed databases (common in NoSQL databases).
• Replication protocols perform replication tasks using distributed computing

Potentially Improved Performance

• The proximity of data to its points of use require support for fragmentation and replication.
• A DBMS fragments the conceptual database allowing for data localization. And has 2 potential advantages:
  • Contention for CPU and I/O services is less severe than in centralized databases.
  • Localization reduces remote access delays in wide area networks.

Parallelism Requirements

• Parallelism requires execution: -Inter-query parallelism: Executes multiple queries at the same time. -Intra-query parallelism: Divides a query into subqueries active on networks to the database. -Each application at a site needs data. -Updates require mutual consistency and freshness of copies.

System Expansion

• Issue is database scaling.
• Emergence of microprocessor and workstation technologies, and demise of Grosh's law.
• The Client-server model of computing exists.
• Data communication cost vs telecommunication cost.

Distributed DBMS Issues:

• Distributed Database Design
  • How to distribute the database. Replicated & non-replicated database distribution.
  • A related problem in directory management.
• Query Processing involves converting user transactions and involves min{cost = data transmission + local processing}.
• General formulation is NP-hard.
• Concurrency Control involves synchronization of concurrent accesses, consistency and isolation of transactions' effects, and deadlock management.
• How to make the system resilient to failures and Atomicity and durability.

Related Issues

• Operating System Support that operating system with proper support for database operations.
• Open Systems and Interoperability in Distributed Multidatabase Systems including Parallel issues.

Architecture

• Defines the structure of the system.
• Components are identified.
• Functions are defined for each component.
• Defines interrelationships between components.

Dimensions of the problem

• Distribution is whether components are on the same machine or not.
• Heterogeneity across hardware, communications, or OS; DBMS most important with different data models, query language, or transaction management algorithms.
• Autonomy, Design Autonomy, Communication, and Execution.
  • Design autonomy: Ability of a component DBMS to decide on issues related to its own design.
  • Communication autonomy: Ability of a component DBMS to decide whether and how to communicate with other DBMSs.
  • Execution autonomy: Ability of a component DBMS to execute local operations in any manner it wants to.

Client/Server Architecture Advantages

• More efficient division of labor
• Horizontal and vertical scaling of resources
• Better price/performance on client machines
• The ability to use familiar tools on client machines
• Client access to remote data (via standards)
• Full DBMS functionality provided to client workstations
• Overall better system price/performance