Chapter 17: Database System Architectures

 Centralized and Client-Server Systems

 Server System Architectures
 Parallel Systems
 Distributed Systems
 Network Types

Chapter 17: Database System Architectures

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use

Database System Concepts - 6th Edition 17.2 ©Silberschatz, Korth and Sudarshan

Centralized Systems A Centralized Computer System

 Run on a single computer system and do not interact with other
computer systems.
 General-purpose computer system: one to a few CPUs and a number
of device controllers that are connected through a common bus that
provides access to shared memory.
 Single-user system (e.g., personal computer or workstation): desk-top
unit, single user, usually has only one CPU and one or two hard
disks; the OS may support only one user.
 Multi-user system: more disks, more memory, multiple CPUs, and a
multi-user OS. Serve a large number of users who are connected to
the system vie terminals. Often called server systems.

Database System Concepts - 6th Edition 17.3 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.4 ©Silberschatz, Korth and Sudarshan
 Client-Server Systems Client-Server Systems (Cont.)
 Server systems satisfy requests generated at m client systems, whose  Database functionality can be divided into:
general structure is shown below:
 Back-end: manages access structures, query evaluation and
optimization, concurrency control and recovery.
 Front-end: consists of tools such as forms, report-writers, and
graphical user interface facilities.
 The interface between the front-end and the back-end is through SQL or
through an application program interface.

Database System Concepts - 6th Edition 17.5 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.6 ©Silberschatz, Korth and Sudarshan

Client-Server Systems (Cont.) Server System Architecture

 Advantages of replacing mainframes with networks of workstations or  Server systems can be broadly categorized into two kinds:
personal computers connected to back-end server machines:  transaction servers which are widely used in relational database
 better functionality for the cost systems, and
 flexibility in locating resources and expanding facilities  data servers, used in object-oriented database systems
 better user interfaces
 easier maintenance

Database System Concepts - 6th Edition 17.7 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.8 ©Silberschatz, Korth and Sudarshan
 Transaction Servers Transaction Server Process Structure
 Also called query server systems or SQL server systems  A typical transaction server consists of multiple processes accessing
 Clients send requests to the server data in shared memory.

 Transactions are executed at the server  Server processes

 These receive user queries (transactions), execute them and send
 Results are shipped back to the client.
results back
 Requests are specified in SQL, and communicated to the server
 Processes may be multithreaded, allowing a single process to
through a remote procedure call (RPC) mechanism.
execute several user queries concurrently
 Transactional RPC allows many RPC calls to form a transaction.
 Typically multiple multithreaded server processes
 Open Database Connectivity (ODBC) is a C language application
program interface standard from Microsoft for connecting to a server,  Lock manager process
sending SQL requests, and receiving results.  More on this later
 JDBC standard is similar to ODBC, for Java  Database writer process
 Output modified buffer blocks to disks continually

Database System Concepts - 6th Edition 17.9 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.10 ©Silberschatz, Korth and Sudarshan

Transaction Server Processes (Cont.) Transaction System Processes (Cont.)

 Log writer process

 Server processes simply add log records to log record buffer
 Log writer process outputs log records to stable storage.
 Checkpoint process
 Performs periodic checkpoints
 Process monitor process
 Monitors other processes, and takes recovery actions if any of
the other processes fail
 E.g., aborting any transactions being executed by a server
process and restarting it

Database System Concepts - 6th Edition 17.11 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.12 ©Silberschatz, Korth and Sudarshan
 Transaction System Processes (Cont.) Data Servers
 Shared memory contains shared data  Used in high-speed LANs, in cases where

Buffer pool  The clients are comparable in processing power to the server
 Lock table
 The tasks to be executed are compute intensive.
 Log buffer
 Data are shipped to clients where processing is performed, and then
 Cached query plans (reused if same query submitted again) shipped results back to the server.
 All database processes can access shared memory  This architecture requires full back-end functionality at the clients.
 To ensure that no two processes are accessing the same data structure
 Used in many object-oriented database systems
at the same time, databases systems implement mutual exclusion
using either  Issues:
 Operating system semaphores  Page-Shipping versus Item-Shipping
 Atomic instructions such as test-and-set  Locking
 To avoid overhead of interprocess communication for lock  Data Caching
request/grant, each database process operates directly on the lock
table  Lock Caching
 instead of sending requests to lock manager process
 Lock manager process still used for deadlock detection

Database System Concepts - 6th Edition 17.13 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.14 ©Silberschatz, Korth and Sudarshan

Data Servers (Cont.) Data Servers (Cont.)

 Page-shipping versus item-shipping  Data Caching
Smaller unit of shipping ⇒ more messages
  Data can be cached at client even in between transactions
 Worth prefetching related items along with requested item
 But check that data is up-to-date before it is used (cache
 Page shipping can be thought of as a form of prefetching coherency)
 Locking  Check can be done when requesting lock on data item
 Overhead of requesting and getting locks from server is high due  Lock Caching
