DB2 Vs MySQL系列 |：體系架構對比
前些日子，我們做了DB2 VS MySQL的數(shù)據(jù)類型的對比，今天我們將體系架構的對比分享給大家，讓大家對這兩類數(shù)據(jù)庫有更深刻的認識。
DB2體系結構
DB2 for LUW進程模型在DB2v9.5之前都是多進程模型，DB2 v9.5之后體系架構變更為單進程多線程模型。
是一個C/S結構，客戶端可以通過TCP/IP或IPC協(xié)議與服務器通信，每當客戶端與服務器建立連接之后，會在服務器端產生一個代理線程（db2agent）負責處理來自客戶端的所有請求，但是當某一時刻并發(fā)請求很多或者連接斷開時，重復地產生與銷毀代理線程會產生很大的系統(tǒng)開銷，所以DB2服務器在啟動時創(chuàng)建一個常連接池來避免重復地創(chuàng)建/銷毀代理線程。
但是如果某一個處理的請求非常大時，如果單個線程去處理效率比較低下，為了提高單個請求的處理能力，與客戶端通信的那個代理線程（db2agent）可以從線程池中額外召集幾個線程（db2agentp）來共同處理某個請求。
DB2的線程分類
常連接池內的線程db2agent和db2agentp
處理客戶端請求，比如從bufferpool中取請求的數(shù)據(jù)，或者將請求拆解放到預?。╬refetch）隊列中供預取進程（prefetcher）從磁盤取數(shù)據(jù)使用、或者將一些DML操作記錄到日志緩沖區(qū)（logbuffer）中等。
通信管理線程db2tcpcm和db2ipccm
負責對來自客戶端的連接請求進行安全驗證和檢查，并與客戶端實現(xiàn)三次握手連接。
數(shù)據(jù)頁預取進程db2pfchr/頁面清理進程db2pclnr
當請求的數(shù)據(jù)不在bufferpool中時，需要預取進程db2pfchr通過異步讀數(shù)據(jù)的方式將將所需數(shù)據(jù)從磁盤讀入bufferpool中。
DB2對數(shù)據(jù)的操縱主要在bufferpool中進行，當插入某些數(shù)據(jù)或對某些數(shù)據(jù)做了變更后形成臟頁（dirtypage）后，需要使用線程db2pclnr根據(jù)一定的機制定期清理bufferpool中的臟頁，一方面持久化數(shù)據(jù)，另一方面給bufferpool騰出更多可置換空間供使用。
日志頁讀寫進程db2loggr/db2loggw
DB2采用的是讀日志優(yōu)先（Readlog ahead）的策略來持久化數(shù)據(jù)，即在將insert/delete/update的數(shù)據(jù)寫入磁盤前，必須先將對這些操作的日志從日志緩沖區(qū)持久化到磁盤當中，這個操作由db2loggw線程完成。
當需要使用持久化到磁盤的日志恢復或撤銷某些操作時，需要從磁盤中將對應的日志讀入到日志緩沖區(qū)中，此時有db2loggr線程完成。
全局死鎖檢測線程db2dlock
該線程主要是檢測系統(tǒng)死鎖防止因為死鎖造成的應用不可用。
以下為部分常見DB2管理工具和實例：
DB2實例命令
MySQL體系結構
MySQL的體系架構如上圖所示，可將其劃分為以下三個邏輯層：
應用層（Application Layer）
邏輯層（Logical Layer）
物理層（Physical Layer）
應用層ApplicationLayer
MySQL管理工具和應用實例（Administrator&Utilities）
主要是連接到MySQL服務器檢索、修改或增加數(shù)據(jù)，有以下常見MySQL管理工具或實用程序。
本地查詢接口（Query Interface）
MySQL查詢接口主要指mysql腳本，使用mysql工具可以直接與MySQL服務器交互，是日常與MySQL服務器打交道最頻繁的工具。
客戶端應用接口（Client API）
客戶端應用接口主要是使用MySQL服務器對外公布的一些API調用訪問數(shù)據(jù)庫，主要有CAPI、Python API以及JavaAPI。
邏輯層LogicalLayer
MySQL邏輯層主要是包括以下幾個功能：
SQL引擎編譯SQL語句
將客戶端發(fā)送的SQL語句請求通過SQL引擎將SQL語句編譯成MySQL服務器內部存取數(shù)據(jù)的指令的過程，編譯過程包括查詢解析（QueryParser）、查詢檢查(Query check)，查詢優(yōu)化（QueryOptimizer）以及查詢執(zhí)行（Query Excution）四個階段。
事務控制
事務（Transaction）是由一組SQL語句組成的邏輯處理單元，這個邏輯處理單元被原子性地處理，即要么其中的所有SQL語句全部執(zhí)行成功，要么全部失敗，沒有第三種可能。那么MySQL是怎么保證事務被原子性地處理呢？這就是Transactionmanagement組件的功能了。當事務全部處理完畢時，通過該組件完成決定commit還是rollback操作。
日志管理
數(shù)據(jù)庫需要將所有對數(shù)據(jù)變更的操作記錄下來，以便當數(shù)據(jù)庫發(fā)生crash時做Redo或Undo操作，或者在分布式結構中將操作通過從一個計算節(jié)點共享到其他計算節(jié)點，這些功能都是通過事務日志來控制的。
MySQL的事務日志管理系統(tǒng)是Recoverymanagement組件，主要功能是持久化事務日志以及當數(shù)據(jù)庫crash時將數(shù)據(jù)庫恢復到crash之前的一致性狀態(tài)。
存儲管理（Storage management）
數(shù)據(jù)庫中操作數(shù)據(jù)的主要場所是bufferpools，怎么控制數(shù)據(jù)頁和索引頁在bufferpool中的狀態(tài)就是通過storagemanagement完成的，該組件主要還是對Page層面的管理，包括將頁讀入內存、頁的清理等。
值得一提的是，MySQL的邏輯層的上述幾個組件功能并不是MySQL特有的，而是普遍適用于DB2/Oracle等常見關系型數(shù)據(jù)庫。
物理層PhysicalLayer
數(shù)據(jù)庫的物理層主要關注的是數(shù)據(jù)怎么落地存儲以及被有效訪問的問題，MySQL的物理層設計比較特殊，MySQL提供了多種存儲引擎供用戶選擇，而且這些存儲引擎是可插拔的（Pluggable）,這是區(qū)別于業(yè)內其他關系型數(shù)據(jù)庫的一個很重要的特征。
MySQL數(shù)據(jù)庫為用戶提供了20多種可插拔的存儲引擎，比較常見的有如下列表所示幾種：
如上圖的存儲引擎中，從功能上比較接近商業(yè)數(shù)據(jù)庫功能的是InnoDB存儲引擎。從MySQL5.5開始，InnoDB成為MySQL服務器的默認存儲引擎；而早在SunMicroSystem被Oracle收購之前的2005年，InnoDB存儲引擎就被Oracle收購。
相比較于其他MySQL存儲引擎，MySQLInnoDB存儲引擎支持以下關鍵特性：
多版本并發(fā)控制（MVCC）
行級鎖（Row-level Locking）
外鍵支持（Foreign key support）
群集索引（Cluster Indexing）
可自由分配的bufferpools
在線數(shù)據(jù)庫備份
以下以InnoDB內部是怎么和磁盤文件交互的詳細架構示意圖
如下圖是支持訪問MySQL數(shù)據(jù)庫服務器的API接口類型，可以通過編寫程序調用四種API接口訪問MySQL數(shù)據(jù)庫：
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數(shù)據(jù)庫。
總之，MYSQL支持通過當前最流行的幾種主流語言訪問。
