MySQL 體系架構 

一.邏輯模塊組成

總的來說，MySQL 可以看成是二層架構，***層我們通常叫做SQL Layer，在MySQL 數(shù)據(jù)庫系統(tǒng)處理底層數(shù)據(jù)之前的所有工作都是在這一層完成的，包括權限判斷，sql 解析，執(zhí)行計劃優(yōu)化，querycache 的處理等等；    第二層就是存儲引擎層，我們通常叫做Storage Engine Layer，也就是底層數(shù)據(jù)存取操作實現(xiàn)部分，由多種存儲引擎共同組成。所以，可以用如下一張最簡單的架構示意圖來表示MySQL 的基本架構，如圖2-1 所示：

雖然從上圖看起來MySQL 架構非常的簡單，就是簡單的兩部分而已，但實際上每一層中都含有各自的很多小模塊，尤其是***層SQL Layer，結構相當復雜的。下面我們就分別針對SQL Layer 和Storage Engine Layer 做一個簡單的分析。 

SQL Layer 中包含了多個子模塊，下面我將逐個做一下簡單的介紹：

1、初始化模塊

顧名思議，初始化模塊就是在MySQL Server 啟動的時候，對整個系統(tǒng)做各種各樣的初始化操作，比如各種buffer，cache 結構的初始化和內存空間的申請，各種系統(tǒng)變量的初始化設定，各種存儲引擎的初始化設置，等等。 

2、核心API

核心API 模塊主要是為了提供一些需要非常高效的底層操作功能的優(yōu)化實現(xiàn)，包括各種底層數(shù)據(jù)結構的實現(xiàn)，特殊算法的實現(xiàn)，字符串處理，數(shù)字處理等，小文件I/O，格式化輸出，以及最重要的內存管理部分。核心API 模塊的所有源代碼都集中在mysys和strings文件夾下面，有興趣的讀者可以研究研究。 

3、網(wǎng)絡交互模塊

底層網(wǎng)絡交互模塊抽象出底層網(wǎng)絡交互所使用的接口api，實現(xiàn)底層網(wǎng)絡數(shù)據(jù)的接收與發(fā)送，以方便其他各個模塊調用，以及對這一部分的維護。所有源碼都在vio 文件夾下面。 

4、Client& Server 交互協(xié)議模塊

任何C/S 結構的軟件系統(tǒng)，都肯定會有自己獨有的信息交互協(xié)議，MySQL 也不例外。MySQL的Client & Server 交互協(xié)議模塊部分，實現(xiàn)了客戶端與MySQL 交互過程中的所有協(xié)議。當然這些協(xié)議都是建立在現(xiàn)有的OS 和網(wǎng)絡協(xié)議之上的，如TCP/IP 以及Unix Socket。 

5、用戶模塊

用戶模塊所實現(xiàn)的功能，主要包括用戶的登錄連接權限控制和用戶的授權管理。他就像MySQL 的大門守衛(wèi)一樣，決定是否給來訪者“開門”。 

6、訪問控制模塊

造訪客人進門了就可以想干嘛就干嘛么？為了安全考慮，肯定不能如此隨意。這時候就需要訪問控制模塊實時監(jiān)控客人的每一個動作，給不同的客人以不同的權限。訪問控制模塊實現(xiàn)的功能就是根據(jù)用戶模塊中各用戶的授權信息，以及數(shù)據(jù)庫自身特有的各種約束，來控制用戶對數(shù)據(jù)的訪問。用戶模塊和訪問控制模塊兩者結合起來，組成了MySQL 整個數(shù)據(jù)庫系統(tǒng)的權限安全管理的功能。 

7、連接管理、連接線程和線程管理

連接管理模塊負責監(jiān)聽對MySQL Server 的各種請求，接收連接請求，轉發(fā)所有連接請求到線程管理模塊。每一個連接上MySQL Server 的客戶端請求都會被分配（或創(chuàng)建）一個連接線程為其單獨服務。而連接線程的主要工作就是負責MySQL Server 與客戶端的通信，接受客戶端的命令請求，傳遞Server 端的結果信息等。線程管理模塊則負責管理維護這些連接線程。包括線程的創(chuàng)建，線程的cache 等。 

