[Architecture of a Database System] Process Models

multi-user 서버를 디자인할 때, concurrent 유저의 요청과 이 요청이 어떻게 OS의 프로세스 또는 쓰레드에 매핑될지에 대해 고려해야한다. 이것은 퍼포먼스와 확장 가능성, 그리고 이식성에 영향을 끼친다.

이 장에서는 availability of operating system support for threads와 uniprocessor를 가정한다.

앞으로의 모든 설명은 다음 정의를 따른다.

• Operating System Process는 private한 address space를 가진 OS의 프로그램 실행 단위(thread of control)이다. 프로세스에는 OS resource handles와 security context가 포함된다. 프로세스 실행은 커널 스케쥴러에 의해 스케쥴링 된다.
• Operating System Thread는 private한 OS context와 address space가 없는 OS 프로그램 실행 단위이다. 쓰레드 실행은 커널 스케쥴러에 의해 스케쥴링 된다. 이를 커널 쓰레드라고 부른다.
• Lightweight Thread Package는 어플리케이션 레벨의 쓰레드이다. OS에 의해 스케쥴되는 OS 쓰레드와 달리, Lightweight 쓰레드는 어플리케이션 레벨의 쓰레드 스케쥴러에 의해 스케쥴된다. Lightweight 쓰레드는 커널 스케쥴러 없이 user-space에서만 실행된다.
  • 장점
    • OS 커널 모드로 스위치할 필요가 없어서 빠르다.
  • 단점
    • blocking operation을 실행하면 모든 쓰레드를 block한다.Lightweight thread package는 이 단점을 1)asynchronous I/O 요청만 실행시키고, 2) block시킬 수 있는 OS operation을 실행시키지 않음으로 해결한다.
• 몇몇 DBMS는 LWT packages를 구현해서 사용한다. 이를 DBMS 쓰레드 혹은 쓰레드 라고 부를 것이다.
• DBMS Client는 어플리케이션 프로그램이 사용하는 API를 구현한 소프트웨어 컴포넌트이다. 예로는 JDBC와 ODBC가 있다.
• DBMS Worker는 DBMS Client를 대신해 일하는 쓰레드이다. DBMS Worker와 DBMS Client는 1:1 매핑된다. DBMS Worker는 하나의 DBMS Client의 요청의 모든 SQL을 실행한다.

2.1 Uniprocessors and Lightweight Threads

다음 두 가지 가정을 바탕으로 시작한다.

1. OS thread support: OS가 커널 쓰레드에 대한 효율적인 서포트를 해주고 프로세스가 많은 쓰레드를 가질수 있다는 것을 가정한다. 또한 쓰레드의 오버헤드가 매우 작고, 컨텍스트 스위치가 비싸지 않다고 가정한다.
2. Uniprocessor hardware: 하나의 CPU를 가진 머신을 위한 디자인을 한다고 가정한다.

DBMS는 3가지 프로세스 모델 중 하나로 구현된다.

1. DBMS Worker 당 프로세스 하나
2. DBMS Worker 당 쓰레드 하나
3. 프로세스 풀

2.1.1 Process per DBMS Worker

이 모델은 DBMS worker가 OS 프로세스로 매핑되기 때문에 상대적으로 구현이 쉽다. OS 스케쥴러가 DBMS worker의 timesharing를 관리한다. 따라서 DBMS 개발자는 memory 침범과 같은 버그를 OS protection facilities에 의존할 수 있다.

이 모델의 단점은 DBMS의 커넥션 사이에서 공유되어야 하는 in-memory 자료구조 (lock 테이블과 버퍼 풀)를 구현하기 어렵다는 것이다. 이 공유되는 자료구조들은 모든 DBMS프로세스가 접근할 수 있도록 OS-supported 공유 메모리에 명시적으로 할당되어야 한다.

이 모델의 최대 단점은 concurrent 커넥션을 스케일 업 하기 어렵다는 것이다. 프로세스가 쓰레드보다 state가 더 많고 더 많은 메모리를 소모하기 때문이다.

IBM DB2, PostgreSQL, and Oracle가 이 모델을 사용한다.

2.1.2 Thread per DBMS Worker

하나의 멀티쓰레드 프로세스가 모든 DBMS의 활동을 관리하다. Dispatcher 쓰레드가 DBMS 클라이언트의 커넥션을 리슨한다. 각각의 커넥션에는 하나의 쓰레드가 할당된다.

