[淺談]- How Do RDBMS Thread work ?

#database #RDBMS #Threads #關聯式資料庫 #多執行緒

在設計一個多人使用DBMS (database management system),基本上都會使用的 OS (operation system) 的多執行緒的功能,大概分為3種:

  1. Process per DBMS Worker

  2. Thread per DBMS Worker

  3. Process Pool

  4. DBMS Thread Pkg

在以下進行介紹時,有以下兩個假設(不討論在這兩個架設之外的細節):

  1. OS 本身已經支援 Thread

  2. 單核CPU 下的環境

1. Process per DBMS Worker

在 DBMS 中,一個 user 會對應到一個獨立的 OS Process 存取資料,這樣子就稱為Process per DBMS Worke。這樣子的作法的時空背景是在 OS Thread 技術才剛發展的年代,使得以現今的角度看,會有以下幾個問題:

  1. 需要更大的記憶體

  2. Context switch 需要觸發 OS 的 table, file, network 的機制,而這些thread 卻不用。

但好處就是可以使用到作業系統層級的 Process 交互機制。

2. Thread per DBMS Worker

在 DBMS 中所有的 user 都只會對應到 OS 的一個 Process,而不是所有的 user 都會有對應的 Process 。在這樣的做法下有以下好處:

  1. 更節省 Memory 的空間,更有利於大連線需求

  2. thread switch 比 Process 來得更快 (不需要等待 OS 排成)

壞處是:

  1. 有可能在操作 I/O 的時候造成 Process block

基於壞處,在這一類 DB 實作的時候,不會使用 Block (Sync) I/O ,反而會使用 None-Block (Async) I/O。

3. Process Pool

在 BDMS 中,多個連線共用多個 Process。這種方式是把可用的 Process 整合成一個 pool,這一類的 pool 可以動態的 scaling up/down。

這類型的設計會繼承所有的 Process per DBMS Worker 的好處,但更加節省資源。

4. DBMS Threads Pkg

在 Database 設計初期其實還沒有 threads 的概念,直到 1990 之後 thread 才普遍的存在於各 OS 中,因此大部分的 Relation Database 都沒有使用 thread 反而是獨立發展自己的 Thread Pkg.

Shared Data and Process Boundaries

在 DBMS 設計上都會盡可能地讓執行緒之間達到 independent,但事實上要完全做到是完全不可能的。勢必有可能會 worker 之間會存取到相同的記憶體位置。在資料庫的運作中,Client 透過 SQL 取得資料,事實上DBMS 要做到這件事情是要透過 buffer。

  1. Disk I/O Buffer: 用於 Read/Write 資料的 buffer 主要分成兩類:

    1. Database I/O Request: buffer pool 所有存取 persistent data 都必須透過此去達成

    2. Log I/O Request: A Queue for log. 所有執行緒存取資料都會需要更新 logs。然而再 Transaction 中,會以 log 作為是否成功的基準。換句話說,當執行 Transaction 的時候 DBMS 在未 flushed 之前,都不會釋放資源。

  2. Client communication buffers: 指的是 SQL。在 DBMS 去 Fetch 資料是透過 SQL 去抓取資料。在這部分,有時候要加速抓取的速度,有可能會使用先前已經執行過 SQL 用於達到 prefetch 的效果。

  3. Lock Table: 用於 Process 取用資源的一個保護機制,以避免 concurrency issues。

Admission Control

主要用於控制 Throughput 的機制,是一個非常重要的 DB 元件。尤其在多工系統中容易突破系統的臨界值 使得整體的效能大幅下降。因此 Admission Control Policy 對於 DBMS 來說是非常重要的。

一般來說有兩層:

  1. Process Dispatcher: 用於確保 client connection 低於臨界值

  2. Execution Admission Controller: 主要決定是否讓某個 query 執行或者延後。通常在 query 已經進行優化,解譯的階段才執行。

參考資料

[1] Hellerstein, Joseph M., Michael Stonebraker, and James Hamilton. "Architecture of a database system." Foundations and Trends® in Databases 1.2 (2007): 141-259.

Last updated