MySQL 體系架構 Oracle體系架構 PostgreSQL體系架構

一.邏輯模塊組成

總的來講，MySQL 能夠當作是二層架構，第一層咱們一般叫作SQL Layer，在MySQL 數據庫系統處理底層數據以前的全部工做都是在這一層完成的，包括權限判斷，sql 解析，執行計劃優化，querycache 的處理等等；    第二層就是存儲引擎層，咱們一般叫作Storage Engine Layer，也就是底層數據存取操做實現部分，由多種存儲引擎共同組成。因此，能夠用以下一張最簡單的架構示意圖來表示MySQL 的基本架構，如圖2-1 所示：

雖然從上圖看起來MySQL 架構很是的簡單，就是簡單的兩部分而已，但實際上每一層中都含有各自的不少小模塊，尤爲是第一層SQL Layer，結構至關複雜的。下面咱們就分別針對SQL Layer 和Storage Engine Layer 作一個簡單的分析。

 

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

一、初始化模塊

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

 

二、核心API

核心API 模塊主要是爲了提供一些須要很是高效的底層操做功能的優化實現，包括各類底層數據結構的實現，特殊算法的實現，字符串處理，數字處理等，小文件I/O，格式化輸出，以及最重要的內存管理部分。核心API 模塊的全部源代碼都集中在mysys和strings文件夾下面，有興趣的讀者能夠研究研究。

 

三、網絡交互模塊

底層網絡交互模塊抽象出底層網絡交互所使用的接口api，實現底層網絡數據的接收與發送，以方便其餘各個模塊調用，以及對這一部分的維護。全部源碼都在vio 文件夾下面。

 

四、Client& Server 交互協議模塊

任何C/S 結構的軟件系統，都確定會有本身獨有的信息交互協議，MySQL 也不例外。MySQL的Client & Server 交互協議模塊部分，實現了客戶端與MySQL 交互過程當中的全部協議。固然這些協議都是創建在現有的OS 和網絡協議之上的，如TCP/IP 以及Unix Socket。

 

五、用戶模塊

用戶模塊所實現的功能，主要包括用戶的登陸鏈接權限控制和用戶的受權管理。他就像MySQL 的大門守衛同樣，決定是否給來訪者「開門」。

 

六、訪問控制模塊

造訪客人進門了就能夠想幹嗎就幹嗎麼？爲了安全考慮，確定不能如此隨意。這時候就須要訪問控制模塊實時監控客人的每個動做，給不一樣的客人以不一樣的權限。訪問控制模塊實現的功能就是根據用戶模塊中各用戶的受權信息，以及數據庫自身特有的各類約束，來控制用戶對數據的訪問。用戶模塊和訪問控制模塊二者結合起來，組成了MySQL 整個數據庫系統的權限安全管理的功能。

 

七、鏈接管理、鏈接線程和線程管理

鏈接管理模塊負責監聽對MySQL Server 的各類請求，接收鏈接請求，轉發全部鏈接請求到線程管理模塊。每個鏈接上MySQL Server 的客戶端請求都會被分配（或建立）一個鏈接線程爲其單獨服務。而鏈接線程的主要工做就是負責MySQL Server 與客戶端的通訊，接受客戶端的命令請求，傳遞Server 端的結果信息等。線程管理模塊則負責管理維護這些鏈接線程。包括線程的建立，線程的cache 等。

 

八、Query 解析和轉發模塊

在MySQL 中咱們習慣將全部Client端發送給Server 端的命令都稱爲query，在MySQL Server 裏面，鏈接線程接收到客戶端的一個Query 後，會直接將該query 傳遞給專門負責將各類Query 進行分類而後轉發給各個對應的處理模塊，這個模塊就是query 解析和轉發模塊。其主要工做就是將query 語句進行語義和語法的分析，而後按照不一樣的操做類型進行分類，而後作出針對性的轉發。

 

九、QueryCache 模塊