to message delays
 Locks can be retained by client system even in between
 Can grant locks on requested and prefetched items; with page
shipping, transaction is granted lock on whole page. transactions
 Locks on a prefetched item can be P{called back} by the server,  Transactions can acquire cached locks locally, without
and returned by client transaction if the prefetched item has not contacting server
been used.  Server calls back locks from clients when it receives conflicting
 Locks on the page can be deescalated to locks on items in the lock request. Client returns lock once no local transaction is
page when there are lock conflicts. Locks on unused items can using it.
then be returned to server.
 Similar to deescalation, but across transactions.

Database System Concepts - 6th Edition 17.15 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.16 ©Silberschatz, Korth and Sudarshan
 Parallel Systems Speed-Up and Scale-Up
 Parallel database systems consist of multiple processors and multiple  Speedup: a fixed-sized problem executing on a small system is given
disks connected by a fast interconnection network. to a system which is N-times larger.
 A coarse-grain parallel machine consists of a small number of  Measured by:
powerful processors speedup = small system elapsed time
 A massively parallel or fine grain parallel machine utilizes large system elapsed time
thousands of smaller processors.
 Speedup is linear if equation equals N.
 Two main performance measures:
 Scaleup: increase the size of both the problem and the system
 throughput --- the number of tasks that can be completed in a
 N-times larger system used to perform N-times larger job
given time interval
 Measured by:
 response time --- the amount of time it takes to complete a single
task from the time it is submitted scaleup = small system small problem elapsed time
big system big problem elapsed time
 Scale up is linear if equation equals 1.

Database System Concepts - 6th Edition 17.17 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.18 ©Silberschatz, Korth and Sudarshan

Speedup Scaleup

Database System Concepts - 6th Edition 17.19 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.20 ©Silberschatz, Korth and Sudarshan
 Batch and Transaction Scaleup Factors Limiting Speedup and Scaleup
 Batch scaleup: Speedup and scaleup are often sublinear due to:
 A single large job; typical of most decision support queries and  Startup costs: Cost of starting up multiple processes may dominate
scientific simulation. computation time, if the degree of parallelism is high.
 Use an N-times larger computer on N-times larger problem.  Interference: Processes accessing shared resources (e.g., system
 Transaction scaleup: bus, disks, or locks) compete with each other, thus spending time
waiting on other processes, rather than performing useful work.
 Numerous small queries submitted by independent users to a
shared database; typical transaction processing and timesharing  Skew: Increasing the degree of parallelism increases the variance in
systems. service times of parallely executing tasks. Overall execution time
determined by slowest of parallely executing tasks.
 N-times as many users submitting requests (hence, N-times as
many requests) to an N-times larger database, on an N-times
larger computer.
 Well-suited to parallel execution.

Database System Concepts - 6th Edition 17.21 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.22 ©Silberschatz, Korth and Sudarshan

Interconnection Network Architectures Interconnection Architectures

 Bus. System components send data on and receive data from a
single communication bus;

Does not scale well with increasing parallelism.
 Mesh. Components are arranged as nodes in a grid, and each
component is connected to all adjacent components
 Communication links grow with growing number of components,
and so scales better.
 But may require 2√n hops to send message to a node (or √n with
wraparound connections at edge of grid).
 Hypercube. Components are numbered in binary; components are
connected to one another if their binary representations differ in
exactly one bit.
 n components are connected to log(n) other components and can
reach each other via at most log(n) links; reduces communication
delays.

Database System Concepts - 6th Edition 17.23 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.24 ©Silberschatz, Korth and Sudarshan
 Parallel Database Architectures Parallel Database Architectures
 Shared memory -- processors share a common memory
 Shared disk -- processors share a common disk
 Shared nothing -- processors share neither a common memory nor
common disk
 Hierarchical -- hybrid of the above architectures

Database System Concepts - 6th Edition 17.25 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.26 ©Silberschatz, Korth and Sudarshan

Shared Memory Shared Disk

 Processors and disks have access to a common memory, typically via  All processors can directly access all disks via an interconnection
a bus or through an interconnection network. network, but the processors have private memories.
 Extremely efficient communication between processors — data in  The memory bus is not a bottleneck
shared memory can be accessed by any processor without having to  Architecture provides a degree of fault-tolerance — if a
move it using software. processor fails, the other processors can take over its tasks
 Downside – architecture is not scalable beyond 32 or 64 processors since the database is resident on disks that are accessible from
since the bus or the interconnection network becomes a bottleneck all processors.
 Widely used for lower degrees of parallelism (4 to 8).  Examples: IBM Sysplex and DEC clusters (now part of Compaq)
running Rdb (now Oracle Rdb) were early commercial users
 Downside: bottleneck now occurs at interconnection to the disk
subsystem.
 Shared-disk systems can scale to a somewhat larger number of