8、Query 解析和轉發(fā)模塊

在MySQL 中我們習慣將所有Client端發(fā)送給Server 端的命令都稱為query，在MySQL Server 里面，連接線程接收到客戶端的一個Query 后，會直接將該query 傳遞給專門負責將各種Query 進行分類然后轉發(fā)給各個對應的處理模塊，這個模塊就是query 解析和轉發(fā)模塊。其主要工作就是將query 語句進行語義和語法的分析，然后按照不同的操作類型進行分類，然后做出針對性的轉發(fā)。 

9、QueryCache 模塊

Query Cache 模塊在MySQL 中是一個非常重要的模塊，他的主要功能是將客戶端提交給MySQL 的Select 類query 請求的返回結果集cache 到內存中，與該query 的一個hash 值做一個對應。該Query 所取數(shù)據(jù)的基表發(fā)生任何數(shù)據(jù)的變化之后，MySQL 會自動使該query 的Cache 失效。在讀寫比例非常高的應用系統(tǒng)中，Query Cache 對性能的提高是非常顯著的。當然它對內存的消耗也是非常大的。 

10、Query 優(yōu)化器模塊

Query 優(yōu)化器，顧名思義，就是優(yōu)化客戶端請求的query，根據(jù)客戶端請求的query 語句，和數(shù)據(jù)庫中的一些統(tǒng)計信息，在一系列算法的基礎上進行分析，得出一個***的策略，告訴后面的程序如何取得這個query 語句的結果。 

11、表變更管理模塊

表變更管理模塊主要是負責完成一些DML 和DDL 的query，如：update，delte，insert，create table，alter table 等語句的處理。 

12、表維護模塊

表的狀態(tài)檢查，錯誤修復，以及優(yōu)化和分析等工作都是表維護模塊需要做的事情。 

13、系統(tǒng)狀態(tài)管理模塊

系統(tǒng)狀態(tài)管理模塊負責在客戶端請求系統(tǒng)狀態(tài)的時候，將各種狀態(tài)數(shù)據(jù)返回給用戶，像DBA 常用的各種showstatus 命令，showvariables 命令等，所得到的結果都是由這個模塊返回的。 

14、表管理器

這個模塊從名字上看來很容易和上面的表變更和表維護模塊相混淆，但是其功能與變更及維護模塊卻完全不同。大家知道，每一個MySQL 的表都有一個表的定義文件，也就是*.frm文件。表管理器的工作主要就是維護這些文件，以及一個cache，該cache 中的主要內容是各個表的結構信息。此外它還維護table 級別的鎖管理。 

15、日志記錄模塊

日志記錄模塊主要負責整個系統(tǒng)級別的邏輯層的日志的記錄，包括error log，binary log，slow query log 等。 

16、復制模塊

復制模塊又可分為Master 模塊和Slave 模塊兩部分， Master 模塊主要負責在Replication 環(huán)境中讀取Master 端的binary 日志，以及與Slave 端的I/O 線程交互等工作。

Slave 模塊比Master 模塊所要做的事情稍多一些，在系統(tǒng)中主要體現(xiàn)在兩個線程上面。一個是負責從Master請求和接受binary 日志，并寫入本地relay log 中的I/O 線程。另外一個是負責從relay log 中讀取相關日志事件，然后解析成可以在Slave 端正確執(zhí)行并得到和Master端完全相同的結果的命令并再交給Slave 執(zhí)行的SQL 線程。 

17、存儲引擎接口模塊

存儲引擎接口模塊可以說是MySQL 數(shù)據(jù)庫中最有特色的一點了。目前各種數(shù)據(jù)庫產品中，基本上只有MySQL 可以實現(xiàn)其底層數(shù)據(jù)存儲引擎的插件式管理。這個模塊實際上只是一個抽象類，但正是因為它成功地將各種數(shù)據(jù)處理高度抽象化，才成就了今天MySQL 可插拔存儲引擎的特色。  