Query Cache 模塊在MySQL 中是一個很是重要的模塊，他的主要功能是將客戶端提交給MySQL 的Select 類query 請求的返回結果集cache 到內存中，與該query 的一個hash 值作一個對應。該Query 所取數據的基表發生任何數據的變化以後，MySQL 會自動使該query 的Cache 失效。在讀寫比例很是高的應用系統中，Query Cache 對性能的提升是很是顯著的。固然它對內存的消耗也是很是大的。

 

十、Query 優化器模塊

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

 

十一、表變動管理模塊

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

 

十二、表維護模塊

表的狀態檢查，錯誤修復，以及優化和分析等工做都是表維護模塊須要作的事情。

 

1三、系統狀態管理模塊

系統狀態管理模塊負責在客戶端請求系統狀態的時候，將各類狀態數據返回給用戶，像DBA 經常使用的各類showstatus 命令，showvariables 命令等，所獲得的結果都是由這個模塊返回的。

 

1四、表管理器

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

 

1五、日誌記錄模塊

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

 

1六、複製模塊

複製模塊又可分爲Master 模塊和Slave 模塊兩部分， Master 模塊主要負責在Replication 環境中讀取Master 端的binary 日誌，以及與Slave 端的I/O 線程交互等工做。

Slave 模塊比Master 模塊所要作的事情稍多一些，在系統中主要體如今兩個線程上面。一個是負責從Master請求和接受binary 日誌，並寫入本地relay log 中的I/O 線程。另一個是負責從relay log 中讀取相關日誌事件，而後解析成能夠在Slave 端正確執行並獲得和Master端徹底相同的結果的命令並再交給Slave 執行的SQL 線程。

 

1七、存儲引擎接口模塊

存儲引擎接口模塊能夠說是MySQL 數據庫中最有特點的一點了。目前各類數據庫產品中，基本上只有MySQL 能夠實現其底層數據存儲引擎的插件式管理。這個模塊實際上只是一個抽象類，但正是由於它成功地將各類數據處理高度抽象化，才成就了今天MySQL 可插拔存儲引擎的特點。

 

 

二.各模塊工做配合

在瞭解了MySQL 的各個模塊以後，咱們再看看MySQL各個模塊間是如何相互協同工做的。

接下來，咱們經過啓動MySQL，客戶端鏈接，請求query，獲得返回結果，最後退出，這樣一整個過程來進行分析。

當咱們執行啓動MySQL 命令以後，MySQL 的初始化模塊就從系統配置文件中讀取系統參數和命令行參數，並按照參數來初始化整個系統，如申請並分配buffer，初始化全局變量，以及各類結構等。同時各個存儲引擎也被啓動，並進行各自的初始化工做。當整個系統初始化結束後，由鏈接管理模塊接手。鏈接管理模塊會啓動處理客戶端鏈接請求的監聽程序，包括tcp/ip 的網絡監聽，還有unix 的socket。這時候，MySQL Server 就基本啓動完成，準備好接受客戶端請求了。

當鏈接管理模塊監聽到客戶端的鏈接請求（藉助網絡交互模塊的相關功能），雙方經過Client & Server 交互協議模塊所定義的協議「寒暄」幾句以後，鏈接管理模塊就會將鏈接請求轉發給線程管理模塊，去請求一個鏈接線程。

線程管理模塊立刻又會將控制交給鏈接線程模塊，告訴鏈接線程模塊：如今我這邊有鏈接請求過來了，須要創建鏈接，你趕快處理一下。鏈接線程模塊在接到鏈接請求後，首先會檢查當前鏈接線程池中是否有被cache 的空閒鏈接線程，若是有，就取出一個和客戶端請求鏈接上，若是沒有空閒的鏈接線程，則創建一個新的鏈接線程與客戶端請求鏈接。固然，鏈接線程模塊並非在收到鏈接請求後立刻就會取出一個鏈接線程連和客戶端鏈接，而是首先經過調用用戶模塊進行受權檢查，只有客戶端請求經過了受權檢查後，他纔會將客戶端請求和負責請求的鏈接線程連上。

