[PostgreSQL] PostgreSQL 기본 Architecture

Architecture 구성도

우선 PostgreSQL은 MySQL/MariaDB와는 다르게, 기동 시 여러 개의 필수 프로세스들이 같이 기동되며 수행된다.(Oracle과 유사)  또한 세션 또한 스레드 단위가 아닌 프로세스 단위로 할당을 받는다.

 

PostgreSQL Engine은 크게 Postmaster, Shared Memory, Backend Memory, Utility Process 영역으로 구성된다. 

세부적은 기능은 아래와 같다. 

 

   1. Postmaster 

       PostgreSQL 프로세스들의 최상위 프로세스다. Oracle의 Listener처럼 외부 유저 혹은 어플리케이션의 접속 요청을 받

       아 개별 프로세스(Oracle의 서버 프로세스)를 부여하는 데몬 프로세스이다. 

 

       또한 최상위 프로세스답게 하위 프로세스들의 비정상 작동 유무 등도 체크하며, 하위 프로세스가 강제 종료등의 문제

       가 발생시, 이를 다시 재기동 시켜줄 수 있는 기능도 있다. (즉, Oracle의 PMON 역할을 겸한다.) 

 

   2. Shared Memory 

 

       모든 세션들이 공유하여 사용하는 공간이다. Oralce의 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

         등의 버퍼공간이 있다. 

 

    3. Backend Memory 

 

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

  

        - Maintenance_work_mem : Vaccum, Create Index 등의 작업을위해 사용하는 공간이다. 파라미터를 통한여 기동 시

          에 각 세션들마다 동일한 크기의 공간이 할당 되나, 작업을 할 세션 단위로 임의 조절이 가능하다. 

 

        - temp_buffer : DB에서 사용하는 임시테이블들을 저장하는 공간이다. PostgreSQL에서 내부적으로 작업을 처리 할시

          에 임시적으로 생성하는 테이블이 있을 수 있는데 이를 위해서 마련된다. 

 

        - work_mem : Order by, Distinct 등의 정렬과 관련된 작업, Join, Hash Table 작업을 위해서 사용하는 공간이다. 

          실제 각 세션별 데이터 작업들에는 sort 작업이 많은 편이기 때문에 이 영역도 파라미터 조절을 통해 공간을 확보 해

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

 

        - catalog cache : PostgreSQL에서는 DB 내 모든 영역들에 대한 메타데이터를 pg_catalog에 보관하며, Catalog Cac

          he 또한 이를 위해서 존재 하는 공간이다. 

 

        - optimizer, executor : MySQL, MariaDB 와 동일하게 수행할 쿼리들에 대한 최적의 실행 계획 수립(Optimizer) 및 실

          행 계획에 따른 실행(Executor)을 담당하는 영역이다. 

   

     4. Utility Process 

     

        - Writer : Backgroud 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 역할을 수행 하던 wirter 대신하여 checkpoint를 수행한

          다. 

 

        - archiver : 백업을 통한 시점 복구를 위해서 마련하는 아카이브 파일을 기록하는 프로세스, 파라미터에서 설정이 가

          능한데, on/off를 선택할 수 있으며 기본은 off다. 보통 off는 개발, 테스트 같이 시점 복구등이 전혀 필요없는 사항에 

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

          다.)

 

        - logging collector : 시스템 내 시스템 로그들을 기록하는 프로세스, 9.6 버전까지는 default가 pg_log 디렉토리에 로그

          파일 생성 및 내용들을 기록하였으나 10 이후부터는 디렉토리로 비뀌었다.

 

        - stats collector : 통계 수집을 담당하는 프로세스, archive 같이 on/off 설정이 가능하다. 자체적으로 수집 시점을 탐지

          하다 특정 기록 시점이라 판단되면 통계 데이터를 수집한다. 

 

        - autovacuum launcher : vacuum 대상 및 시점에 대해서 인지 하다가 vacuum 작업이 필요하다 판단 되면 자동으로 

          vacuum을 수행시켜 주는 프로세스, 파라미터를 통하여 vacuum을 수행 할 세션 개수를 조절 가능하며, 해당 작업을 

          수행하는 세션은 작업 완료 후 자동 종료 된다.