# DynamoDB Table 설계

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


1. 요소

        - 프라이머리 키 선택 = 유니크 키

        - 개별 항목에 대한 작업 부하 패턴


2. 테이블 설계 시, 고려 사항

- Randomizing Across Multiple Hash Key Values

- suffix set 를 이용하여 프라이머리키를 고르게 분포되도록 한다 ( write / read 속도 향상 )

- example: 2014-07-09.1, 2014-07-09.2 ~ 2014-07-09.200

- Understand Partition Behavior

- aws 에 의해 table 이 커지면 새로운 partition 이 추가된다

- partition 크기 관련 고려사항

- 테이블 데이터 사이즈

- Provisioned Throughput

- Use Burst Capacity Sparingly

- 설정한 Throughput 만큼 사용하지 않아 남은 것을 "burst" 라 한다

- DynamoDB 는 최근 5분에 대한 "burst" 보관하여 일시적으로 더 빠른 Throughput 를 일시적으로 제공한다

- 일시적으로 사용가능할 뿐 이 값을 의존하여 설계하면 안된다

- Understand Access Patterns for Time Series Data

- Old data 를 S3 로 이동

        - Cache Popular Items

- aws 의  ElastiCache 를 이용하여 cache layer 를 구성하는 것을 권장


3. Item 설계

- Use One-to-Many Tables Instead Of Large Set Attributes

- 한 table 에 많은 column 을 만드는 것보다 여러 table 로 중복되게 저장하는 것이 좋다

- 이유

- 하나의 큰 size 를 읽는 것보다 여러 작은 size 를 읽는 것이 비용적으로 효율적인다

- 작은 데이터 가 입출력 I/O 가 더 좋다

- example

- 많은 attr 테이블

- attr 가 적은 테이블 지향



- 긴 Attribute Values 저장하는 것을 지양

- GZIP or LZO 알고리즘 사용하여 압축

- Amazon S3 에 값을 저장

- Multiple Items 으로 쪼개어 저장

- cross-item transactions 을 지원하지 않는 점을 고려하여 설계에 유의


4. Query 조건 고려사항

- Avoid Sudden Bursts of Read Activity

- Reduce Page Size : a Scan operation reads an entire page (by default, 1 MB)

- Isolate Scan Operations

- Take Advantage of Parallel Scans : "sweeper" process

- 조건

- The table size is 20 GB or larger

- Sequential Scan operations are too slow

- 그러나 비싼 과금 지불이 필요하다


5. Secondary Indexes

- 개념

- DynamoDB 는 일반적으로 primary key (hash OR hash+range) 에 대한 index 를 지원한다

- key column 을 제외한 나머지 column 으로 조건을 걸어 조회시, scan 형태로 전체 데이터를 받아온 뒤, 가공하게 된다

- 그래서 **Secondary Indexes** 가 필요하다

- 종류

- Global Secondary Indexes

- index 처리한 column 으로 새로운 table 을 생성하여, 기존 테이블과 비동기 방식으로 데이터를 맞춘다

- 별도의 테이블 이 생성된다

- Local Secondary Indexes : 

- 별도의 테이블 생성 없이 기존의 테이블에 추가적으로 작업

- 지원 옵션

- KEYS_ONLY : 가장 작은 단위의 옵션. 단일 column 을 index 로 활용한다

- INCLUDE : KEYS_ONLY 에 추가적으로 column 을 추가하여 index 로 활용한다

- ALL : 모든 column 을 index 로 활용한다

        - 별도의 Throughput 설정이 필요하다


6. 가이드 라인 in AWS

- primary 키 선택

- 통일된 작업에 사용될 키를 사용해라

- 값이 고르게 분포될 수 있는 값을 선택해라 == 특정 부분에 집중되어 있는 값을 선택할 경우, 값을 가져오기 힘들다

- 인덱스 선정 시, Take Advantage of Sparse Indexes

- 일부 컬럼에서는 가지고 있지 않은 값을 선택하는 것이 좋다 == index_table 자체를 작게 가져갈 수 있기 때문이다

