AWS PostgreSQL(RDS · Aurora)에 분석계 붙이기
Amazon RDS와 Aurora PostgreSQL에서 논리 복제(rds.logical_replication)를 켜고 publication을 만듭니다. GritDB가 이를 구독해 변경을 받고, 받은 데이터는 분석 세션에서 조회합니다.
이중 엔진 데이터베이스 · PostgreSQL 호환
리포트는 빠르게,
운영 DB는 가볍게
GritDB는 PostgreSQL 엔진에 열 기반 분석 엔진을 더한 이중 엔진 데이터베이스입니다. 운영 DB의 변경을 받아, 무거운 리포트를 운영 DB 대신 실행합니다.
- 운영 DB는 복제나 CDC · ETL 연결만, 업무 프로그램은 그대로
- 리포트 · BI 도구는 PostgreSQL 드라이버로 접속
- 사내 서버(온프레미스)와 클라우드에 모두 설치
금융 고객 검증기존 PostgreSQL에서 20만 건에 229초 걸리던 리포트 질의를, 50배인 1,000만 건에서 8.8초에 처리사례 보기
이런 고민이 있다면
리포트가 운영 DB를 느리게 합니다
집계 쿼리와 리포트 쿼리가 업무 쿼리와 같은 데이터베이스에서 실행되어, 업무 처리가 느려지거나 멈춥니다.
분석하려면 ETL 파이프라인부터 만들어야 합니다
운영 DB의 데이터를 꺼내고 바꿔서 옮기는 ETL 파이프라인이 따로 필요합니다. 이 파이프라인을 만들고 고쳐 가는 데 인력과 비용이 듭니다.
분석 때문에 데이터를 옮기거나 한 클라우드에 묶입니다
클라우드 분석 서비스는 데이터를 그 서비스로 옮겨야 하고, 옮긴 뒤에는 다른 곳으로 바꾸기 어렵습니다. 개인신용정보처럼 회사 밖으로 내보낼 수 없는 데이터는 아예 쓰기 어렵습니다.
GritDB는 이렇게 풉니다
운영 DB는 그대로
분석계는 운영 DB 옆에 두는 GritDB 서버 한 대입니다. 운영 DB의 실행 파일과 데이터, 업무 프로그램은 그대로 둡니다. 운영 DB가 PostgreSQL이면 ETL 파이프라인을 따로 만들지 않고 내장 복제를 설정합니다. 복제 설정을 바꿔야 하면 운영 DB를 한 번 재시작해야 합니다. 다른 데이터베이스면 PostgreSQL을 대상으로 쓰는 CDC · ETL 도구로 변경을 보냅니다. 쓰던 도구가 있으면 대상만 GritDB로 바꿉니다. 리포트 · BI 도구는 분석계에 접속하고, 접속 옵션으로 분석 세션을 켭니다.
온프레미스도, 클라우드도
GritDB는 고객이 고른 서버에 설치합니다. 사내 서버(온프레미스)에도, Amazon EC2 같은 클라우드 가상 서버에도 같은 설치 파일을 쓰므로 특정 클라우드에 묶이지 않습니다. 인터넷이 없는 망에서는 반입한 설치 파일과 OS 패키지로 설치합니다.
대량 집계는 분석 엔진으로
등록한 테이블의 변경은 열 기반 파일로 저장됩니다. 분석 세션의 조회는 분석 엔진(GritDB 엔진)이 필요한 열만 읽고, 파일 단위로 나눠 여러 CPU 코어에서 실행합니다.
분석계로 붙일 때 운영 DB에 생기는 일은 설정할 때, 평소, 분석계가 멈췄을 때로 나눠 아키텍처에 정리했습니다.
트랜잭션은 행으로, 분석은 열로
응용 프로그램 쓰기 · 업무 조회
리포트 · BI 도구 집계 · 리포트 조회
GritDB
PostgreSQL 드라이버 · SQL로 접속
일반 세션
분석 세션
트랜잭션 엔진 PostgreSQL 엔진 행 저장
변경 PLUG가 이어받기
분석 엔진 GritDB 엔진 · 열 기반 파일
PLUG UNIFY BURST
트랜잭션 엔진은 PostgreSQL 엔진입니다. 그래서 응용 프로그램과 BI 도구는 쓰던 PostgreSQL 드라이버와 SQL로 GritDB에 접속합니다. PostgreSQL을 대상으로 쓰는 CDC · ETL 도구도 GritDB에 그대로 쓸 수 있습니다. 분석 세션의 조회, 즉 등록 테이블만 읽는 조회는 분석 엔진이 실행합니다. 쓰기와 그 밖의 쿼리는 트랜잭션 엔진이 처리합니다. 자세한 조건은 아키텍처의 쿼리 경로에 있습니다. 1.1에서는 GritDB를 운영 DB 옆에 분석계로 붙이는 방식을 권합니다. 업무 프로그램은 지금처럼 운영 DB에 접속합니다. 자세한 내용은 아키텍처의 도입 방식에 있습니다.
시연 영상
Oracle®에서 CDC 도구로 GritDB에 동기화
Oracle에 TPC-H 데이터(SF10, 8개 테이블 8,658만 행)를 넣고, CDC 도구로 GritDB에 동기화합니다.
시연 환경 보기시연 환경 접기
영상은 누르면 YouTube 플레이어로 열립니다.
Amazon RDS · Amazon Aurora · Amazon EC2는 Amazon.com, Inc. 또는 그 계열사의 상표이고, Oracle은 Oracle 및 그 계열사의 등록 상표이며, TPC-H는 Transaction Processing Performance Council의 상표입니다.
이런 곳에 맞습니다
금융
보험사, 카드사, 증권사의 정산과 실적 분석, 마감 뒤 원장 집계, 감사 대응 조회에 맞습니다. 회사 밖으로 내보낼 수 없는 데이터를 사내 분석계에서 분석할 수 있습니다.
공공
PostgreSQL로 전환한 기관은 내장 복제로, 다른 데이터베이스를 쓰는 기관은 CDC · ETL 도구로 분석계를 붙일 수 있습니다. 인터넷이 없는 망에도 설치할 수 있습니다.
기업 · SaaS
PostgreSQL을 쓰는 서비스는 ETL 파이프라인 대신 내장 복제로 분석계를 붙여, 리포트 부하를 운영 DB에서 분석계로 옮길 수 있습니다.
도입 순서
- 1
사전 상담
느린 리포트 몇 개를 고객 DBA와 같이 보고 GritDB가 맞는지 판단합니다. PoC의 범위와 기간, 비용도 정합니다.
- 2
PoC
고객 데이터와 리포트로 시험합니다. PoC는 유상이고, 구독하시면 PoC 비용은 첫해 구독료에서 차감합니다. 평가용 사용권은 최대 90일입니다.
- 3
계약
Datagrit이 Unit 수를 같이 계산하고 견적을 드립니다. 주문서와 사용권 약관에 서명합니다.
- 4
설치 · 운영
설치는 직접 하시거나 맡기실 수 있습니다. 구독은 1년마다 갱신합니다.
견적, 계약, 설치 파일 받기, 갱신까지 구매 순서 전체는 구독에 있습니다.
GritDB 1.1은 분석계부터 맡습니다
분석 엔진은 분석 세션에서 등록한 테이블만 읽는 조회를 실행합니다. 이 조회는 변경을 묶어 열 기반 파일에 넣은 뒤에 읽으므로, 방금 commit한 변경은 바로 보이지 않습니다. 자체 시험에서는 보통 12초 뒤에 보였고, 100번 중 99번은 22초 안에 보였습니다. 분석계로 붙였으면 운영 DB에서 복제되는 시간이 더해집니다. 최신 값이 꼭 필요한 조회는 일반 세션에서 하고, 분석계로 붙였으면 운영 DB에서 합니다. 운영과 분석을 GritDB 하나에서 함께 처리하는 범위는 다음 버전부터 넓혀 갑니다.
금액처럼 정확해야 하는 열은 정밀도를 정한 numeric(p, s)로 만들고, p는 38 이하로 둡니다. 정밀도를 정하지 않은 numeric은 분석 엔진에서 근삿값으로 계산합니다.
두 엔진의 구성, 도입 방식, 쿼리 경로는 아키텍처에 있습니다. 이중화, 행 단위 보안(RLS), 지원하는 열 형식처럼 1.1에서 알아 둘 것은 아키텍처의 1.1에서 알아 둘 것에 모았습니다.
GritDB를 직접 확인해 보세요
사전 상담이나 PoC를 요청하시면 담당자가 연락드립니다.