PostgreSQL / PPAS 기본 아키텍처 (Engine)

해당 페이지에서는 Postgresql / PPAS 기본 아키텍처 중 엔진영역에 대하여 다룬다.

(그림 출처 및 참고 사이트)

https://kimdubi.github.io/postgresql/psql_architecture/

https://www.interdb.jp/pg/pgsql05.html

http://ugenssnc.com/cloud3-3.html

 

 

 

 

PostgreSQL / PPAS 는 공식 Doc 에 공식 아키텍처 도식이 없기에 외부에서 그나마 잘 작성된 아키텍처 도식 2개를 같이 올린다. 각 도식에 빠진 부분은 아래에 일괄적으로 설명하겠다.

 

타 RDBMS 의 기본구조인 Engine + Data 영역과 유사하게 Mysql , MariaDB 도 Engine 영역, Data 영역으로 나뉜다.

또한 PostgreSQL 에서는 Oracle 아키텍처 요소와 유사한 부분이 있으므로 Oracle 아키텍처에 대해서 잘 알고 있다면 PostgreSQL 의 아키텍처 또한 빠르게 이해 할 수 있다.

 

우선 PostgreSQL 은 MySQL / MariaDB 와는 다르게, 기동 시 여러개의 필수 프로세스들이 같이 기동되며 수행된다.

이 역시 Oracle 과 유사하다. 

 

세션 또한 스레드 단위가 아닌 프로세스 단위로 할당을 받는다.

 

PostgreSQL / PPAS Engine 은 크게 Postmaster, Shared Memory, Backend Memory, Utility Process 영역으로 구성 된다. 세부적인 기능은 아래와 같다.

 

 

 

Postmaster

 

PostgreSQL / PPAS 프로세스들의 최상위 프로세스다. Oracle 의 리스너 처럼 외부 유저 혹은 어플리케이션의 접속 요청을 받아 개별 프로세스 (ORACLE 서버 프로세스) 를 부여하는 데몬 프로세스이다.

 

또한 최상위 프로세스답게 하위 프로세스들의 비정상 작동유무등도 체크하며, 하위 프로세스가 강제 종료등의 문제가 발생 시, 이를 다시 재기동 시켜 줄 수 있는 기능도 있다. (즉, Oralce 의 PMON 역할을 겸한다.)

 

Shared Memory

 

모든 세션들이 공유하여 사용하는 공간이다. Oracle 의 SGA 와 유사하다. Shared Memory 는 아래의 요소들이 있다.

 

 

- Shared Buffer

 

데이터 영역에서 참조된 데이터를 저장하는 공간이다. 즉, 일반적인 RDBMS 작업에서 사용되는 메모리 버퍼 캐시 영역이다. 공식 Doc 에서는 서버 메모리의 25% 를 할당하는 것을 권장한다.

 

 

- WAL Buffer (Write Ahead Log Buffer)

 

데이터가 변경 될 시, 이에 대하여 변경된 내역을 저장하는 공간. Crash 발생 시, 복구에 쓰인다.

WAL 은 다른 DB에서도 사용되는 개념이나 PostgreSQL 에서는 명시적으로 Redo Log 영역에 대응하는 이름으로 쓴다.

 

 

- Clog Buffer

 

트랜잭션 상태 정보를 저장하는 공간. 각 트랜잭션의 commit 등의 상태값을 저장

 

 

- Lock Space

 

트랜잭션 간의 lock 정보를 저장하는 공간

 

 

- Other Buffers

 

위의 주요 공간이 외에 다른 기능들을 처리하는 공간들이 있는 곳이다. 통계정보, two-phase-commit 등의 버퍼공간이 있다. (two-phase-commit 개념 참조 : weicomes.tistory.com/378)

 

Backend Memory

 

각 세션들이 할당받아 사용하는 공간이다. Oracle 의 PGA 와 유사하다. Backend Memory 는 아래의 요소들이 있다.

 

 

- maintenance_work_mem

 

Vacuum, Create Index 등의 작업을 위해 사용하는 공간이다. 파라미터를 통하여 기동시에 각 세션들마다 동일한 크기의 공간이 할당 되나, 작업을 할 세션단위로 임의 조절이 가능하다.