- 인덱스 사용 시, Use a Global Secondary Index For Quick Lookups

- use non key 

- use key : index table 에 컬럼을 일부만 사용

- 읽기 조건 사용 : Create an Eventually Consistent Read Replica

- 자주 사용하지 않을 index 를 만들지 마라 == 파일 I/O 가 더 발생하게 된다

'Nosql > aws dynamoDB' 카테고리의 다른 글

DynamoDB 소개  (0) 2016.08.02
DynamoDB 특징  (0) 2016.08.01
Posted by 감각적신사
,

# 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 확인

 export PATH=/opt/PostgresPlus/9.5AS/bin:$PATH

  export EDBHOME=/opt/PostgresPlus/9.5AS

  export PGDATA=/opt/PostgresPlus/9.5AS/data

  export PGDATABASE=edb

  # export PGUSER=enterprisedb

  export PGPORT=5444

  export PGLOCALEDIR=/opt/PostgresPlus/9.5AS/share/locale


4. pg_ctl 명령어

  pg_ctl init[db]               [-D DATADIR] [-s] [-o "OPTIONS"]

  pg_ctl start   [-w] [-t SECS] [-D DATADIR] [-s] [-l FILENAME] [-o "OPTIONS"]

  pg_ctl stop    [-W] [-t SECS] [-D DATADIR] [-s] [-m SHUTDOWN-MODE]

  pg_ctl restart [-w] [-t SECS] [-D DATADIR] [-s] [-m SHUTDOWN-MODE] [-o "OPTIONS"]

  pg_ctl reload  [-D DATADIR] [-s]  # 설정파일만 다시 읽어온다 

  pg_ctl status  [-D DATADIR]

  pg_ctl promote [-D DATADIR] [-s]  # 서비스 이중화 구성시

  pg_ctl kill    SIGNALNAME PID

- 명령어 호출 예제

         


5. psql

- \? : command 명령어

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

- \d+ : 상세정보 출력

- \help : sql 문

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

       



6. admin tool

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

        - paging 처리가 반드시 필요함

'Database > postgreSQL' 카테고리의 다른 글

postgreSQL 주요 기능  (0) 2016.08.25
postgreSQL 소개  (0) 2016.08.24
Posted by 감각적신사
,

# 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 가 존재할 때

필펙터는 인덱스가 생성될 때 인덱스 페이지를 채우는 비율

인덱스가 처음 생성될때만 적용되고 운영중에는 유지되지 않기 때문에 데이타 수정이 잦은 DB라면 의미 없는 값이 된다

데이타 수정이 거의없는 DB라면 필펙터를 높여서 읽기 성능을 높일수 있겠지만

데이타 수정이 잦아지면 페이지 스플릿의 증가로 쓰기 성능이 나빠질수 있다

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

이 옵션은 index 생성시에 어떠한 lock 없이 동작하게끔 한다


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

  wal_level=archive

   archive_mode=on

                - 실행 : cp -i %p from_path/%f </dev/null


6. Extensions

- 다양한 plugin 을 지원한다

- 특징

- package manager 가 있다

- 표준화된 개발환경 (PGXS) 을 지원한다

- 간단한 설치 및 관리

- http://pgxn.org

- 대표적인 extension

- pgcrypto : 암호화 / 복호화 용도

- pg_buffercache : 메모리의 버퍼 상태를 모니터링 하는 용도

- pg_freespacemp : FSM 정보를 제공 하는 용도

- pageinspect : 블럭에 대한 덤프 기능

- pg_prewarm : 디스크의 내용을 메모리에 올려둔다

- pg_stat_statements : 조회한 쿼리 정보 조회 기능

- memory 공간에 대한 추가적인 설정이 필요하다

- pg_repack : 논란의 요지가 있으나 유용하다

- online 중에 clustering, vacuum full 기능을 lock 없이 사용하도록 지원


'Database > postgreSQL' 카테고리의 다른 글

postgreSQL 설치  (0) 2016.08.25
postgreSQL 소개  (0) 2016.08.24
Posted by 감각적신사
,