Greenplum - Data manipulations

- Data manipulations

INSERT, UPDATE 등 테이블의 데이터를 조작하는 것은 일반적인 DBMS와 유사하다. 다만 GP v4에만 분산키와 파티션키가 업데이트 되지 않는 제한이 있다.
GP의 transaction은 BEGIN (혹은 START)로 시작되고, END (혹은 COMMIT)으로 commit된다. psql에서 transaction이 Autocommit되기 때문에, 유효한 구문은 자동적으로 commit된다.
기본적인 OLTP DBMS는 테이블을 실수로 DROP하게 되면 어딘가 DROP되기 전으로 돌릴 수 있는 기능이 있는데, OLAP DBMS인 GP는 그런 기능이 없다고 한다. 예전에 프로젝트에서 실수로 날라간 데이터들을 동료가 살린 기억이 있는데, 어떻게 한 것일까?
조금 더 찾아보니, DROP은 아예 파일 시스템에서 삭제가 되지만 DELETE된 데이터는 살릴 수 있다고 한다 (참고: https://stackoverflow.com/questions/28293769/rollback-data-of-a-table-deleted-in-greenplum). Daily로 DBMS를 Backup하는 작업을 꼭 해야 겠다.
SQL Commands에 따른 Lock Mode가 있다. 다음은 SQL Commands - Lock Mode를 정리한 것이다.

1. SELECT - ACCESS SHARE
2. INSERT, COPY - ROW EXCLUSIVE
3. VACUUM, ANALYZE - SHARE UPDATE EXCLUSIVE
4. CREATE INDEX - EXCLUSIVE
5. DELETE, UPDATE - EXCLUSIVE
6. ALTER/DROP/TRUNCATE/REINDEX/CLUSTER/VACUUM FULL TABLE - ACCESS EXCLUSIVE

(각 Lock Mode에 대한 좋은 글은 https://www.postgresql.org/docs/9.4/explicit-locking.html와 http://www.dbguide.net/db.db?cmd=view&boardUid=148215&boardConfigUid=9&boardIdx=138&boardStep=1를 참조)

- Workload management와 System Design

Resource queue과 Resource group.
DB에 쿼리를 실행할 수 있는 Resource queue가 각 사용자에게 부여할 수 있다. DBA는 Resource queue에 주어질 최대 COST(자원), 최소 COST, 우선순위 등을 설정하고, 이를 계정에 연결할 수 있다. 또 이를 real time으로 우선순위 변경할 수 있다.
GP 5 이상부터 Resource group이라는 것이 생겼다. 다만 OS가 Redhat 7 버전 이상부터 동작이 가능하고, OS의 cgroup를 활용하기 때문에 OS Level의 설정이 필요하다.
Resource group은 CPU_RATE_LIMIT과 MEMORY_LIMIT 등을 설정할 수 있는데, Resource queue보다 Resource 배분 측면에서 훨씬 효율적으로 동작한다고 한다.
DISTRIBUTED RANDOMLY. GP DB에서 random algorithm을 써서 각 Segment마다 동등하게 데이터를 분배한다고 한다. 이런 경우 대부분 join이 될 때 Broadcast 혹은 Redistribution motion이 발생한다.
PARTITIONING.은 하면 좋다. 다만 파티션이 많아지면 object 개수가 많아지게 되는데, 데이터 양이 작은데 partitioning을 잘게 하면 오히려 오버헤드가 발생한다.

- Query Performance Analysis

EXPLAIN <query>를 실행하게 되면 query의 예상 plan, EXPLAIN ANALYZE <query>를 실행하게 되면 query가 실제로 실행되고 어떻게 실행되었는지 보여준다.
쿼리 플랜에서 Gather Motion은 Master로 데이터들이 모아지는 것인데, 이 부분이 MPP의 특별한 점이다. 쿼리 플랜을 보게 되면 복잡하게 플랜이 나오는데, COST와 ROWS, WIDTH를 참고해서 어떤 부분을 고쳐야 하는지 파악할 수 있다.
쿼리 플랜을 만드는 optimizer는 legacy optimizer가 있고, ORCA라는 optimizer가 있다. 사용되는 optimizer를 보려면 show optimizer; Set optimizer = off로 설정하면 legacy optimizer가 사용된다.
Hash Join은 Join되는 key를 Hashing해서, 같은 Hash 결과인 데이터들만 Join하는 방식이다. 성능이 굉장히 좋지만 자원을 많이 쓴다. Nested Loop Join은 Nested Loop으로 Join하는 방식이다. Join되는 컬럼으로 Indexing이 되어 있다면 성능이 나쁘지 않다. Merge Join은 두 테이블을 Full Scan하고 Join되는 컬럼으로 ordering한 후에, Merge하는 방식이다. 
EXPLAIN ANALYZER한 결과를 긁어서, 다음 사이트에 넣고 Submit하면 이쁘게 보여준다. (https://planchecker.cfapps.io/)