if kakao 2021 - PostgreSQL ecosystem

https://if.kakao.com/session/59

if(kakao)2021

 

PostgreSQL EcoSystem

1996년 오픈소스 프로젝트로 오픈됨. 현재까지도 1년에 한 번은 메이저 버전이 오픈됨.

• Extension: 다양하고 실험적인 기능을 패키지 형태로 제공하는 기능.
  • 예시: 데이터 암호화 기능 (pg), pivot table 쿼리를 쉽게 구현할 수 있는 tablefunc.

FDW : Foreign Data Wrapper

• 원격지의 데이터를 로컬 table처럼 사용할 수 있게 해주는 extension.
• 원격 데이터 + 로컬 데이터 join이나 DML 실행이 가능함.

데이터 처리 로직을 보다 간단히 구현할 수 있음.

Orafce : 오라클과 postgres의 호환성 제공

쿼리나 비즈니스 로직 수정을 최소화한 채 이관할 수 있음.

쿼리 모니터링에 필수적인 extensions; pg_stat_statements, auto_explain

Citus

• 데이터를 여러 노드에 분산저장 + scale out을 가능하게 해 주는 Extension.
  • 데이터가 위치한 노드에 Query 수행 + 결과값을 리턴받는 Coordinator
  • 데이터가 저장되어 있는 복수의 node.

사용자가 Coordinator DB에 Query요청할 경우

1. metadata 참조해서 데이터가 참조된 노드 확인
2. 분산환경에 최적화된 Query 작성 + 해당 노드에 실행 후 값을 받아온다.

이런 Shard 기능을 활용하면 '동일한 묶음의 데이터를 격리해서 저장하는' Multi-tenant DB로도 사용이 가능함.

 

ex) 오픈마켓을 예시로 들면, 모든 데이터는 mall_id 별로 저장. 따라서 조회할 때 mall_id 조건이 붙게 됨.

• mall_id 기준으로 분산저장 -> 같은 Mall_id 조회는 하나의 노드에 저장.
• 단일 인스턴스로는 구성이 어려운 대용량 데이터도 하나의 클러스터로 구성 가능.

 

필요한 데이터를 여러 노드에 분산 + 병렬처리로 빠른 연산을 실행할 수 있음.

• 데이터 실시간 분석용으로 활용 가능.
• 노드별로 하나의 테이블. 데이터 조회 n개의 노드 서버에서 동시에 실행하므로 병렬처리 효과가 있음.

 

카카오에서는 DB 이중화를 기본 적용. master / standby 두 개가 존재하며, 마스터에 장애 발생 시 standby 서버가 투입되는 구조.

• 백업 / 복구 모니터링은 별도로 존재. 운영노하우도 필요

Citus를 사용할 경우 postgres 운영방식을 그대로 사용하면서 sharding 기능을 사용할 수 있다는 장점.

구성법

1. Coordinator / node로 사용할 DB를 이중화 세팅으로 각각 설치, Citus 설치.
2. Coordinator에서 Node DB 설정해주면 됨.

Citus에서 사용하는 table 종류는 세 가지. Distributed Table / Reference Table / Local Table

• Distributed : distributed column 기준으로 N개의 shard로 나누어 각 노드에 분산저장.
• create_distributed_table(<table이름>, ) 명령어로 생성 가능.
• 분산 병렬처리용이라면 하나의 Node core 1개당 최소 하나의 Table이 설정되도록.
  • ex) 16core 노드 3대 -> 테이블 Shard 수는 48로 설정시 최대 병렬처리 효과.

• Reference : Access가 잦은 테이블의 경우 모든 노드에 공통으로 저장되도록 세팅.
  • 사이즈가 작고, 여러 테이블에 JOIN으로 자주 쓰이는 경우 적용

 

• Local : Coordinate DB에 직접 저장되는 일반 Postgres 테이블.
• 노드에 쿼리를 실행하지 않고 Coordinator에서 바로 조회가 가능함.

TimescaleDB

 

• HyperTable chunk: 특정 시간대별로 데이터를 묶은 것을 말함. Chunk는 실제 데이터가 저장되는 TABLE이 된다.
• 개념적으로는 Partition table == hypertable, 각 파티션이 하나의 Chunk를 의미한다고 보면 됨.

 

• create_hypertable(<table명>, <chunk로 쪼갤 기준이 되는 Colunm>)

 

• 일반적인 시계열DB는 독자직인 인터페이스 / Query Language가 있는 편인데, timescaleDB는 Postgres Extension이므로 sql문 지원.
• 복잡한 Join과 같은 sql 특성 + timescale 분석함수 사용 가능.
• 시계열 데이터와 일반 데이터를 하나의 DB로 운영할 수 있음.
• postgres 운영하고 있다면, 운영에 추가 부담이 덜한 편.

 

Scale out 가능한 다중노드로 구성가능.

• create_distributed_hyptertable(<테이블명>, <timescale chunk 기준이 될 column>, <각 노드에 배치할 기준 column>)
• access node를 통해 분산노드에 접근할 수 있음.

cf. 노드 확장에 필요한 데이터 Rebalancing / 특정 노드의 Chunk를 다른 노드로 이동시키는 기능은 아직 구현되지 않음.

 

시계열 데이터 저장 시 파티션 테이블을 많이 사용하는 편.

• 특정 시간 단위로 partiton 생성 + 일정 시간이 지난 partition 삭제 기능을 batch로 추가해야 했음
• timescale DB는 chunk 단위로 데이터가 분할되며, 보관기간 정책 설정만 해주면 자동삭제해줌.

 

시간이 지나며 계속 쌓이는 데이터 -> 압축 기능이 지원됨. 90% 이상의 압축률 지원.

• row 개수를 줄이기 위해, column별로 값을 배열로 압축함.
• 특정 Key값 조회 시, 해당 key에 해당하는 row만 압축 해제하면 되므로 성능이 빠른 편.

보통 최근 데이터를 조회할 경우 -> 압축되지 않은 row 기반의 데이터 조회가 많음

 

오래된 데이터 조회 시 -> 특정 Colunm의 정보를 확인할 때가 많음. 따라서 column 기반의 압축 방식이 유용함

 

기타: 카카오에서 사용하고 있는, 공간데이터 저장용 postgres Extension "Postgis"