二.各模塊工作配合

在了解了MySQL 的各個模塊之后，我們再看看MySQL各個模塊間是如何相互協(xié)同工作的。

接下來，我們通過啟動MySQL，客戶端連接，請求query，得到返回結果，***退出，這樣一整個過程來進行分析。

當我們執(zhí)行啟動MySQL 命令之后，MySQL 的初始化模塊就從系統(tǒng)配置文件中讀取系統(tǒng)參數(shù)和命令行參數(shù)，并按照參數(shù)來初始化整個系統(tǒng)，如申請并分配buffer，初始化全局變量，以及各種結構等。同時各個存儲引擎也被啟動，并進行各自的初始化工作。當整個系統(tǒng)初始化結束后，由連接管理模塊接手。連接管理模塊會啟動處理客戶端連接請求的監(jiān)聽程序，包括tcp/ip 的網(wǎng)絡監(jiān)聽，還有unix 的socket。這時候，MySQL Server 就基本啟動完成，準備好接受客戶端請求了。

當連接管理模塊監(jiān)聽到客戶端的連接請求（借助網(wǎng)絡交互模塊的相關功能），雙方通過Client & Server 交互協(xié)議模塊所定義的協(xié)議“寒暄”幾句之后，連接管理模塊就會將連接請求轉發(fā)給線程管理模塊，去請求一個連接線程。

線程管理模塊馬上又會將控制交給連接線程模塊，告訴連接線程模塊：現(xiàn)在我這邊有連接請求過來了，需要建立連接，你趕快處理一下。連接線程模塊在接到連接請求后，首先會檢查當前連接線程池中是否有被cache 的空閑連接線程，如果有，就取出一個和客戶端請求連接上，如果沒有空閑的連接線程，則建立一個新的連接線程與客戶端請求連接。當然，連接線程模塊并不是在收到連接請求后馬上就會取出一個連接線程連和客戶端連接，而是首先通過調用用戶模塊進行授權檢查，只有客戶端請求通過了授權檢查后，他才會將客戶端請求和負責請求的連接線程連上。

在MySQL 中，將客戶端請求分為了兩種類型：一種是query，需要調用Parser 也就是Query 解析和轉發(fā)模塊的解析才能夠執(zhí)行的請求；一種是command，不需要調用Parser 就可以直接執(zhí)行的請求。如果我們的初始化配置中打開了Full QueryLogging 的功能，那么Query 解析與轉發(fā)模塊會調用日志記錄模塊將請求計入日志，不管是一個Query 類型的請求還是一個command 類型的請求，都會被記錄進入日志，所以出于性能考慮，一般很少打開Full QueryLogging 的功能。

當客戶端請求和連接線程“互換暗號（互通協(xié)議）”接上頭之后，連接線程就開始處理客戶端請求發(fā)送過來的各種命令（或者query），接受相關請求。它將收到的query語句轉給Query 解析和轉發(fā)模塊，Query 解析器先對Query 進行基本的語義和語法解析，然后根據(jù)命令類型的不同，有些會直接處理，有些會分發(fā)給其他模塊來處理。

如果是一個Query 類型的請求，會將控制權交給Query解析器。Query 解析器首先分析看是不是一個select 類型的query，如果是，則調用查詢緩存模塊，讓它檢查該query 在query cache 中是否已經(jīng)存在。如果有，則直接將cache 中的數(shù)據(jù)返回給連接線程模塊，然后通過與客戶端的連接的線程將數(shù)據(jù)傳輸給客戶端。如果不是一個可以被cache 的query類型，或者cache 中沒有該query 的數(shù)據(jù)，那么query 將被繼續(xù)傳回query 解析器，讓query解析器進行相應處理，再通過query 分發(fā)器分發(fā)給相關處理模塊。

