# Postgres: A Proven Track Record
---------------------------
1. Postgres
- VS mysql
- 라이센스 정책 이슈 가 없어 사용하기 좋다
- Versioning
- 9.0 streaming 지원
- 9.5 parelle scan (table) ... 지원
- version up 됨에 따라 기능, 파라미터의 삭제 case 도 있다
- 제품군
- Postgres (community ver)
- EDB Postgres Advanced Server (enterprise ver)
- hint ? 가 있다
- Postgres Plus Cloud (enterprise ver)
2. physical database 구조
- cluster == DB (최근 일반화된 cluster 의 정의와는 다르다)
- 포터블 하다
- 각 database 는 하나의 폴더 구조를 가진다 == /install-path/9.5AS/data/
- pg_tblspc : 각각의 tablespace 에 각각의 관계가 저장된다
- base :
- 각각의 table 이나 index 의 경우 각각 다른 파일로 저장된다 (OID 숫자 파일로 생성)
- OID 숫자는 pg_class.relfilenode 에서 찾을 수 있다
- 하나의 파일은 최대 1GB
- page structure
- tuple 8 kb , 조정 불가
- toast 라는 메커니즘을 통해 8 kb 이상의 가변 길이 데이터를 따로 저장한다
4. process
- multi process 구조 이다 (최근 많이 사용하는 multi thread 구조, 비동기 구조 와는 다르다)
- 클라이언트에서 pool 로 관리하여 DB 에 접속하기 때문에 변경할 필요는 없다
- 각자 판단하여 각자 업무를 한다 == utility process 가 별로로 존재
- 클라이언트 의 응답용 backend process 가 있다
- Postmaster
- listener 가 네트워크 서버 역할, 자식 process 를 만든다
- 하나의 master process 만 생성하기 때문에 port 도 하나만 사용한다
- Postgres == Server Process == backend process
- postmaster 에 의해 생성되며 client 의 요청을 수행하는 프로세스
- 데이터의 입출력을 담당한다
- Utility process
- background writer : write dirty data to disk
- WAL writer : write WAL file to disk
- checkpoint process
- ...
5. DB I/O 의 특징
- DB 의 모든 데이터의 접근은 server process 가 memory 를 통한다
- DB 의 성능을 좌우한다
- read path
- step1. memory 영역 조회
- step2. 없으면 memory 할당을 받음
- step3. 직접 Disk 를 조회
- step4. memory write
- step5. client 에 전달
- write path
- step1. buffer cache 조회
- step2. memory 확보
- step3. 변경내용 log buffer (WAL buffer)에 기록
- step4. memory 데이터 변경 > transaction log 기록 (utility process 중 background writer)
- -------------- write 보장 / commit --------------
- step5. DB File 에 완전히 기록 된 것을 확인 (utility process 중 WAL writer)
- commit && check point
- before commit : data in memory
- after commit : data in transaction log
- after check point : data in data file
6. transaction log == WAL log
- 순차적으로 변경사항을 기록 (DB file 에 직접 쓰는 것보다 성능적으로 우수하다)
- commit 완료되기 전에 DB file 에 기록
- long transaction 의 경우 commit 되기 전에 주기적으로 기록
- archive log 폴더로 별도의 백업이 이루어진다
7. check point : DB 의 성능을 좌우한다
- 동작
- step1. WAL 파일에 REDO point 를 지정
- step2. 지정된 시점의 WAL 파일을 buffer 에 기록
- step3. pg_control 파일 업데이트
- step4. 공유 버퍼 풀에 있는 모든 dirty page 를 스토리지에 기록 후 플러시
- 주기 조절이 중요하다
- 빈번한 수행 :
+ 장애 복구 시 신속한 복구 가능
- disk I/O 가 많아져 성능 저하 이슈
- 긴 주기 수행 :
+ disk I/O 가 적어 성능 좋음
- 장애시, 복구할 WAL file 이 많아져 이슈가 될 수 있음
- 역할 :
- 주기적으로 biffer cache 의 변경된 block(dirty buffer) 를 file 에 기록
- 모든 변경 내용이 기록된 transaction log 파일을 release 하여 해당파일 삭제
- 버전 관리
- a > a1 : wal log 에 기록 후 buffer memory 기록
- if 장애 발생시, disk 에 블록 header 부분에 변경사항을 기록한다 , wal log 의 변경사항 비교
참고 https://www.postgresql.org/docs/
'Database > postgreSQL' 카테고리의 다른 글
| postgreSQL 설치 (0) | 2016.08.25 |
|---|---|
| postgreSQL 주요 기능 (0) | 2016.08.25 |
