数据库系统架构深度解析：DB2,Oracle,MySQL背后的设计原则

需积分: 10 93 浏览量更新于2024-07-23 收藏 910KB PDF 举报

本文档深入探讨了数据库管理系统（Database Management Systems, DBMS）在现代计算中的重要性和核心地位。作为早期多用户服务器系统的重要创新者，DBMS在可扩展性和可靠性方面奠定了基础，这些设计技术如今广泛应用于各种其他领域。尽管DBMS使用的算法和抽象概念在教科书中已有详尽阐述，但关于系统设计层面的讨论相对较少。文章标题《数据库实现架构》重点关注了DBMS的设计原则，涵盖了以下几个关键主题： 1. 进程模型：论文介绍了DBMS中处理并发请求的方式，包括事务管理、调度策略以及数据一致性模型。理解这些模型对于确保系统的高效运行和数据一致性至关重要。 2. 并行架构：随着现代计算机硬件的发展，DBMS需要支持并行处理能力。本文详细剖析了如何在多处理器或分布式环境中设计并行执行结构，以及如何通过分区、复制和负载均衡来优化性能。 3. 存储系统设计：数据库存储是基石，包括索引设计、数据压缩、存储层次结构（如B树、哈希表等）的选择以及与硬件交互的优化。这部分内容涉及了如何最大化磁盘I/O效率，同时保证数据的安全性和可用性。 4. 事务处理：DBMS如何确保数据的一致性是核心议题，作者讨论了ACID属性（原子性、一致性、隔离性、持久性）的实现机制，以及在分布式环境中的挑战。 5. 错误恢复和容错性：为了应对硬件故障和网络中断，DBMS需要有强大的错误检测与恢复机制，这包括日志管理、备份和恢复策略。 6. 安全性和隐私保护：在现代数据敏感的环境中，DBMS的设计必须考虑数据加密、访问控制和审计功能，以保护用户隐私和防止未经授权的访问。这篇论文不仅回顾了DBMS的传统设计理念，还着重于介绍其现代设计面临的挑战和最佳实践，为读者提供了一个全面且深入理解数据库系统架构的视角。通过阅读，专业人士能够更好地理解和设计高可用、高性能的数据库系统。

156 Process Models

Fig. 2.3 Process Pool: each DBMS Worker is allocated to one of a pool of OS processes

as work requests arrive from the Client and the process is returned to the pool once the

request is processed.

and all processes are already servicing other requests, the new request

must wait for a process to become available.

Process pool has all of the advantages of process per DBMS worker

but, since a much smaller number of processes are required, is consid-

erably more memory eﬃcient. Process pool is often implemented with

a dynamically resizable process pool where the pool grows potentially

to some maximum number when a large number of concurrent requests

arrive. When the request load is lighter, the process pool can be reduced

to fewer waiting processes. As with thread per DBMS worker, the pro-

cess pool model is also supported by a several current generation DBMS

in use today.

2.1.4 Shared Data and Process Boundaries

All models described above aim to execute concurrent client requests

as independently as possible. Yet, full DBMS worker independence and

isolation is not possible, since they are operating on the same shared

2.1 Uniprocessors and Lightweight Threads 157

database. In the thread per DBMS worker model, data sharing is easy

with all threads run in the same address space. In other models, shared

memory is used for shared data structures and state. In all three mod-

els, data must be moved from the DBMS to the clients. This implies

that all SQL requests need to be moved into the server processes and

that all results for return to the client need to be moved back out.

How is this done? The short answer is that various buﬀers are used.

The two major types are disk I/O buﬀers and client communication

buﬀers. We describe these buﬀers here, and brieﬂy discuss policies for

managing them.

Disk I/O buﬀers: The most common cross-worker data dependencies

are reads and writes to the shared data store. Consequently, I/O inter-

actions between DBMS workers are common. There are two sepa-

rate disk I/O scenarios to consider: (1) database requests and (2) log

requests.

•

Database I/O Requests: The Buﬀer Pool. All persistent

database data is staged through the DBMS buﬀer pool

(Section 5.3). With thread per DBMS worker, the buﬀer

pool is simply a heap-resident data structure available to

all threads in the shared DBMS address space. In the other

two models, the buﬀer pool is allocated in shared memory

available to all processes. The end result in all three DBMS

models is that the buﬀer pool is a large shared data struc-

ture available to all database threads and/or processes. When

a thread needs a page to be read in from the database, it

generates an I/O request specifying the disk address, and a

handle to a free memory location (frame) in the buﬀer pool

where the result can be placed. To ﬂush a buﬀer pool page

to disk, a thread generates an I/O request that includes the

page’s current frame in the buﬀer pool, and its destination

address on disk. Buﬀer pools are discussed in more detail in

Section 4.3.

•

Log I/O Requests: The Log Tail. The database log

(Section 6.4) is an array of entries stored on one or

more disks. As log entries are generated during transaction

160 Process Models

was to implement their own proprietary, lightweight thread package.

These lightweight threads, or DBMS threads, replace the role of the

OS threads described in the previous section. Each DBMS thread is

programmed to manage its own state, to perform all potentially block-

ing operations (e.g., I/Os) via non-blocking, asynchronous interfaces,

and to frequently yield control to a scheduling routine that dispatches

among these tasks.

Lightweight threads are an old idea that is discussed in a retro-

spective sense in [49], and are widely used in event-loop programming

for user interfaces. The concept has been revisited frequently in the

recent OS literature [31, 48, 93, 94]. This architecture provides fast

task-switching and ease of porting, at the expense of replicating a good

deal of OS logic in the DBMS (task-switching, thread state manage-

ment, scheduling, etc.) [86].

2.3 Standard Practice

In leading DBMSs today, we ﬁnd representatives of all three of the

architectures we introduced in Section 2.1 and some interesting varia-

tions thereof. In this dimension, IBM DB2 is perhaps the most interest-

ing example in that it supports four distinct process models. On OSs

with good thread support, DB2 defaults to thread per DBMS worker

and optionally supports DBMS workers multiplexed over a thread pool.

When running on OSs without scalable thread support, DB2 defaults

to process per DBMS worker and optionally supports DBMS worker

multiplexed over a process pool.

Summarizing the process models supported by IBM DB2, MySQL,

Oracle, PostgreSQL, and Microsoft SQL Server:

Process per DBMS worker:

This is the most straight-forward process model and is still heavily used

today. DB2 defaults to process per DBMS worker on OSs that do not

support high quality, scalable OS threads and thread per DBMS worker

on those that do. This is also the default Oracle process model. Oracle

also supports process pool as described below as an optional model.

PostgreSQL runs the process per DBMS worker model exclusively on

all supported operating systems.

剩余118页未读，继续阅读

qq_16932173

粉丝: 0
资源: 3

数据库系统架构深度解析：DB2,Oracle,MySQL背后的设计原则

大数据环境下基于MySQL的数据库架构设计与实现.pdf

分布式数据库架构及企业实践-基于Mycat中间件

分布式数据库架构及企业实践-基于Mycat中间件.pdf

详解几种常用（闭源、开源）关系型数据库的架构和实现原理解读

数据库架构设计：如何选择合适的数据库模型和架构.md

时敏目标预警系统分布式数据库架构的实现.pdf

移动云数据库RDS的架构和实现.pdf

饿了么数据库架构演进

LNH_MySQL 03-mysql主从复制介绍及分布式数据库架构实现介绍.mp4

"OceanBase数据库技术架构解析：商业应用与架构演进

最新资源