如果解析器解析結果是一條未被cache 的select 語句，則將控制權交給Optimizer，也就是Query 優(yōu)化器模塊，如果是DML 或者是DDL 語句，則會交給表變更管理模塊，如果是一些更新統(tǒng)計信息、檢測、修復和整理類的query 則會交給表維護模塊去處理，復制相關的query 則轉交給復制模塊去進行相應的處理，請求狀態(tài)的query 則轉交給了狀態(tài)收集報告模塊。實際上表變更管理模塊根據(jù)所對應的處理請求的不同，是分別由insert 處理器、delete 處理器、update 處理器、create 處理器，以及alter 處理器這些小模塊來負責不同的DML和DDL 的。 

在各個模塊收到Query 解析與分發(fā)模塊分發(fā)過來的請求后，首先會通過訪問控制模塊檢查連接用戶是否有訪問目標表以及目標字段的權限，如果有，就會調用表管理模塊請求相應的表，并獲取對應的鎖。表管理模塊首先會查看該表是否已經(jīng)存在于table cache 中，如果已經(jīng)打開則直接進行鎖相關的處理，如果沒有在cache 中，則需要再打開表文件獲取鎖，然后將打開的表交給表變更管理模塊。 

當表變更管理模塊“獲取”打開的表之后，就會根據(jù)該表的相關meta 信息，判斷表的存儲引擎類型和其他相關信息。根據(jù)表的存儲引擎類型，提交請求給存儲引擎接口模塊，調用對應的存儲引擎實現(xiàn)模塊，進行相應處理。

不過，對于表變更管理模塊來說，可見的僅是存儲引擎接口模塊所提供的一系列“標準”接口，底層存儲引擎實現(xiàn)模塊的具體實現(xiàn)，對于表變更管理模塊來說是透明的。他只需要調用對應的接口，并指明表類型，接口模塊會根據(jù)表類型調用正確的存儲引擎來進行相應的處理。

當一條query 或者一個command 處理完成（成功或者失敗）之后，控制權都會交還給連接線程模塊。如果處理成功，則將處理結果（可能是一個Result set，也可能是成功或者失敗的標識）通過連接線程反饋給客戶端。如果處理過程中發(fā)生錯誤，也會將相應的錯誤信息發(fā)送給客戶端，然后連接線程模塊會進行相應的清理工作，并繼續(xù)等待后面的請求，重復上面提到的過程，或者完成客戶端斷開連接的請求。

如果在上面的過程中，相關模塊使數(shù)據(jù)庫中的數(shù)據(jù)發(fā)生了變化，而且MySQL 打開了binlog 功能，則對應的處理模塊還會調用日志處理模塊將相應的變更語句以更新事件的形式記錄到相關參數(shù)指定的二進制日志文件中。

在上面各個模塊的處理過程中，各自的核心運算處理功能部分都會高度依賴整個MySQL的核心API 模塊，比如內存管理，文件I/O，數(shù)字和字符串處理等等。 

了解到整個處理過程之后，我們可以將以上各個模塊畫成如圖2-2 的關系圖：

 

下面這個是官方文檔里的一個圖：

Oracle體系結構介紹   --基礎篇

在學習oracle中，體系結構是重中之重，掌握的越深入越好。在實際工作遇到疑難問題，其實都可以歸結到體系結構中來解釋，所以我們根據(jù)下面的示圖了解一下oracle體系結構。

1. Summarize

根據(jù)示圖，便于我們記憶，示圖分三部分組成，左側User Process、Server Process、PGA可以看做成Clinet端，上面的實例（Instance）和下面的數(shù)據(jù)庫（Database）及參數(shù)文件（parameter file）、密碼文件（password file）和歸檔日志文件（archived logfiles）組成Oracle Server，所以整個示圖可以理解成一個C/S架構。

