DB2 Vs MySQL系列 |：體系架構對比

前些日子，我們做了DB2 VS MySQL的數據類型的對比，今天我們將體系架構的對比分享給大家，讓大家對這兩類數據庫有更深刻的認識。

DB2體系結構

DB2 for LUW進程模型在DB2v9.5之前都是多進程模型，DB2 v9.5之后體系架構變更為單進程多線程模型。

是一個C/S結構，客戶端可以通過TCP/IP或IPC協議與服務器通信，每當客戶端與服務器建立連接之后，會在服務器端產生一個代理線程（db2agent）負責處理來自客戶端的所有請求，但是當某一時刻并發請求很多或者連接斷開時，重復地產生與銷毀代理線程會產生很大的系統開銷，所以DB2服務器在啟動時創建一個常連接池來避免重復地創建/銷毀代理線程。

但是如果某一個處理的請求非常大時，如果單個線程去處理效率比較低下，為了提高單個請求的處理能力，與客戶端通信的那個代理線程（db2agent）可以從線程池中額外召集幾個線程（db2agentp）來共同處理某個請求。

DB2的線程分類

• 常連接池內的線程db2agent和db2agentp

處理客戶端請求，比如從bufferpool中取請求的數據，或者將請求拆解放到預?。╬refetch）隊列中供預取進程（prefetcher）從磁盤取數據使用、或者將一些DML操作記錄到日志緩沖區（logbuffer）中等。

• 通信管理線程db2tcpcm和db2ipccm

負責對來自客戶端的連接請求進行安全驗證和檢查，并與客戶端實現三次握手連接。

• 數據頁預取進程db2pfchr/頁面清理進程db2pclnr

當請求的數據不在bufferpool中時，需要預取進程db2pfchr通過異步讀數據的方式將將所需數據從磁盤讀入bufferpool中。

DB2對數據的操縱主要在bufferpool中進行，當插入某些數據或對某些數據做了變更后形成臟頁（dirtypage）后，需要使用線程db2pclnr根據一定的機制定期清理bufferpool中的臟頁，一方面持久化數據，另一方面給bufferpool騰出更多可置換空間供使用。

• 日志頁讀寫進程db2loggr/db2loggw

DB2采用的是讀日志優先（Readlog ahead）的策略來持久化數據，即在將insert/delete/update的數據寫入磁盤前，必須先將對這些操作的日志從日志緩沖區持久化到磁盤當中，這個操作由db2loggw線程完成。

當需要使用持久化到磁盤的日志恢復或撤銷某些操作時，需要從磁盤中將對應的日志讀入到日志緩沖區中，此時有db2loggr線程完成。

• 全局死鎖檢測線程db2dlock

該線程主要是檢測系統死鎖防止因為死鎖造成的應用不可用。

以下為部分常見DB2管理工具和實例：

DB2實例命令

MySQL體系結構

MySQL的體系架構如上圖所示，可將其劃分為以下三個邏輯層：

• 應用層（Application Layer）

• 邏輯層（Logical Layer）

• 物理層（Physical Layer）

應用層ApplicationLayer

MySQL管理工具和應用實例（Administrator&Utilities）

主要是連接到MySQL服務器檢索、修改或增加數據，有以下常見MySQL管理工具或實用程序。

本地查詢接口（Query Interface）

MySQL查詢接口主要指mysql腳本，使用mysql工具可以直接與MySQL服務器交互，是日常與MySQL服務器打交道最頻繁的工具。

客戶端應用接口（Client API）

客戶端應用接口主要是使用MySQL服務器對外公布的一些API調用訪問數據庫，主要有CAPI、Python API以及JavaAPI。

邏輯層LogicalLayer

MySQL邏輯層主要是包括以下幾個功能：

• SQL引擎編譯SQL語句

將客戶端發送的SQL語句請求通過SQL引擎將SQL語句編譯成MySQL服務器內部存取數據的指令的過程，編譯過程包括查詢解析（QueryParser）、查詢檢查(Query check)，查詢優化（QueryOptimizer）以及查詢執行（Query Excution）四個階段。

• 事務控制

事務（Transaction）是由一組SQL語句組成的邏輯處理單元，這個邏輯處理單元被原子性地處理，即要么其中的所有SQL語句全部執行成功，要么全部失敗，沒有第三種可能。那么MySQL是怎么保證事務被原子性地處理呢？這就是Transactionmanagement組件的功能了。當事務全部處理完畢時，通過該組件完成決定commit還是rollback操作。

• 日志管理

數據庫需要將所有對數據變更的操作記錄下來，以便當數據庫發生crash時做Redo或Undo操作，或者在分布式結構中將操作通過從一個計算節點共享到其他計算節點，這些功能都是通過事務日志來控制的。

MySQL的事務日志管理系統是Recoverymanagement組件，主要功能是持久化事務日志以及當數據庫crash時將數據庫恢復到crash之前的一致性狀態。

• 存儲管理（Storage management）

數據庫中操作數據的主要場所是bufferpools，怎么控制數據頁和索引頁在bufferpool中的狀態就是通過storagemanagement完成的，該組件主要還是對Page層面的管理，包括將頁讀入內存、頁的清理等。

值得一提的是，MySQL的邏輯層的上述幾個組件功能并不是MySQL特有的，而是普遍適用于DB2/Oracle等常見關系型數據庫。

物理層PhysicalLayer

數據庫的物理層主要關注的是數據怎么落地存儲以及被有效訪問的問題，MySQL的物理層設計比較特殊，MySQL提供了多種存儲引擎供用戶選擇，而且這些存儲引擎是可插拔的（Pluggable）,這是區別于業內其他關系型數據庫的一個很重要的特征。

MySQL數據庫為用戶提供了20多種可插拔的存儲引擎，比較常見的有如下列表所示幾種：

如上圖的存儲引擎中，從功能上比較接近商業數據庫功能的是InnoDB存儲引擎。從MySQL5.5開始，InnoDB成為MySQL服務器的默認存儲引擎；而早在SunMicroSystem被Oracle收購之前的2005年，InnoDB存儲引擎就被Oracle收購。

相比較于其他MySQL存儲引擎，MySQLInnoDB存儲引擎支持以下關鍵特性：

• 多版本并發控制（MVCC）

• 行級鎖（Row-level Locking）

• 外鍵支持（Foreign key support）

• 群集索引（Cluster Indexing）

• 可自由分配的bufferpools

• 在線數據庫備份

以下以InnoDB內部是怎么和磁盤文件交互的詳細架構示意圖

如下圖是支持訪問MySQL數據庫服務器的API接口類型，可以通過編寫程序調用四種API接口訪問MySQL數據庫：

• JDBC with Connector/J

通過Java程序訪問MySQL服務器

• .NET with Connector/NET

使用.NET程序訪問MySQL服務器

• 
  

• ODBC with Connector/ODBC

• Other APIs with C Library

使用基于C語言庫的編程語言，比如C/C++語言、Python/PHP/Perl/Ruby語言等訪問MySQL數據庫。

總之，MYSQL支持通過當前最流行的幾種主流語言訪問。