DBMS進程模型

• 關鍵定義
• 單處理機和輕量級線程
• • 每個DBMS工作者擁有一個進程
  • 每個DBMS工作者擁有一個線程
  • 進程池
  • 共享數據和進程空間
  • • 磁盤I/O緩沖區
    • 客戶端通信緩沖區
• DBMS線程
• 現在數據庫所支持的進程模型簡單列舉
• • 每個DBMS工作者擁有一個進程
  • 每個DBMS工作者擁有一個線程
  • • 每個 DBMS 工作者擁有一個系統線程
    • 每個 DBMS 工作者擁有一個DBMS線程
  • 進程/線程池
• 準入控制
• DBMS工作者與請求的多對多關系

關鍵定義

在討論進程模型前，必須要了解下面幾個重要定義：

• 操作系統進程：包含一個正在執行程序的活動單元以及專屬的地址空間。其中一個進程需要維護的狀態包括系統資源句柄和安全性上下文環境。
• 操作系統線程：操作系統程序執行單元，它沒有私有的地址空間和上下文。在多線程系統中，每個線程都可以共享地訪問所屬進程的地址空間。
• 輕量級線程包（又稱DBMS線程和簡單線程）：一個應用層次上的結構，支持單系統進程中的多線程。它不由操作系統內核調度線程，而是由應用級線程調度程序來負責調度。

輕量級線程的缺點：任何線程中斷操作，比如I/O中斷，都會打斷進程中的其他線程。
如何避免？

只接受無中斷的異步I/O操作；

不調用可以導致中斷的系統操作。

• DBMS客戶端：應用程序實現與數據庫系統通信API的軟件組件，JDBC、ODBC和OLE/DB等例。
• DBMS工作者：指DBMS中為客戶端工作的線程。一個DBMS工作者處理一個來自DBMS客戶端的SQL請求。DBMS客戶端發送SQL請求給DBMS服務器。DBMS工作者處理每一條請求并將結果返回客戶端（如下圖）。
  

單處理機和輕量級線程

為簡化介紹，先做兩個簡單的假設：

• 系統線程支持：即假設操作系統內核有效地支持線程，并且一個進程可以擁有很多線程。假設線程存儲空間很小，所以在切換時不需要太多的代價。
• 單處理機：假設我們針對僅擁有一個CPU的一臺機器。

DBMS擁有的三個天然的擁有三種進程模型性質。下面分別介紹這三種模型。

每個DBMS工作者擁有一個進程

這種模型，DBMS工作者直接映射到系統進程，這相對容易實現。但是，這種模型需要廣泛使用共享內存，使得地址空間分離的優勢被削弱了。

缺陷：因為進程相對線程而言，哦那個有更多的環境變量并且消耗更多的存儲空間。進程切換需要切換安全的上下文環境、存儲空間變量、文件和網絡句柄列表以及其他一些進程上下文。而線程不需要。

IBM DB2、PostgreSQL和Oracle支持該模型。

每個DBMS工作者擁有一個線程

在此模型中，一個多線程進程負責所有的DBMS工作者的工作。一個調度線程監聽新的DBMS客戶端連接。每個連接都被分配一個新的線程。當每個客戶端提交SQL請求時，都由對應的DBMS工作者線程執行。線程在DBMS進程中運行。

困難：操作系統對線程不提供溢出和指針的保護，調試困難。由于不同操作系統在線程接口和多線程擴展性方面的不同，使得軟件可移植性較差。

IBM DB2、微軟SQL Server、MySQL、Informix和Sybase支持這種模型。

進程池

進程池管理所有DBMS工作者。一個中央進程控制所有的DBMS客戶端連接，每個從客戶端來的SQL請求將被分配一個進程池中的進程。SQL請求處理完之后，結果返回客戶端，進程回到緩沖池中準備分配給下一個請求。

優勢：進程池擁有每個DBMS工作者擁有一個進程模型的所有優點，而且只需要少量的進程，其內存使用效率也很高。

缺陷：緩沖池的大小是一定的，且通常不可變。如果一個請求到來而沒有進程空閑，那么新的請求必須等待進程。

共享數據和進程空間

緩沖區的作用：通過使用緩沖區，服務器處理SQL請求，數據被DBMS傳送到客戶端。

兩種主要的緩沖區：磁盤I/O緩沖區和客戶端通信緩沖區。

磁盤I/O緩沖區

工作者之間的數據依賴是讀寫共享的數據。它們之間存在兩種不同的I/O中斷。

• 數據庫I/O中斷請求：緩沖池。數據庫提交的數據存放在數據庫緩沖池中，緩沖池中的數據以堆結構的形式存放，它作為所有進程共享的空間。
• 日志I/O請求：日志尾部。日志條目在事務處理過程中產生，被暫時存儲在內存隊列中，周期性地按照FIFO順序刷新至日志磁盤中。（在許多系統中，會有一個獨立的進程或者線程負責刷新）