Oracle Server 由兩個實體組成：實例（instance）與數(shù)據(jù)庫（database）。這兩個實體是獨立的，不過連接在一起。在數(shù)據(jù)庫創(chuàng)建過程中，實例首先被創(chuàng)建，然后才創(chuàng)建數(shù)據(jù)庫。在典型的單實例環(huán)境中，實例與數(shù)據(jù)庫的關系是一對一的，一個實例連接一個數(shù)據(jù)庫，實例與數(shù)據(jù)庫也可以是多對一的關系，即不同計算機上的多個實例打開共享磁盤系統(tǒng)上的一個公用數(shù)據(jù)庫。這種多對一關系被稱為實際應用群集（Real Application Clusters，RAC）RAC極大提高了數(shù)據(jù)庫的性能、容錯與可伸縮性（可能耗費更多的存儲空間）并且是oracle網(wǎng)格（grid）概念的必備部分。

2. Client端

在Client端的作用是如何從客戶端創(chuàng)建服務器進程與數(shù)據(jù)庫進行交互的過程。

2.1 User process

用戶運行一個應用程序時與Oracle數(shù)據(jù)庫進程交互（例如：sql/plus）時，oracle創(chuàng)建一個用戶進程來運行用戶的應用程序。

2.2 Server process

Server Process是用來處理連接到實例的用戶進程（User Process）提交的請求。當應用程序與Oracle服務器運行在同一臺機器上時，某些用戶進程（User Process）可以與Server Process合并為同一個進程，即便減小系統(tǒng)開銷。從邏輯層面來講，用戶進程必須要通過一個Server Process來同Oracle進行通信的.（只不過有些時候在同一臺機器的時候，某些User Process和Server Process會合并罷了）

2.3 PGA

PGA（Program Global Area）程序全局區(qū)，是用戶進程連接到數(shù)據(jù)庫并創(chuàng)建一個會話時，由Oracle服務器進程分配的專門用于當前用戶會話的內存區(qū)，該區(qū)域是私有的。

為每個用戶連接Oracle數(shù)據(jù)庫保留的內存

當進程創(chuàng)建時分配

進程結束后被釋放

只能被一個進程使用

參數(shù)：PGA_AGGREGATE_TARGET指定PGA的總共大小

3. Database

 "3+3"結構，3個必要文件+3個可選文件。

3.1 Data files

內容：

1）用戶數(shù)據(jù)：用戶表、DML語句可調整；

2）數(shù)據(jù)字典數(shù)據(jù)：數(shù)據(jù)字典表記錄DB結構、只讀不可修改、DDL語句調整

3）真實看到的文件

作用：

讀取數(shù)據(jù)

特點：

1）至少包含一個SYSTEM表空間、DDL語言

2）各種不同表空間 數(shù)據(jù)字典信息

3）我的數(shù)據(jù)保存在表空間上，表空間是以多個數(shù)據(jù)文件的形式體現(xiàn)的。

3.2 Control files

內容：

1）DB基本信息：DBID

2）DB結構信息

3）***一次同步的SCN信息

3.1）同步：內存區(qū)域database buffer cache的臟數(shù)據(jù)寫出磁盤

3.2）SCN:（system change number），時間軸、生命線

4）當前日志序列號

5）RMAN備份信息

作用：

1）記錄數(shù)據(jù)庫基本信息

2）記錄內存下一些信息

特點：

1）大小一般不變（固定部分、可變部分）

2）個數(shù)，一個即可，分類存放

3.3 Redo log files

內容：

按時間順序記錄著DB中的改變（redo entry條目），數(shù)據(jù)塊改變就會生成redo

作用：

提供數(shù)據(jù)的可恢復性

特點：

1）大小不變

2）順序寫

3）容量有限，循環(huán)覆寫

4）至少兩組日志，日志成員冗余

5）提供恢復的手段

3.4 Parameter file

內容：

1）記錄那些定制的DB參數(shù)

2）參數(shù)默認值

3）pfile：需要重啟實例和spfile

作用：

定義數(shù)據(jù)庫實例的屬性

特點：

兩種類型參數(shù)的特點

3.5 Password file

內容：

特權身份用戶的口令

作用:

用于特權身份用戶登錄的驗證

特點：

1）操作系統(tǒng)、密碼認證方式登錄數(shù)據(jù)庫

