[ 목적 ]
MySQL과 Postgresql의 철학을 이해하고 Postgresql 메모리 아키텍처의 차이를 이해하는 것을 목적으로 한다.
[ 철학 ]
MySQL과 Postgresql은 둘 다 OLTP 서비스에서 사용할 수 있는 RDBMS이다. 하지만 개발하게 된 철학과 기능, 아키텍처 등 많은 차이가 있다.
Mysql
MySQL의 철학은 '가볍고' 빠른 처리 속도와 간편한 사용을 강조하는 철학을 가지고 있다. 그렇기 때문에 다른 RDBMS에 비해 지원하는 기능이 부족하다. 쿼리의 재사용성을 높이기 위한 CTE, PK SEQUENCE 등 여러 기능이 존재하지 않는다. 그렇기 때문에 복잡도가 높은 쿼리가 필요한 서비스에서는 적합하지 않다. 가벼운 서버를 지향하는 MySQL 답게 쓰레드 기반으로 동작한다. 그러므로 간단한 쿼리에 대한 컨텍스트 스위칭이 빠르다.
Postgresql
RDBMS의 전문적인 기능과 확장성을 강조하는 철학을 가지고 나온 RDBMS이다. RDBMS는 테이블, 행, 열의 정보를 구조화하고 테이블 간 관계를 모델링하여 데이터베이스를 관리하는 시스템을 의미한다. 하나의 복잡한 쿼리를 수행하기 위해 스레드보다는 프로세스가 적합하다.
이유는 스레드와 프로세스의 차이점을 이해하면 왜 그런지 이해가 가능할 것이다. 저번에 공부한 실행계획을 살펴보면 'Gather Merge'라는 실행계획이 있었는데, 병렬로 처리된다는 의미다. MySQL은 쿼리가 단일 스레드로 진행되지만, Postgresql는 프로세스 기반으로 동작하므로, 자식 스레드를 생성하여 병렬처리가 가능한 것이다. 그래서 대용량 데이터, JOIN 등 여러 쿼리에서 더욱 이점이 있다.
결론.
복잡한 쿼리, 대용량 데이터를 처리할 경우가 있다면 Postgresql이 적합하고, 스타트업 등의 비용 절감이 중요한 기업에서는 MySQL을 사용하는 것이 적합하다고 생각한다.
*프로세스, 스레드 차이점
https://technote-mezza.tistory.com/68
[ Memory archtecture ]
Postgresql은 oracle과 같은 프로세스 기반의 RDBMS이고 비슷한 메모리 아키텍처를 가지고 있어, 오라클 인강 듣는 겸 postgresql의 메모리 아키텍처를 정리하려고한다.
다음은 postgresql의 메모리 아키텍처를 나타낸다.
위 그림을 처음 보면 뭐가 뭔지 하나도 모를 것이다.
Postgresql이 구동중인 서버를 들어가서 ps -ef | grep postgres를 실행하면 나오는 postgresql 관련 프로세스다.
PID와 PPID를 보아 3585592 프로세스가 postmaster 프로세스임을 알 수 있다. config파일을 읽어들여 실행되는 것을 볼 수 있다.
postmaster 프로세스는 다음과 같은 역할을 한다.
- postmaster 프로세스는 PostgreSQL 서버를 시작하고 관리하는 프로세스
- 데이터베이스 클러스터의 마스터 프로세스로서 동작하며, 클라이언트 요청을 받아들이고 백그라운드에서 실행되는 여러 프로세스를 생성하고 관리
- postmaster 프로세스는 클라이언트와의 네트워크 연결을 처리하고, 백엔드 프로세스를 생성하여 각각의 요청을 처리
- 데이터베이스 클러스터의 메타데이터와 구성 정보를 유지 관리하며, 백업 및 복구 작업, 로그 기록 등의 관리 작업도 수행
postgresql 서버에 클라이언트가 하나씩 생성되면
다음과 같은 백앤드 프로세스가 하나씩 생성된다. PPID는 postmaster 프로세스가 된다.
백앤드 프로세스는 다음과 같은 역할을 수행한다.
- backend 프로세스는 postmaster 프로세스에 의해 생성되고 관리되는 작업 단위
- 클라이언트의 요청을 처리하고 결과를 반환
- 각 클라이언트 연결에 대해 독립적으로 실행되며, 병렬로 다수의 백엔드 프로세스가 동시에 실행될 수 있음
- SQL 쿼리 처리, 트랜잭션 관리, 데이터베이스 객체의 작업 수행 등의 역할을 담당
- 각각의 backend 프로세스는 자체적으로 메모리 및 CPU를 할당 받으며, 동시 다중 사용자 요청을 처리하는데 사용되고, backend 프로세스는 요청이 완료되면 결과를 클라이언트에게 반환하고 종료됨
위 2가지 프로세스와 다른 백그라운드에서 계속해서 작업을 하는 백그라운드 프로세스가 존재한다.
각 오브젝트마다 하나의 프로세스가 할당되고, PPID는 postmaster 프로세스가 된다.
TimescaleDB 관련 프로세스는 postgresql의 확장 모듈이므로 해당 포스트에서는 생략한다.
1. Autovacuum launcher
- Autovacuum 프로세스는 테이블과 인덱스의 자동 VACUUM 및 ANALYZE 작업을 수행
- VACUUM은 공간 회수 및 중복된 행 제거를 통해 데이터베이스 내부의 불필요한 공간을 정리
- ANALYZE는 통계 정보를 수집하여 쿼리 실행 계획의 최적화에 활용
- Autovacuum 프로세스는 사용자가 직접 VACUUM 명령을 실행하지 않아도 자동으로 실행되어 데이터베이스의 성능을 유지
* VACUUM : 자바의 GC와 같은 역할을 수행. 임계치 이상으로 발생한 Dead Tuple을 정리하여 FSM (Free Space Map) 으로 반환
2. Background Writer
- Background Writer 프로세스는 디스크로부터 데이터를 읽거나 데이터를 디스크에 기록
- PostgreSQL은 변경된 데이터를 메모리 캐시인 공유 버퍼(Shared Buffer)에 기록하고, 나중에 디스크에 동기화
- Background Writer는 변경된 데이터를 주기적으로 디스크에 플러시하여 데이터베이스의 일관성과 내구성을 보장함
3. WAL Writer 프로세스
- Write Ahead Log (WAL) Writer 프로세스는 트랜잭션 로그인 WAL 파일에 데이터 변경 작업을 기록함
- WAL은 데이터 변경 작업을 로그로 기록하여 데이터베이스의 복구와 장애 복구 기능을 지원
- WAL Writer는 WAL 버퍼를 주기적으로 디스크에 플러시하여 로그의 지속적인 기록을 보장
4. Checkpointer 프로세스
- Checkpointer 프로세스는 데이터베이스의 일관성과 성능을 개선하기 위해 백그라운드에서 실행되는 프로세스
- Checkpointer는 변경된 데이터를 디스크에 플러시하고, 체크포인트를 수행하여 데이터베이스의 상태를 안정화함
- 체크포인트는 WAL 로그를 검사하여 변경된 데이터가 모두 디스크에 반영되었음을 확인하고 로그 파일을 정리함
5. Stats Collector
- stats collector는 PostgreSQL의 백그라운드 프로세스로, 데이터베이스 시스템의 활동과 성능에 대한 통계 정보를 수집하고 관리
- 삽입, 갱신, 삭제된 튜플의 수, 인덱스 사용 정보, 버퍼 캐시 히트 비율 등과 같은 데이터를 수집
- 통계 데이터는 현재 데이터베이스의 상태에 기반하여 쿼리 옵티마이저가 효율적인 실행 계획을 생성하는데 사용됨
- stats collector는 수집한 데이터를 시스템 카탈로그 테이블에 저장하며, 통계 정보를 검색하기 위해 pg_stat 뷰를 통해 쿼리할 수 있음
6. Logical Replication Launcher
- logical replication launcher는 PostgreSQL에서 논리적 복제를 관리하고 조정하는 역할을 담당
- 논리적 복제는 한 데이터베이스에서 다른 데이터베이스로 특정 테이블이나 데이터 하위 집합을 선택적으로 복제하는 기능을 제공
- logical replication launcher 프로세스는 지속적으로 복제 구성을 모니터링하고 복제 워커를 조정
- 새로운 복제 슬롯이 생성되거나 복제 구성에 변경이 발생하면, 런처 프로세스는 필요한 복제 워커 프로세스를 생성
- 복제 워커는 복제 소스의 Write-Ahead Log (WAL)에서 변경 내용을 읽고 논리적 복제 슬롯을 사용하여 이를 복제 대상 데이터베이스에 적용함
참고자료
https://www.slideshare.net/pgday_seoul/mvcc-in-postgre
https://www.integrate.io/ko/blog/postgresql-vs-mysql-the-critical-differences-ko/
'데이터베이스' 카테고리의 다른 글
데이터베이스 sequential, scattered (0) | 2023.06.08 |
---|---|
postgresql mvcc (0) | 2023.05.20 |
데이터베이스 실행 계획, 옵티마이저와 쿼리 최적화 실습 ( feat. mantech ) (1) | 2023.05.04 |
Delete vs Truncate (0) | 2023.04.26 |
postgresql's sequence obejct (0) | 2023.03.28 |