[PostgreSQL] 아키텍처 및 쿼리 워크플로우

 

 

1. 프로세스 아키텍처 (Process Architecture)

PostgreSQL은 사용자의 요청을 처리하기 위해 여러 개의 프로세스를 사용 함

 1-1. Postmaster (Daemon Process)

 - 데이터 베이스 서버가 시작될 때 가장 먼저 실행되는 부모 프로세스

 - 클라이언트의 연결 요청을 감시하고, 요청이 들어오면 새로운 'Backend Process'를 생성(fork)하여 연결을 넘겨줌

 1-2. Backend Process

 - 클라이언트와 1:1로 매핑되어 실제 SQL 쿼리를 실행하는 프로세스

 - 클라이언트가 접속을 종료할 때까지 유지 됨

 1-3. Nackground Processes

 - 데이터베이스의 성능과 안정성을 유지하기 위해 뒤에서 묵묵히 일하는 프로세스들

 - Writer(Checkpointer/Background Writer): 메모리에 있는 데이터를 주기적으로 디스크에 기록

 - WAL Writer: 틀내잭션 로그(Write Ahead Log)를 디스크로 안전하게 옮김

 - Autovacuum Launcher: 불필요해진 데이터(Garbage)를 정리하여 성능 저하를 막음

 

 

2. 메모리 아키텍처 (Memory Archiitecture)

데이터를 효율적으로 처리하기 위해 메모리는 공유 영역과 개별 영역으로 나뉨

 2-1. Shared Memory : 모든 프로세스가 공통으로 사용하는 공간

 - Shared Buffer : 디스크에서 읽어온 데이터 페이지를 보관하는 캐시 영역

 - WAL Buffer : 디스크에 기록하기 전 트랜잭션 로그를 임시 저장

 2-2. Local Memory : 각 Nackend Process가 자신만의 작업을 위해 할당받는 공간

 - Work Mem : 정렬(sort)이나 조인(join)작업을 수행할 때 사용 됨

 - Maintenance Work Mem : 인덱스 생성이나 진공(Vacuum) 작업 등 관리 업무에 사용 됨

 

 

3. 저장소 구조 (Storage Architecture)

데이터가 디스크에 불리적으로 어떻게 저장되는지를 결정

 3-1. Page/Block : PostgreSQL 저장소의 기본 단위(보통8KB)이다. 실제 행(Row) 데이터가 이 페이지 안에 저장 됨

 3-2. MVCC (Multi-Version Concurrency Control) : 동시성을 제어하는 핵심 기술. 데이터를 수정할 때 기존 데이터를 덮어쓰지 않고 새로운 버전을 생성함으로써, 읽기 작업과 쓰기 작업이 서로 방해받지 않게 함

 

 

 

쿼리 워크플로우

 

1. 연결(Connection) : 클라이언트가 접속을 요청하면 부모 프로세스인 Postmaster가 이를 받아 자식 프로세스인 Backend Process를 생성(fork)함. 이 때부터 해당 클라이언트 전용 통로가 생기는 것임 
2. 구문 분석(Parser) : 사용자가 보낸 SQL 문장에 오타가 없는지, 문법에 맞는지 검사하여 분석 트리(Parse Tree)를 만듦
3. 재작성 (Rewrite) : 뷰(View)나 룰(Rule) 시스템을 적용하여 쿼리를 더 단순하거나 구체적인 형태로 변형
4. 최적화 및 계획(Optimizer/Planner) : 핵심 단계. 통계 정보를 바탕으로 인덱스를 쓸지, 테이블 전체를 읽을지 결정하여 가장 비용이 적은 실행 계획 세움
5. 실행 (Executor) : 계획에 따라 데이터를 가져옴
   1. Shared Buffers(공유 메모리)에 찾는 데이터가 있는지 확인
   2. 없으면 디스크에서 읽어와 메모리에 올림
   3. 데이터를 수정한다면 WAL Buffers에 로그를 먼저 남기고 데이터 변경

 

 

잘 안 와닿아서 개인적으로 더 알아본 단계 설명

• 재작성 단계

active_users 라는 이름의 view가 있고 사용자가 쿼리문으로  "select * from active_users" 를 날린 경우 내부적으로는 "select * from users where status == 'active'" 를 실행해서 결과를 사용자에게 보여줌

 

 

• 최적화 단계

PostgreSQL의 옵티마이저는 비용 기반 최적화(CBO, Cost-Based Optimization) 방식 사용

비용은 쿼리를 실행할 때 예상되는 CPU 사용량과 디스크 I/O 등을 숫자로 계산한 값!

 

상세 워크플로우

1. 경로 생성(Path Generation): 데이털르 가져올 수 있는 모든 가능한 경로 탐색
   1. ex) 인덱스를 탈지, 그냥 처음부터 끝까지 풀스캔할지, 어떤 알고리즘을 사용할지 등
2. 비용 계산(Cost Estimation): 각 경로에 대해 수치를 매김. DB가 미리 수집해둔 통계정보를 참조
   1. ex) 이 테이블은 데이터가 100만 건이니까 인덱스가 효율적이다, 이 조건은 결과가 1건만 나오겠네 등
3. 최적의 계획 선택(Plan Selection): 계산된 비용 중 가장 낮은(가장 빠른) 경로를 최종 실행 계획(Plan Tree)으로 확정