2）特高、特權身份登錄到數(shù)據(jù)庫實例啟動數(shù)據(jù)庫，跳過了數(shù)據(jù)字典的驗證

3）O7：Oracle 7版本，啟用普通身份登錄

3.6 Archived logfiles

內容：

重做日志（redo log）歷史

作用：

1）長期保存日志以便恢復

2）保證redo log 不丟失

特點：

1）個數(shù)=當前日志數(shù)-1

2）大小<=在線日志文件大小

3）命名需要具有唯一性：序列號、RAC節(jié)點號

4）離線文件可通過操作系統(tǒng)命令管理

4. Instance

實例由存儲結構和進程組成，并且只短暫存在于RAM和CPU中。

4.1 SGA

內存結構包括兩個部分

1）系統(tǒng)全局（SGA）：在實例啟動時候分配，是Oracle實例的基礎組件。

2）程序全局（PGA)：當服務器進程生成分配。

4.1.1 Shared Pool

用于存儲：

1）最近執(zhí)行的SQL語句

2）最近使用的數(shù)據(jù)定義

由兩個與性能相關的部分組成：

1）庫緩存

2）數(shù)據(jù)字典緩存

由參數(shù)SHARED_POOL_SIZE決定大小

4.1.1.1 Library Cache

1.1）存儲最近使用的SQL和PL/SQL語句的信息（軟解析，緩存一次多次使用） 

1.2）共享常用的語句

1.3）管理上遵循LRU規(guī)則

1.4）包括兩個部分

1.4.1）共享SQL區(qū)

1.4.2）共享PL/SQL區(qū)

1.5）大小由Shared Pool的大小決定

4.1.1.2 Data Dictionary Cache

2.1）存儲在數(shù)據(jù)庫中最近使用的定義

2.2）包括數(shù)據(jù)文件、表、索引、列、用戶、權限和其他的數(shù)據(jù)庫對象

2.3）在分析階段，服務器進程查找數(shù)據(jù)字典去驗證對象的名字以及是否是合法訪問

2.4）對于查詢和DML語句，如果數(shù)據(jù)字典的信息在緩存中能夠提高響應時間

2.5）大小由Shared Pool 的大小決定

4.1.2 Database Buffer Cache

1）存儲從數(shù)據(jù)文件中獲得的數(shù)據(jù)塊的鏡像

2）當獲取和更新數(shù)據(jù)的時候能夠大幅度的提高性能

3）管理上遵循LRU規(guī)則

4）參數(shù)DB_BLOCK_SIZE其塊的大小

5）包括以下獨立的子緩存：

DB_CACHE_SIZE

DB_KEEP_CACHE_SIZE

DB_RECYCLE_CACHE_SIZE

6）能夠動態(tài)的調整大小

4.1.3 Redo Log Buffer

1）記錄所有數(shù)據(jù)庫的塊改變

2）主要的目的是用于恢復

3）大小由參數(shù)LOG_BUFFER（不可動態(tài)調整）決定

4.1.4 Large Pool

1）是系統(tǒng)全局區(qū)中可選的一個部分

2）用于：

2.1）RMAN備份恢復操作

2.2）I/0并行進程

2.3）共享服務器的會話內存（UGA），以減輕在共享池中的負擔

3）大小由參數(shù)LARGE_POOL_SIZE決定

4）能夠被動態(tài)的改變大小

4.1.5 Java Pool

1）Java命令的分析

2）如果要安裝和使用Java

3）大小由參數(shù)JAVA_POOL_SIZE決定，如果granule是4M，默認是24M,granule是16M，默認大小是32M

4.1.6 Streams Pool

流相關的數(shù)據(jù)在流池中，提高緩存效果。目前oracle較為弱化，提高采用Oracle Golden Gate（OGG），高級復制功能。

4.2 Process structure

Oracle有以下幾種進程：

1）用戶進程：在用戶連接數(shù)據(jù)時產生

2）服務器進程：當連接到Oracle實例并且用戶建立會話的時候產生

3）后臺進程：Oracle實例啟動的時候產生