실제로 인덱스 추가 등의 업무 수행 시에도 매우 유용하게 쓰이는 파라미터다.

 

 

- temp_buffer

 

DB에서 사용하는 임시테이블들을 저장하는 공간이다. PostgreSQL 에서 내부적으로 작업을 처리할시에 임시적으로 생성하는 테이블이 있을 수 있는데 이를 위해서 마련된다.

 

 

- work_mem

 

Order by, Distinct 등의 정렬과 관련된 작업, Join, Hash Table 작업을 위해서 사용하는 공간이다. 실제 각 세션별 데이터작업들에는 sort 작업이 많은 편이기 때문에 이 영역도 파라미터 조절을 통해 공간을 확보 해 주면 좋다.

(실제 메모리 영역에 대비하여 필수적으로 계산을 해주는 영역중 하나다.)

 

 

- catalog cache 

 

PostgreSQL 에서는 DB 내 모든 영역들에 대한 메타데이터를 pg_catalog 에 보관하며, Catalog Cache 또한 이를 위해서 존재 하는 공간이다. 각 세션들이 메타데이터를 조회하거나 이용하는 경우가 많은데 이때 마다 디스크를 조회하면 속도저하가 일어나기 때문에 이를 방지하기 위해 메모리상에 마련하는 공간이다.

 

 

- optimizer, executor

 

MySQL / MariaDB 와 같이 수행할 쿼리들에 대한 최적의 실행 계획 수립 (Optimizer) 및 실행 계획에 따른 실행 (Executor) 을 담당하는 영역이다.

 

Utility Process

 

- writer

 

Background Writer 로 명칭하기도 한다 . Shared Buffer 에 변경 된 데이터들을 디스크(DB 파일)에 써 내리는 역할을 맡는다. 타 RDBMS 와 같이 Write Ahead Log Writing (선행 기입법) 에 근거 하여 변경된 내용을 수시로 쓰지 않고 모아 두며 WAL Writer 가 먼저 WAL File 에 먼저 지속적으로 기록하다가 특정 시점이 되면 일괄로 디스크에 데이터를 기록 하고 메모리영역에 있는 데이터를 다 써 내렸다는 기록을 DB 내부에 기록 해 둔다. 이를 checkpoint 라고 한다.

 

 

- wal writer

 

wal buffers 에 기록되는 DB 트랜잭션. 변경내역을 디스크(wal file)에 기록하는 프로세스. 디스크에 기록하는 조건은

commit 및 로그파일 공간을 모두 다 채웠을 때다. (관련된 파라미터를 통해 기록 시간을 조절 가능)

 

 

- checkpointer

 

9.2 부터 추가된 프로세스. 기존 checkpoint 역할을 수행하던 writer 를 대신하여 checkpoint 를 수행한다.

 

 

- archiver

 

백업을 통한 시점복구를 위해서 마련하는  아카이브 파일을 기록하는 프로세스. 파라미터 에서 설정이 가능한데 on off 를 선택 할 수 있으며 기본은 off 다. 보통 off 는 개발, 테스트 같이 시점복구등이 전혀 필요없는 사항에 설정되고

on 설정은 운영서버에는 필수적으로 적용해야 한다고 보면 된다. (이 설정도 Oracle Archive 와 매우 유사하다)

 

 

- logging collector

 

시스템 내 시스템 로그들을 기록하는 프로세스. 9.6 버전까지는 default 가 pg_log 디렉토리에 로그파일 생성 및 내용들을 기록하였으나 10 이후부터는 log 디렉토리로 바뀌었다.

 

 

- stats collector

 

통계수집을 담당하는 프로세스. archive 같이 on off 설정이 가능하다. 자체적으로 수집 시점을 탐지하다 특정 기록 시점이라 판단되면 통계 데이터를 수집한다.

 

 

- autovacuum launcher

 

vacuum 대상 및 시점에 대해서 인지 하다가 vacuum 작업이 필요하다 판단 되면 자동으로 vacuum 을 수행시켜 주는 프로세스. 파라미터를 통하여 vacuum 을 수행 할 세션 개수를 조절 가능 하며 해당 작업을 수행하는 세션은 작업 완료 후 자동 종료 된다.