감각적신사 의 멱살잡고 IT

# Postgres Installation

-----------------

[참고](https://www.postgresql.org/download/)

1. Prerequirement

    - OS : linux / windows 64bit

    - admin 계정으로 설치 / SELinux permission (permissive mode)

    - locale 정보

- 지역별 문자열에 대한 ordering 이슈가 있을 수 있다. 이를 관리한다 (default 로 쓴다)

2. installation

    - [download](https://www.postgresql.org/download/)

    - 설치 경로

    - 추가 설치 컴포넌트

    - 커넥터스 == driver

    - infinite cache

    - Migration Toolkit : oracle 데이터 importer / exporter

    - PEM : GUI tool (end user 입장에서는 pg_admin 과 동일) (중앙관리적 입장의 기능 추가) _

    - ...

    - data 경로 , WAL 경로

    - 추가 layer (Compatable with Oracle): oracle 명령어를 동작할 수 있게끔 지원 하는 기능 enable/disable

    - user / password 설정

    - port (default 5444)

    - Dynatune 

- Server Utilization

- 개발

- 범용 (default)

- 전용

- Workload Profile

- 트랜잭션 (default) : OLTP systems

- 범용 : OLTP and reporting workloads

- 보고 : 복잡한 쿼리 or OLAP workloads

    - ...

    - StackBuilder run or not

3. post installation

    - 권한변경 : installation Path

    - pgplus_env.sh 확인

4. pg_ctl 명령어

- 명령어 호출 예제

5. psql

- \? : command 명령어

- \x : 컬럼을 열로 보여줌

- \d+ : 상세정보 출력

- \help : sql 문

- psqlrc 파일 생성시, psql client 실행을 할때 선 수행된다

6. admin tool

        - query에 대한 limit default 값이 없어 툴이 죽을 수 있다 

        - paging 처리가 반드시 필요함

# postgreSQL 주요 기능

------------------

0. Transaction Isolation 개념

- session1 : read A > update A to A1

- session2 : read A > ...................... > read A

- session2 가 읽은 A 는 A 일까 A1 일까?

- **3가지 상황 을 처리하기 위한 isolation level**

- dirty reads : session2 가 session1 이 commit 하기 전부터 A1 를 읽어옴

- nonrepeatable reads : session2 가 session1 이 commit 해도 기존에 읽은 A 가 있다면 A 를 읽어옴

- phantom reads : session2 가 session1 이 A 데이터를 변경하지 못한다 (shared lock 적용)

  - oracle 도 default 로 read commited level 을 지원한다

    - [참고URL](https://support.microsoft.com/ko-kr/kb/601430)

    - 추가 : oracle transaction 은 statement 단위로 롤백이 되지만, postgreSQL 은 transaction 전체가 롤백 된다

1. MVCC (Multi Version Concurrency Control)

- 만약 하나의 record 에 대해 각각의 세션이 데이터 변경, 삭제 등의 동작을 했다면, 세션1(A), 세션2(A'), 세션3(A'') 는 존재해야 한다

- oracle 방식 (우월한 방식이다)

- 세션1 이 select 중 세션2가 업데이트할 시,

- A 를 다른 공간(undo)에 업데이트 하고 A' 를 원본 데이터로 저장한다

- 세션1에게는 다른 공간의 A를 읽어온다

- undo 영역에 대한 가비지 컬랙터가 존재하며, 부담이 없다

- 대신 rollback 이 느리다

    - postgreSQL 방식

    - 세션1 이 select 중 세션2가 업데이트할 시,

- A' 를 같은 테이블에 저장 append 한다

- 세션1에게는 A' 의 데이터 입력 시간 을 확인하고 skip 한다

- 각 레코드 마다 트랜잭션에 대한 created, expired 컬럼을 가지게 된다

- xmin , xmax : transaction 의 시작,끝

- cmin , cmax : transcation 내의 query 에 매겨지는 순서

- 각 레코드에 불필요한 overhead(각각 32bit)가 발생하게 된다

- 2 ~ 40억 의 값이 부여된다

- 현재 트랜잭션 ID 를 기준으로 +20억 까지는 미래, -20억 까지는 과거

- 그림

- transaction 관리 table 을 두고, transaction 의 상태 (commit, rollback, progress ...) 를 관리한다

- A 를 지우기 위한 가비지 컬랙터가 필요하다, 원본 테이블에 대한 컬랙터의 동작으로 어렵다

- OID 

- table 생성시, with OID 옵션을 추가하면 생긴다

- OID 를 별로도 저장하지 않는다?

- 내부 관리용으로 사용된다

2. Vacuuming

- 쓰레기 데이터를 정리하여 쾌적하게 청소하라는 명령 으로 "디스크 조각 모음" 이라고 생각하면 된다

- Update나 Delete 한다고 해서 해당영역이 자동으로 재사용되거나 사라지지 않고 이러한 오래된 영역을 재사용하거나 정리해주는 명령어가 Vacuum 이다

- postgresql.conf 파일내의 AUTOVACUUM PARAMETERS 관련 옵션을 지정

- default on : 오프시키면 안된다

- table 단위로 on/off 가 가능하다

- log_autovaccum_min_duration (default -1) : 

- freeze_max_age : 2억번 이상의 transaction 이 발생했을 때

- max_wokers (default 3) : 

- naptime (default 1 min) : worker 가 계속 일하는 것이 아니라 쉬는 시간을 갖는다

- threshold : 50 개가 변경이 되면 vacuum 해라

- analyze : 통계 정보가 변경되는 간격

    - http://blog.gaerae.com/2015/09/postgresql-vacuum-fsm.html

3. reindexing

    - 작업 소요 시간의 요인

- indexes 의 수

- indexes 의 크기

- 동작 중의 서버 load

    - reindexing 하는 이유

    - index 가 "bloated" 상태가 되었을때 == 많이 비어있거나 거의 비어있는 상태 일때

    - 대체할 fillfactor 와 같은 parameter 가 존재할 때

   - CONCURRENTLY 옵션이 실패하여 "invalid" index 로 남겨졌을 때

4. clustering

- clustering 하면 지정된 index 에 의해 순서대로 정렬한다 (하는 중에는 table lock 이 걸린다)

- 반복적으로 적용되어 처리해주는 것이 아니라 명령 실행 이후 데이터는 무정렬 상태로 출력된다

5. backup

- logical backup

- partial backup and recovery (table 단위)

- can validate all data files

- logical backup 의 방법 : sql commands 를 통해

            - pg_dump 유틸리티 를 통해 다양한 포멧의 형태로 백업이 가능하다

                - 주요 사용옵션 : -Fp, -Fd (테이블별 병렬처리로 덤프), -Fc

            - pg_dumall 유틸리티 를 통해 클러스터 전체에 대한 백업을 받는다, 자주 사용하지 않는 기능이다

            - pg_restore 유틸리티 를 통해 복구가 가능하다

    - physical backup

    - 디렉토리 구조 전체의 데이터 파일을 통째로 복사한다

    - type

    - Cold backup : db 멈춘상태에서 백업

    - Continuous Archiving == Pointing In Time Recovery (PITR):

    - checkpoint 가 발생하기 전에 transaction log 를 모아두는 archive log 공간으로 복사

    - 추가적인 WAL log 나 transaction log 를 적용하여 시점 이후의 데이터를 복원 가능하다

    - setting

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