在MySQL 中，將客戶端請求分爲了兩種類型：一種是query，須要調用Parser 也就是Query 解析和轉發模塊的解析纔可以執行的請求；一種是command，不須要調用Parser 就能夠直接執行的請求。若是咱們的初始化配置中打開了Full QueryLogging 的功能，那麼Query 解析與轉發模塊會調用日誌記錄模塊將請求計入日誌，無論是一個Query 類型的請求仍是一個command 類型的請求，都會被記錄進入日誌，因此出於性能考慮，通常不多打開Full QueryLogging 的功能。

當客戶端請求和鏈接線程「互換暗號（互通協議）」接上頭以後，鏈接線程就開始處理客戶端請求發送過來的各類命令（或者query），接受相關請求。它將收到的query語句轉給Query 解析和轉發模塊，Query 解析器先對Query 進行基本的語義和語法解析，而後根據命令類型的不一樣，有些會直接處理，有些會分發給其餘模塊來處理。

若是是一個Query 類型的請求，會將控制權交給Query解析器。Query 解析器首先分析看是否是一個select 類型的query，若是是，則調用查詢緩存模塊，讓它檢查該query 在query cache 中是否已經存在。若是有，則直接將cache 中的數據返回給鏈接線程模塊，而後經過與客戶端的鏈接的線程將數據傳輸給客戶端。若是不是一個能夠被cache 的query類型，或者cache 中沒有該query 的數據，那麼query 將被繼續傳回query 解析器，讓query解析器進行相應處理，再經過query 分發器分發給相關處理模塊。

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

 

在各個模塊收到Query 解析與分發模塊分發過來的請求後，首先會經過訪問控制模塊檢查鏈接用戶是否有訪問目標表以及目標字段的權限，若是有，就會調用表管理模塊請求相應的表，並獲取對應的鎖。表管理模塊首先會查看該表是否已經存在於table cache 中，若是已經打開則直接進行鎖相關的處理，若是沒有在cache 中，則須要再打開表文件獲取鎖，而後將打開的表交給表變動管理模塊。

 

當表變動管理模塊「獲取」打開的表以後，就會根據該表的相關meta 信息，判斷表的存儲引擎類型和其餘相關信息。根據表的存儲引擎類型，提交請求給存儲引擎接口模塊，調用對應的存儲引擎實現模塊，進行相應處理。

不過，對於表變動管理模塊來講，可見的僅是存儲引擎接口模塊所提供的一系列「標準」接口，底層存儲引擎實現模塊的具體實現，對於表變動管理模塊來講是透明的。他只須要調用對應的接口，並指明表類型，接口模塊會根據表類型調用正確的存儲引擎來進行相應的處理。

當一條query 或者一個command 處理完成（成功或者失敗）以後，控制權都會交還給鏈接線程模塊。若是處理成功，則將處理結果（多是一個Result set，也多是成功或者失敗的標識）經過鏈接線程反饋給客戶端。若是處理過程當中發生錯誤，也會將相應的錯誤信息發送給客戶端，而後鏈接線程模塊會進行相應的清理工做，並繼續等待後面的請求，重複上面提到的過程，或者完成客戶端斷開鏈接的請求。

若是在上面的過程當中，相關模塊使數據庫中的數據發生了變化，並且MySQL 打開了binlog 功能，則對應的處理模塊還會調用日誌處理模塊將相應的變動語句以更新事件的形式記錄到相關參數指定的二進制日誌文件中。

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

 

瞭解到整個處理過程以後，咱們能夠將以上各個模塊畫成如圖2-2 的關係圖：

 

 

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

 

 

Oracle體系結構介紹

                                      --基礎篇

        在學習oracle中，體系結構是重中之重，掌握的越深刻越好。在實際工做遇到疑難問題，其實均可以歸結到體系結構中來解釋，因此咱們根據下面的示圖瞭解一下oracle體系結構。

   

 

    

 1. Summarize

        根據示圖，便於咱們記憶，示圖分三部分組成，左側User Process、Server Process、PGA能夠看作成Clinet端，上面的實例（Instance）和下面的數據庫（Database）及參數文件（parameter file）、密碼文件（password file）和歸檔日誌文件（archived logfiles）組成Oracle Server，因此整個示圖能夠理解成一個C/S架構。

    Oracle Server 由兩個實體組成：實例（instance）與數據庫（database）。這兩個實體是獨立的，不過鏈接在一塊兒。在數據庫建立過程當中，實例首先被建立，而後才建立數據庫。在典型的單實例環境中，實例與數據庫的關係是一對一的，一個實例鏈接一個數據庫，實例與數據庫也能夠是多對一的關係，即不一樣計算機上的多個實例打開共享磁盤系統上的一個公用數據庫。這種多對一關係被稱爲實際應用羣集（Real Application Clusters，RAC）RAC極大提升了數據庫的性能、容錯與可伸縮性（可能耗費更多的存儲空間）而且是oracle網格（grid）概念的必備部分。