4）維持物理和內存之間的聯(lián)系

4.1）必須要有的后臺進程：DBWn、PMON、CKPT、LGWR、SMON

4.2）可選的后臺進程：ARCn、CJQn、Jnnn、RECO、MMAN、MMON、Snnn、Dnnn、Pnnn

4.2.1 PMON

PMON（進程監(jiān)測進程）：

1）清除失敗的進程

1.1）回滾事務

1.2）釋放鎖

1.3）釋放其他資源

1.4）重啟死掉的dispatchers

1.5）動態(tài)注冊監(jiān)聽器

4.2.2 SMON

SMON（系統(tǒng)檢測進程）作用:

1）實例恢復：

1.1）前滾所有重做日志中的改變

1.2）打開數(shù)據(jù)庫為了用戶能訪問

1.3）回滾沒有提交的事務

2）釋放臨時表空間（deallocated）

4.2.3 DBWR

DBWn（數(shù)據(jù)庫寫進程）寫的條件：

1）發(fā)生檢查點

2）臟緩存到達限制（1/4滿）

3）沒有自由的緩存

4）超時發(fā)生

5）RACping請求（8i）

6）表空間離線

7）表空間只讀

8）熱備份表空間開始動作

9）表被刪除或者截斷

4.2.4 LGWR

LGWR（日志寫進程）的條件：

1）commit的時候

2）達到三分之一滿

3）日志的大小到1M

4）每隔三秒

5）在DBWn進程寫之前

4.2.5 CKPT

CKPT（檢查點進程）作用：

1）給DBWn信號

2）更新數(shù)據(jù)文件頭

3）更新控制文件

4.2.6 ARCn

ARCn（歸檔進程）：

1）可選的后臺進程

2）當啟用歸檔方式后自動歸檔重做日志文件

PostgreSQL 體系架構

PostgreSQL是自由的對象-關系數(shù)據(jù)庫服務器，在靈活的BSD-風格許可證下發(fā)行的。PostgreSQL數(shù)據(jù)庫是一種幾乎可以運行在各種平臺上的免費的開放源碼的對象關系數(shù)據(jù)庫，它是一種以關系數(shù)據(jù)庫和SQL為基礎，擴展了抽象數(shù)據(jù)類型，從而具備面向對象特性的數(shù)據(jù)庫。PostgreSQL數(shù)據(jù)庫由連接管理系統(tǒng)（系統(tǒng)控制器）、編譯執(zhí)行系統(tǒng)、存儲管理系統(tǒng)、事務系統(tǒng)、系統(tǒng)表五大部分組成，其組成結構和關系如圖2-3所示。

 

圖  PostgreSQL體系結構 

連接管理系統(tǒng)接受外部操作對系統(tǒng)的請求，對操作請求進行預處理和分發(fā)，起系統(tǒng)邏輯控制作用；編譯執(zhí)行系統(tǒng)由查詢編譯器、查詢執(zhí)行器組成，完成操作請求在數(shù)據(jù)庫中的分析處理和轉化工作，最終實現(xiàn)物理存儲介質中數(shù)據(jù)的操作；存儲管理系統(tǒng)由索引管理器、內存管理器、外存管理器組成，負責存儲和管理物理數(shù)據(jù)，提供對編譯查詢系統(tǒng)的支持；事務系統(tǒng)由事務管理器、日志管理器、并發(fā)控制、鎖管理器組成，日志管理器和事務管理器完成對操作請求處理的事務一致性支持，鎖管理器和并發(fā)控制提供對并發(fā)訪問數(shù)據(jù)的一致性支持；系統(tǒng)表是PostgreSQL數(shù)據(jù)庫的元信息管理中心，包括數(shù)據(jù)庫對象信息和數(shù)據(jù)庫管理控制信息。系統(tǒng)表管理元數(shù)據(jù)信息，將PostgreSQL數(shù)據(jù)庫的各個模塊有機地連接在一起，形成一個高效的數(shù)據(jù)管理系統(tǒng)[1]。