감각적신사 의 멱살잡고 IT

# 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/