2. Client端

     在Client端的做用是如何從客戶端建立服務器進程與數據庫進行交互的過程。

  2.1 User process

     用戶運行一個應用程序時與Oracle數據庫進程交互（例如：sql/plus）時，oracle建立一個用戶進程來運行用戶的應用程序。

  2.2 Server process

    Server Process是用來處理鏈接到實例的用戶進程（User Process）提交的請求。當應用程序與Oracle服務器運行在同一臺機器上時，某些用戶進程（User Process）能夠與Server Process合併爲同一個進程，即使減少系統開銷。從邏輯層面來說，用戶進程必需要經過一個Server Process來同Oracle進行通訊的.（只不過有些時候在同一臺機器的時候，某些User Process和Server Process會合並罷了）

  2.3 PGA

PGA（Program Global Area）程序全局區，是用戶進程鏈接到數據庫並建立一個會話時，由Oracle服務器進程分配的專門用於當前用戶會話的內存區，該區域是私有的。

    爲每一個用戶鏈接Oracle數據庫保留的內存

    當進程建立時分配

    進程結束後被釋放

    只能被一個進程使用

    參數：PGA_AGGREGATE_TARGET指定PGA的總共大小

3. Database

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

  3.1 Data files

    內容：

    1）用戶數據：用戶表、DML語句可調整；

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

    3）真實看到的文件

    做用：

    讀取數據

    特色：

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

    2）各類不一樣表空間 數據字典信息

    3）個人數據保存在表空間上，表空間是以多個數據文件的形式體現的。

  3.2 Control files

    內容：

    1）DB基本信息：DBID

    2）DB結構信息

    3）最後一次同步的SCN信息

    3.1）同步：內存區域database buffer cache的髒數據寫出磁盤

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

    4）當前日誌序列號

    5）RMAN備份信息

    做用：

    1）記錄數據庫基本信息

    2）記錄內存下一些信息

    特色：

    1）大小通常不變（固定部分、可變部分）

    2）個數，一個便可，分類存放

  3.3 Redo log files

    內容：

    按時間順序記錄着DB中的改變（redo entry條目），數據塊改變就會生成redo

    做用：

    提供數據的可恢復性

    特色：

    1）大小不變

    2）順序寫

    3）容量有限，循環覆寫

    4）至少兩組日誌，日誌成員冗餘

    5）提供恢復的手段

  3.4 Parameter file

   內容：

   1）記錄那些定製的DB參數

   2）參數默認值

   3）pfile：須要重啓實例和spfile

   做用：

   定義數據庫實例的屬性

   特色：

   兩種類型參數的特色

  3.5 Password file

   內容：

   特權身份用戶的口令

   做用:

   用於特權身份用戶登陸的驗證

   特色：

   1）操做系統、密碼認證方式登陸數據庫

   2）特高、特權身份登陸到數據庫實例啓動數據庫，跳過了數據字典的驗證

   3）O7：Oracle 7版本，啓用普通身份登陸

  3.6 Archived logfiles

    內容：

    重作日誌（redo log）歷史

    做用：

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

    2）保證redo log 不丟失

    特色：

    1）個數=當前日誌數-1

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

    3）命名須要具備惟一性：序列號、RAC節點號

    4）離線文件可經過操做系統命令管理

 4. Instance

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

  4.1 SGA

   內存結構包括兩個部分

   1）系統全局（SGA）：在實例啓動時候分配，是Oracle實例的基礎組件。

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

 4.1.1 Shared Pool

 

  用於存儲：

   1）最近執行的SQL語句

   2）最近使用的數據定義

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

   1）庫緩存

   2）數據字典緩存

   由參數SHARED_POOL_SIZE決定大小

  4.1.1.1 Library Cache

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

 

   1.2）共享經常使用的語句

   1.3）管理上遵循LRU規則

   1.4）包括兩個部分

   1.4.1）共享SQL區

   1.4.2）共享PL/SQL區

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

  4.1.1.2 Data Dictionary Cache

   2.1）存儲在數據庫中最近使用的定義

   2.2）包括數據文件、表、索引、列、用戶、權限和其餘的數據庫對象

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

   2.4）對於查詢和DML語句，若是數據字典的信息在緩存中可以提升響應時間

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

  4.1.2 Database Buffer Cache

   1）存儲從數據文件中得到的數據塊的鏡像

   2）當獲取和更新數據的時候可以大幅度的提升性能

   3）管理上遵循LRU規則

   4）參數DB_BLOCK_SIZE其塊的大小

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

   DB_CACHE_SIZE

   DB_KEEP_CACHE_SIZE

   DB_RECYCLE_CACHE_SIZE

   6）可以動態的調整大小

  4.1.3 Redo Log Buffer

   1）記錄全部數據庫的塊改變

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

   3）大小由參數LOG_BUFFER（不可動態調整）決定

  4.1.4 Large Pool

   1）是系統全局區中可選的一個部分

   2）用於：

   2.1）RMAN備份恢復操做

   2.2）I/0並行進程

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

   3）大小由參數LARGE_POOL_SIZE決定

   4）可以被動態的改變大小

  4.1.5 Java Pool

   1）Java命令的分析

   2）若是要安裝和使用Java

   3）大小由參數JAVA_POOL_SIZE決定，若是granule是4M，默認是24M,granule是16M，默認大小是32M

  4.1.6 Streams Pool

   流相關的數據在流池中，提升緩存效果。目前oracle較爲弱化，提升採用Oracle Golden Gate（OGG），高級複製功能。

  4.2 Process structure

   Oracle有如下幾種進程：

   1）用戶進程：在用戶鏈接數據時產生

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

   3）後臺進程：Oracle實例啓動的時候產生

   4）維持物理和內存之間的聯繫

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

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

  4.2.1 PMON

