티스토리 뷰
본 포스팅은 PostgreSQL 아키텍처 구성에 대한 가이드입니다.
PostgreSQL는 오픈소스 Database입니다. RDB와 NoSQL을 모두 지원하며, 최근 확장성 있는 클라우드 환경에서 각광받고 있는 Database 중 하나입니다.
먼저 PostgreSQL의 아키텍처 구성 및 프로세스 정보에 대해 알아보겠습니다.
PostgreSQL의 특징은 다음과 같습니다.
- 프로세스 기반의 DBMS이다.
- 1개의 connection 마다 1개의 backend 프로세스 생성(Postmater 프로세스에 의해 fork)한다.
- Autovacuum launcher/worker 프로세스이다.
PostgreSQL은 다음과 같은 Process로 구성되어 있습니다.
1) Postmaster 프로세스는 제일 앞단에서 Client와 맞닫는 프로세스입니다.
- PostgreSQL 기동할 때 가장 먼저 시작되는 프로세스이다.
- 초기 복구 작업, 메모리 초기화, Background 프로세스 기동작업 수행한다.
- 데몬 프로세스로 Client 프로세스의 접속 요청을 받아 Backend 프로세스를 생성한다.
2) Background 프로세스는 로그, 통계 등 백그라운드에서 배치성으로 돌아가는 프로세스입니다.
- logger 에러 메시지를 로그 파일에 기록한다.
- checkpointer 체크 포인트 발생시 dirty 버퍼를 데이터파일에 기록한다.
- writer 주기적으로 dirty 버퍼를 데이터파일에 기록한다.
- wal writer WAL 버퍼를 WAL 파일에 기록한다.
- autovacuum launcher Vacuum 이 필요한 시점에 Postmaster 프로세스에 autovacuum worker 프로세스 기동 요청한다.
- archiver Archive mode 사용시 WAL 파일을 지정된 디렉토리로 복사한다.
- stats collector 세션 수행 정보, 테이블 사용 통계 정보 같은 DBMS 통계 정보 수집한다.
3) Backend 프로세스
- 클라이언트의 쿼리 요청을 수행 후 결과를 전달한다.
- 로컬 메모리 파라미터이다.
- work_mem : 정렬, Hash 조인 등의 작업에 사용되는 공간이다.
- maintenance_work_mem : Vacuum, Create Index 작업에 사용되는 공간이다.
- temp_buffers : Temporary 테이블을 저장하는 공간이다.
다음으로 PostgreSQL의 메모리 사용 부분에 대해 알아보겠습니다.
1) Shared Buffer
사용자가 요청한 데이터 블록을 저장하는 공간이다.
관리 알고리즘 : Clock Sweep 알고리즘(버퍼 메타데이터를 관리하는 버퍼 디스크립터를 순환하며 scan 하여 사용횟수를 감소시켜 미사용 버퍼를 탐색, NFU(Not Frequently Used) 알고리즘의 일종)한다.
2) WAL(Write Ahead Log) Buffer
데이터 변경 사항을 저장하는 버퍼이다.
WAL writer 프로세스를 통해 WAL 파일에 기록한다.
특징으로 SQL 정보를 관리하는 Oracle의 Library Cache 영역이 미존재한다.
shared_preload_libraries 설정으로 PostgreSQL 기동시 shared memory 영역 할당 가능(Extension 기능이 shared memory 영역을 사용하는 경우 예 : pg_stat_statements)하다.
다음으로 데이터 파일입니다.
database cluster 디렉토리에는 다음과 같은 구성으로 이루어져 있습니다.
- PostgreSQL 프로세스, 메모리, 데이터 파일을 관리하는 단위이다.
- 1개의 Postmaster 프로세스에 1개의 Cluster 존재한다.
- 데이터 파일, 로그 파일, 설정 파일 등을 저장하는 디렉토리이다.
- 서버 내에 여러 개의 database cluster가 존재할 경우 디렉토리와 포트 번호로 구분한다.
data 디렉토리 내부의 파일에 대한 주요 설명입니다.
base : pg_default 테이블스페이스 : 데이터베이스 별로 디렉토리 생성하여 데이터 저장한다.
global : pg_global 테이블스페이스 : Cluster 레벨에서 관리하는 데이터 저장한다.
pg_hba.conf : PostgreSQL에 접속을 관리하는 파일이다.
pg_log : log 파일 생성 디렉토리이다.
pg_tblspc : 사용자 테이블스페이스 : 테이블스페이스 디렉토리 symbolic link를 생성한다.
postgresql.auto.conf : ALTER SYSTEM 명령어로 파라미터 수정시 기록한다.
postgresql.conf : 주요 설정파일이다.
base 데이터 파일 저장 구조는 다음과 같다.
데이터베이스, 테이블, 인덱스 OID 로 디렉토리, 파일 생성한다.
오브젝트 구조는 다음과 같다.
- 1개의 Cluster 에 N개의 데이터베이스 생성이 가능하다.
- User, 테이블스페이스는 Cluster 에서 관리한다.
다음으로 MVCC(Multi-Version Concurrency Control)에 대해 알아보겠습니다.
다중 버전 동시성 제어 - DBMS의 사용자들에게 데이터의 여러 버전을 제공하여 동시성을 확보하는 기법이다.
트랜잭션의 시작 시점을 기준으로 하여 시작 시점보다 같거나 작은 데이터의 버전을 select 한다.
PostgreSQL MVCC 모델구현 방식은 다음과 같습니다.
페이지 레이아웃에 대해 알아보겠습니다.
페이지 크기 : 일반적으로 8 KB (소스로 컴파일 할 경우 변경 가능)를 차지합니다.
페이지 구성 요소는 다음과 같습니다.
구분 |
설명 |
PageHeader |
24 bytes, 페이지의 기본적인 정보 저장(Free Space 포인터 포함)한다. |
ItemIdData |
4 bytes, 데이터 시작위치, 크기가 저장된 포인터이다. |
Free Space |
미할당된 공간이다. |
Items |
데이터(튜플 헤더 + 튜플)이다. |
Special space |
일반적으로 미사용한다. |
pageinspect extension 으로 페이지 헤더 정보 및 튜플 헤더 정보를 조회할 수 있습니다.
이전 데이터를 데이터 페이지에 저장합니다.
레코드 별로 레코드가 생성된 시점(t_xmin), 레코드가 변경된 시점(t_xmax)을 기록하여 동일한 테이블에 저장한다.
Select 하는 트랜잭션 ID와 레코드의 t_xmin, t_xmax값을 비교하여 조회여부 판단한다.
레코드 별로 트랜잭션 ID(XID) 관리합니다.
레코드 별로 t_xmin(최소 XID), t_xmax(최대 XID) 관리한다.
XID 크기가 클수록 페이지를 비효율적으로 사용하기 때문에 PostgreSQL의 XID 는 4바이트 정수형으로 정의한다.
이에대한 발생 가능한 문제점은 다음과 같습니다.
- 데이터 페이지의 비효율적으로 사용, 이전 데이터에 대한 별도 관리의 필요성이 발생합니다.
update는 기존 레코드의 t_xmax 값 변경, 신규 레코드 insert 한다.
delete는 기존 레코드의 t_xmax 값 변경한다.
update, delete가 빈번한 테이블은 실제 데이터와 이전 데이터(dead tuple) 가 차지하는 공간으로 테이블 크기가 실제 크기 보다 많이 차지하게 된다.
- XID 크기에 의한 Wraparound 현상 발생합니다.
4바이트 정수형(32bit) 최대값(4,294,967,296)에 의한 제한 문제가 발생한다.
1000TPS 시스템의 경우 약 50일이면 모든 XID 소진한다.
모든 XID를 소진하면 다시 처음부터 시작하기 때문에 XID 에 의한 트랜잭션 순서 보장이 되지 않는다.
해결방안을 다음과 같이 제시하고자 합니다.
- PostgreSQL의 MVCC 모델에 의해 발생되는 문제점을 해결하는 Vacuum프로세스를 활용합니다.
구분 |
기능 |
VACUUM |
- Dead tuple이 사용하던 공간 반환 작업 수행 한다. - OS에 빈 블록 반환 하지 않아 테이블 크기 유지 한다. - 동시에 DML 사용이 가능하다. - Autovacuum 수행이 가능하다. |
VACUUM ANALYZE |
- Vacuum 과 analyze(테이블 통계정보 수집) 동시 수행한다. - 동시에 DML 사용이 가능하다. - Autovacuum 수행이 가능하다. |
VACUUM FREEZE |
- XID 순환현상 발생하지 않도록 XID 변경작업 수행 한다. - 동시에 DML 사용이 가능하다. - Autovacuum off로 설정하여도 수행된다. |
VACUUM FULL |
- 신규 파일 생성하여 live tuple 복제 수행, 테이블 크기 축소한다. - 동시에 DML 사용이 불가능하다. - Autovacuum 수행이 가능하다. |
이를 통해 발생가능한 문제를 예방 할 수 있습니다.
이상으로 PostgreSQL Architecture에 대해 알아보았습니다. 도입을 고민하는 사이트에서는 본 자료를 참고하셔서 유용히 사용하시기를 바랍니다.
고맙습니다.
'⑤ 개발, 데이터베이스 > ⓓ Database' 카테고리의 다른 글
[SQL 1일차] 데이터베이스와 테이블 그리고 DML (0) | 2018.07.03 |
---|---|
[Database] PostgreSQL Install & wildfly 연동 (0) | 2018.06.15 |
[PostgreSQL] 유용한 명령어 모음 Part 2 (0) | 2018.04.05 |
[Database] PostgreSQL 유용한 명령어 모음 (0) | 2018.04.05 |
[PostgreSQL] Install for Linux & 기동 종료 (0) | 2018.04.04 |
- Total
- Today
- Yesterday
- nodejs
- 마이크로서비스
- OpenStack
- MSA
- openstack tenant
- 쿠버네티스
- git
- SWA
- API Gateway
- JEUS7
- Docker
- kubernetes
- aws
- Architecture
- 마이크로서비스 아키텍처
- k8s
- 오픈스택
- SA
- jeus
- apache
- JBoss
- 아키텍처
- webtob
- Da
- aa
- wildfly
- node.js
- JEUS6
- TA
- openstack token issue
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |