前些日子，我們做了DB2 VS MySQL的數(shù)據(jù)類型的對比，今天我們將體系架構(gòu)的對比分享給大家，讓大家對這兩類數(shù)據(jù)庫有更深刻的認(rèn)識。

DB2體系結(jié)構(gòu)

DB2 for LUW進(jìn)程模型在DB2v9.5之前都是多進(jìn)程模型，DB2 v9.5之后體系架構(gòu)變更為單進(jìn)程多線程模型。

是一個C/S結(jié)構(gòu)，客戶端可以通過TCP/IP或IPC協(xié)議與服務(wù)器通信，每當(dāng)客戶端與服務(wù)器建立連接之后，會在服務(wù)器端產(chǎn)生一個代理線程（db2agent）負(fù)責(zé)處理來自客戶端的所有請求，但是當(dāng)某一時刻并發(fā)請求很多或者連接斷開時，重復(fù)地產(chǎn)生與銷毀代理線程會產(chǎn)生很大的系統(tǒng)開銷，所以DB2服務(wù)器在啟動時創(chuàng)建一個常連接池來避免重復(fù)地創(chuàng)建/銷毀代理線程。

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

DB2的線程分類

• 常連接池內(nèi)的線程db2agent和db2agentp

處理客戶端請求，比如從bufferpool中取請求的數(shù)據(jù)，或者將請求拆解放到預(yù)取（prefetch）隊列中供預(yù)取進(jìn)程（prefetcher）從磁盤取數(shù)據(jù)使用、或者將一些DML操作記錄到日志緩沖區(qū)（logbuffer）中等。

• 通信管理線程db2tcpcm和db2ipccm

負(fù)責(zé)對來自客戶端的連接請求進(jìn)行安全驗證和檢查，并與客戶端實現(xiàn)三次握手連接。

• 數(shù)據(jù)頁預(yù)取進(jìn)程db2pfchr/頁面清理進(jìn)程db2pclnr

當(dāng)請求的數(shù)據(jù)不在bufferpool中時，需要預(yù)取進(jìn)程db2pfchr通過異步讀數(shù)據(jù)的方式將將所需數(shù)據(jù)從磁盤讀入bufferpool中。

DB2對數(shù)據(jù)的操縱主要在bufferpool中進(jìn)行，當(dāng)插入某些數(shù)據(jù)或?qū)δ承?shù)據(jù)做了變更后形成臟頁（dirtypage）后，需要使用線程db2pclnr根據(jù)一定的機(jī)制定期清理bufferpool中的臟頁，一方面持久化數(shù)據(jù)，另一方面給bufferpool騰出更多可置換空間供使用。

• 日志頁讀寫進(jìn)程db2loggr/db2loggw

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

當(dāng)需要使用持久化到磁盤的日志恢復(fù)或撤銷某些操作時，需要從磁盤中將對應(yīng)的日志讀入到日志緩沖區(qū)中，此時有db2loggr線程完成。

• 全局死鎖檢測線程db2dlock

該線程主要是檢測系統(tǒng)死鎖防止因為死鎖造成的應(yīng)用不可用。

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

DB2實例命令

MySQL體系結(jié)構(gòu)

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

• 應(yīng)用層（Application Layer）

• 邏輯層（Logical Layer）

• 物理層（Physical Layer）

應(yīng)用層ApplicationLayer

MySQL管理工具和應(yīng)用實例（Administrator&Utilities）

主要是連接到MySQL服務(wù)器檢索、修改或增加數(shù)據(jù)，有以下常見MySQL管理工具或?qū)嵱贸绦颉?/p>

本地查詢接口（Query Interface）

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

客戶端應(yīng)用接口（Client API）

客戶端應(yīng)用接口主要是使用MySQL服務(wù)器對外公布的一些API調(diào)用訪問數(shù)據(jù)庫，主要有CAPI、Python API以及JavaAPI。

邏輯層LogicalLayer

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

• SQL引擎編譯SQL語句

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

• 事務(wù)控制

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

• 日志管理

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

MySQL的事務(wù)日志管理系統(tǒng)是Recoverymanagement組件，主要功能是持久化事務(wù)日志以及當(dāng)數(shù)據(jù)庫crash時將數(shù)據(jù)庫恢復(fù)到crash之前的一致性狀態(tài)。

• 存儲管理（Storage management）

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

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

物理層PhysicalLayer

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

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

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

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

• 多版本并發(fā)控制（MVCC）

• 行級鎖（Row-level Locking）

• 外鍵支持（Foreign key support）

• 群集索引（Cluster Indexing）

• 可自由分配的bufferpools

• 在線數(shù)據(jù)庫備份

以下以InnoDB內(nèi)部是怎么和磁盤文件交互的詳細(xì)架構(gòu)示意圖

如下圖是支持訪問MySQL數(shù)據(jù)庫服務(wù)器的API接口類型，可以通過編寫程序調(diào)用四種API接口訪問MySQL數(shù)據(jù)庫：

• JDBC with Connector/J

通過Java程序訪問MySQL服務(wù)器

• .NET with Connector/NET

使用.NET程序訪問MySQL服務(wù)器

• 
  

• ODBC with Connector/ODBC

• Other APIs with C Library

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

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