processors, but communication between processors is slower.

Database System Concepts - 6th Edition 17.27 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.28 ©Silberschatz, Korth and Sudarshan
 Shared Nothing Hierarchical
 Node consists of a processor, memory, and one or more disks.  Combines characteristics of shared-memory, shared-disk, and shared-
Processors at one node communicate with another processor at nothing architectures.
another node using an interconnection network. A node functions as  Top level is a shared-nothing architecture – nodes connected by an
the server for the data on the disk or disks the node owns. interconnection network, and do not share disks or memory with each
 Examples: Teradata, Tandem, Oracle-n CUBE other.
 Data accessed from local disks (and local memory accesses) do not  Each node of the system could be a shared-memory system with a
pass through interconnection network, thereby minimizing the few processors.
interference of resource sharing.  Alternatively, each node could be a shared-disk system, and each of
 Shared-nothing multiprocessors can be scaled up to thousands of the systems sharing a set of disks could be a shared-memory system.
processors without interference.  Reduce the complexity of programming such systems by distributed
 Main drawback: cost of communication and non-local disk access; virtual-memory architectures
sending data involves software interaction at both ends.  Also called non-uniform memory architecture (NUMA)

Database System Concepts - 6th Edition 17.29 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.30 ©Silberschatz, Korth and Sudarshan

Distributed Systems Distributed Databases

 Data spread over multiple machines (also referred to as sites or
nodes).  Homogeneous distributed databases

Same software/schema on all sites, data may be partitioned
 Network interconnects the machines
among sites
 Data shared by users on multiple machines
 Goal: provide a view of a single database, hiding details of
distribution
 Heterogeneous distributed databases
 Different software/schema on different sites
 Goal: integrate existing databases to provide useful functionality
 Differentiate between local and global transactions
 A local transaction accesses data in the single site at which the
transaction was initiated.
 A global transaction either accesses data in a site different from
the one at which the transaction was initiated or accesses data in
several different sites.

Database System Concepts - 6th Edition 17.31 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.32 ©Silberschatz, Korth and Sudarshan
 Implementation Issues for Distributed
Trade-offs in Distributed Systems
Databases
 Sharing data – users at one site able to access the data residing at  Atomicity needed even for transactions that update data at multiple
some other sites. sites
 Autonomy – each site is able to retain a degree of control over data  The two-phase commit protocol (2PC) is used to ensure atomicity
stored locally.  Basic idea: each site executes transaction until just before
 Higher system availability through redundancy — data can be commit, and the leaves final decision to a coordinator
replicated at remote sites, and system can function even if a site fails.  Each site must follow decision of coordinator, even if there is a
 Disadvantage: added complexity required to ensure proper failure while waiting for coordinators decision
coordination among sites.  2PC is not always appropriate: other transaction models based on
 Software development cost. persistent messaging, and workflows, are also used
 Greater potential for bugs.  Distributed concurrency control (and deadlock detection) required
 Increased processing overhead.  Data items may be replicated to improve data availability
 Details of above in Chapter 22

Database System Concepts - 6th Edition 17.33 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.34 ©Silberschatz, Korth and Sudarshan

Network Types Local-area Network

 Local-area networks (LANs) – composed of processors that are
distributed over small geographical areas, such as a single building or
a few adjacent buildings.
 Wide-area networks (WANs) – composed of processors distributed
over a large geographical area.

Database System Concepts - 6th Edition 17.35 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.36 ©Silberschatz, Korth and Sudarshan
 Networks Types (Cont.)
 WANs with continuous connection (e.g., the Internet) are needed for
implementing distributed database systems
 Groupware applications such as Lotus notes can work on WANs with
discontinuous connection:
 Data is replicated.
 Updates are propagated to replicas periodically.
 Copies of data may be updated independently. End of Chapter 17
 Non-serializable executions can thus result. Resolution is
application dependent.

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use

Database System Concepts - 6th Edition 17.37 ©Silberschatz, Korth and Sudarshan

Figure 17.01 Figure 17.02

Database System Concepts - 6th Edition 17.39 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.40 ©Silberschatz, Korth and Sudarshan
 Figure 17.03 Figure 17.04

Database System Concepts - 6th Edition 17.41 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.42 ©Silberschatz, Korth and Sudarshan

Figure 17.05 Figure 17.06

Database System Concepts - 6th Edition 17.43 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.44 ©Silberschatz, Korth and Sudarshan
 Figure 17.07 Figure 17.08

Database System Concepts - 6th Edition 17.45 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.46 ©Silberschatz, Korth and Sudarshan

Figure 17.09 Figure 17.10

Database System Concepts - 6th Edition 17.47 ©Silberschatz, Korth and Sudarshan Database System Concepts - 6th Edition 17.48 ©Silberschatz, Korth and Sudarshan
 Figure 17.11

Database System Concepts - 6th Edition 17.49 ©Silberschatz, Korth and Sudarshan