OS가 memory overrun이나 stray pointer에 대해 보호해주지 않는다. 따라서 디버깅이 어렵다. 특히 race condition이 일어난 경우 더 어렵다. 쓰레드 인터페이스와 멀티 쓰레드 스케일링에 대한 정책이 OS에 따라서 다르기 때문에 OS에 이식(port)하기 어렵다.

concurrent 커넥션을 늘리기 쉽다.

IBM DB2, Microsoft SQL Server, MySQL, Informix, 그리고 Sybase와 같은 비교적 최근에 만들어진 DBMS 시스템에서 자주 사용된다.

2.1.3 Process Pool

Process per DBMS worker의 변형이다.

중앙의 프로세스가 모든 DBMS Client 커넥션을 가지고 있다. 클라이언트로부터 오는 각각의 SQL 요청은, 프로세스 풀의 프로세스에 쥐어진다. 모든 프로세스가 다른 요청을 처리하고 있을 때, 새로 들어온 요청은 프로세스를 사용 가능할 때 까지 기다린다(wait).

2.1.4 Shared Data and Process Boundaries

세가지 모델에서 데이터는 DBMS에서 클라이언트로 보내져야 한다. 모든 SQL 요청이 서버의 프로세스로 옮겨져서 클라이언트로 보내져야 한다는 뜻이다. 이는 다양한 버퍼를 사용해서 구현된다.

1. Disk I/O 버퍼
   • Database I/O Requests: The Buffer Pool. All persistent
     database data is staged through the DBMS buffer pool. all three DBMS models is that the buffer pool is a large shared data structure available to all database threads and/or processes.
   • Log I/O Requests: The Log Tail. The database log (Section 6.4) is an array of entries stored on one or more disks. As log entries are generated during transaction processing, they are staged to an in-memory queue that is periodically flushed to the log disk(s) in FIFO order. This queue is usually called the log tail.
2. Client communication 버퍼
   • SQL은 pull model을 사용한다. 따라서 클라이언트의 SQL FETCH request가 발새앟기 전에 DBMS는 일을 실행하고 enqueue시켜둬야 한다. prefetching에 대응하기 위해, DBMS 워커는 클라이언트 통신 소켓을 튜플의 큐로 사용한다.
3. Lock Table

2.2 DBMS Threads

2.2.1 DBMS Threads

1970년대에 연구되었고 1980년대에 상업화되었다. DBMS가 개발될 때는 지금 당연하게 여기는 OS의 특징이 없었다. 1990년대 전 까지는 OS thread가 보편화되지 않았었다. 따라서 DBMS는 OS의 Thread에 의존하지 않았다.

그리고 Thread Process Model은 좋은 커널 없이 잘 돌아가기 위한 솔루션이 필요했다. 몇몇 주요 DBMS가 채택한 방법은 자체 lightweight thread package를 구현하는 것이다.

Lightweight threads are an old idea that is discussed in a retrospective sense in [49], and are widely used in event-loop programming for user interfaces.

2.3 Standard Practice

Process per DBMS worker

• Oracle (process pool as optional)
• PostgreSQL (on all supported operating system)

Thread per DBMS worker

1. OS thread per DBMS worker
   • IBM DB2
   • MySQL
2. DBMS thread per DBMS worker
   1. DBMS threads scheduled on OS process
   2. DBMS threads scheduled on OS threads
      • Microsoft SQL Server non-default option

Process / Thread pool

1. DBMS workers multiplexed over a process pool
   • Oracle optional model
2. DBMS workers multiplexed over a thread pool
   • Microsoft SQL Server

intra-query parallelism is the temporary assignment of multiple DBMS workers to a single SQL query.

쿼리 내 병렬화는 단일 SQL 쿼리에 여러 DBMS 작업자를 임시로 할당하는 것이다.

2.4 Admission Control

DBMS thrashing: 메모리가 차서 망가지는 것

thrashing을 방지하기 위해 admission control 정책을 세워야 한다. admission control은 DBMS 자원이 사용 가능할 때 까지 새로운 작업을 허용하지 않는 것이다.

Admission Control은 두 계층에서 수행된다.

1. Dispatcher Process
   • 클라이언트 커넥션을 임계점 이하로 유지한다.
2. DBMS relational query processor
   • excecution admission control 이라고 한다.
   • 쿼리가 파싱되고 옵티마이즈 된 이후에 쿼리를 실행할지, 지연시킬지를 결정한다.