PMON（進程監測進程）：

1）清除失敗的進程

1.1）回滾事務

1.2）釋放鎖

1.3）釋放其餘資源

1.4）重啓死掉的dispatchers

1.5）動態註冊監聽器

  4.2.2 SMON

SMON（系統檢測進程）做用:

1）實例恢復：

1.1）前滾全部重作日誌中的改變

1.2）打開數據庫爲了用戶能訪問

1.3）回滾沒有提交的事務

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

  4.2.3 DBWR

DBWn（數據庫寫進程）寫的條件：

1）發生檢查點

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

3）沒有自由的緩存

4）超時發生

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）更新數據文件頭

3）更新控制文件

  4.2.6 ARCn

ARCn（歸檔進程）：

1）可選的後臺進程

2）當啓用歸檔方式後自動歸檔重作日誌文件

  PostgreSQL 體系架構

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

 

圖  PostgreSQL體系結構

 

鏈接管理系統接受外部操做對系統的請求，對操做請求進行預處理和分發，起系統邏輯控制做用；編譯執行系統由查詢編譯器、查詢執行器組成，完成操做請求在數據庫中的分析處理和轉化工做，最終實現物理存儲介質中數據的操做；存儲管理系統由索引管理器、內存管理器、外存管理器組成，負責存儲和管理物理數據，提供對編譯查詢系統的支持；事務系統由事務管理器、日誌管理器、併發控制、鎖管理器組成，日誌管理器和事務管理器完成對操做請求處理的事務一致性支持，鎖管理器和併發控制提供對併發訪問數據的一致性支持；系統表是PostgreSQL數據庫的元信息管理中心，包括數據庫對象信息和數據庫管理控制信息。系統表管理元數據信息，將PostgreSQL數據庫的各個模塊有機地鏈接在一塊兒，造成一個高效的數據管理系統[1]。