日志管理方式：

• 一個獨立進程負責管理日志。日志記錄通過共享內存或者其他有效的通信協議與日志管理器進行交互。
• 日志尾部像上文提到的緩沖池安陽分配給共享內存。

一種重要的日志刷新方法是提交事務刷新。一個事務在日志記錄被刷新到日志存儲器之前不能被成功提交。

客戶端通信緩沖區

這是數據預提取的結果隊列，想要盡可能地在客戶端地SQL FETCH流前就準備好數據。

支持數據預提取功能的兩種方法：

DBMS工作者使用客戶端通信套接字作為元組隊列。

實現客戶端游標緩存功能，并使用 DBMS 客戶端存儲近期即將被訪問的結果，而不是依賴于操作系統通信緩沖區。

DBMS線程

為了應對那些沒有好的內核線程的系統。一些DBMS開發了自己的搞笑輕量級線程包。它們選擇使用DBMS輕量級線程包而不是系統線程。每個 DBMS線程都管理自己的變量，通過非中斷的異步接口來編寫中斷操作，并通過調度器來調度任務。

優勢和代價：提供了快速的任務切換和易移植性，但是需要在 DBMS 中重復實現許多操作系統邏輯。

現在數據庫所支持的進程模型簡單列舉

每個DBMS工作者擁有一個進程

DB2 在不支持線程的系統上，默認使用每個 DBMS 工作者擁有一個進程的模型，在支持線程的系統上，默認使用每個 DBMS工作者擁有一個線程的模型。

Oracle 進程模型的默認設計。

PostgreSQL 在所有的操作系統上都只運行每個 DBMS 工作者擁有一個進程模型。

每個DBMS工作者擁有一個線程

每個 DBMS 工作者擁有一個系統線程

IBM DB2 運行在有良好系統線程支持的系統上時，默認使用該模型。

MySQL 同樣使用該模型。

每個 DBMS 工作者擁有一個DBMS線程

在這個模型中，DBMS 工作者的調度是通過系統進程或線程去調度輕量級線程來實現的。這個模型規避了系統調度的一些問題，但是，它開發代價較高，沒有良好的開發工具，也需要運營商的長期維護。

兩種子模型：

• 通過系統進程來調度 DBMS 線程：輕量級線程的調度是由一個或多個系統進程來完成的。
  • Sybase 和 Informix 支持該模型。
• 通過系統線程來調度系統進程。
  • 微軟 SQL Sever 以可選擇的方式支持這種模型（默認的模型為 DBMS 工作者多路復用線程池）。
  • SQL Sever 中這個選項叫做 Fibers，被用做應對高頻事務處理，但是很少被使用。

進程/線程池

• DBMS 工作者共用進程池
  • Oracle 數據庫的可選項，Oracle 建議在大量用戶并發操作的情況下使用。
• DBMS 工作者共用線程池
  • 微軟 SQL Server 默認使用該模型，且超過 99%的 SQL Server產品使用該模型來運行。
  • SQL Server 提供可選支持，允許系統線程調度 DBMS 線程。

準入控制

隨著多用戶系統負載不斷升高，吞吐量將達到上限。任何好的多用戶系統都有準入控制機制，在系統沒有充足資源的情況下，新的任務不被接受。

好的準入器的作用：事務延遲將隨著到達率的增加而適當增加，但吞吐量一直保持在峰值。

DBMS 的準入控制可以在兩個層面上來實現：

一個簡單的準入控制可以通過進程來確保客戶端連接數處于一個臨界值之下。

直接在 DBMS 內核關系查詢處理器上實現。準入控制器在查詢語句轉換和優化完成后執行這一步操作。

對于第2種層面，準入控制具體控制：

• 是否要推遲執行一個查詢？
• 是否要使用更少的資源來執行查詢？
• 是否需要額外的限制條件來執行查詢？

如何執行？準入控制器依靠查詢優化器的信息來執行。

特殊情況下，優化器的查詢計劃可以：

確定查詢所需要的磁盤設備以及對磁盤的 I/O 請求數；

根據查詢中的操作以及要求的元組數目判斷 CPU 負載；

評估查詢數據結構的內存使用情況，包括在連接和其他操作期間的排序和哈希所消耗的內存。

DBMS 把內存使用情況和活躍的 DBMS 工作者的數量作為主要的準入控制標準。

DBMS工作者與請求的多對多關系

一個查詢的工作由多個 DBMS 工作者來完成，一個 DBMS 工作者負責多個查詢的同樣任務。

優勢：

允許一個工作者完成許多查詢的任務（可能提高系統的整體吞吐量）；

允許一個查詢由多個工作者共同完成（可能減少查詢操作的延時）；

在處理器局部性方面顯得更有優勢，在硬件未命中的情況下，能更好地防止 CPU 空閑。

總結

以上是生活随笔為你收集整理的【数据库】DBMS几种进程模型优劣与举例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。