이 글에서는 DBMS에서 OLAP과 OLTP를 지원하기 위한 방법들 중 SAP HANA의 논문을 분석해 보겠습니다.
관련 기술을 참고하기 위해서 다음의 논문을 참고합니다.
"Parallel Replication across Formats in SAP HANA for Scaling Out Mixed OLTP/OLAP Workloads"
Table Of Contents
Parallel Replication across Formats in SAP HANA for Scaling Out Mixed OLTP/OLAP Workloads
이중화 관련 기술을 참고하기 위해서 다음의 논문을 참고합니다.
"Parallel Replication across Formats in SAP HANA for Scaling Out Mixed OLTP/OLAP Workloads"
배경
in-memory dbms는 oltp와 olap의 혼합된 형태의 워크로드를 처리할 수 있는 능력을 필요로하고 있습니다.
ETL을 이용한 OLAP의 문제점
일반적으로는 이것을 하기 위해서 ETL 툴이나 application의 배치 작업을 통해서 OLTP의 데이터를 OLAP으로 복제하는 방법을 사용합니다.
하지만, 이런 형태의 복제는 실시간 복제가 아니기 때문에 데이터의 실시간성을 반영하지 못합니다.
OLTP와 OLAP을 하나의 시스템에서 운영하는 문제점
하나의 DBMS에서 oltp와 olap을 운영하는 경우 olap의 부하가 많이 가는 질의 수행으로 인해 olap 기본 질의 성능이 떨어지는 문제가 있습니다. 그 뿐 아니라, 이 때문에 OLTP의 성능에도 영향을 줘서 OLTP/OLAP 작업에 모두 좋지 못한 영향을 줍니다.
구체적으로는 OLAP 질의를 수행하느라 버퍼가 replace되어 다른 oltp의 성능에 크게 영향을 줄 수 있습니다.
그 뿐 아니라 오래 동작하는 OLAP의 질의로 인해서 undo 영역에 무리를 줄 수도 있습니다.
문제 해결을 위한 시스템 설계 - Asynchronous Parallel Table Replication (ATR)
OLTP는 전용의 OLTP 시스템을 사용하며, OLAP은 OLTP와 다른 시스템을 이용하여 서로 간섭없이 동작할 수 있습니다. 이를 위해서 OLTP 시스템의 데이터를 OLAP 시스템에 복제합니다.
이렇게 함으로써, 장점을 가질 수 있는 것은 OLTP 시스템은 row 기반 스토리지를 사용하는 시스템을 적용할 수 있으며 OLAP 시스템의 경우 column 기반 스토리지를 사용하는 시스템을 적용할 수 있습니다.
ATR은 OLAP 시스템의 질의 성능과 확장성을 높이기 위해서 lock-free parallel log replay 구조(이 논문에서는 MVCC: multi-version concurrency control 기반)를 갖습니다.
이로써 지연시간을 최소화 하는 실시간 복제를 통해 실시간 OLAP을 지원할 수 있습니다. (real-time reporting)
ATR은 상용환경에서 갱신 집약적인 워크로드에서도 1초 미만의 지연을 달성하여 확장 가능한 실시간 OLAP 성능을 제공합니다.
전체 구조
다양한 고객 워크로드를 분석한 결과, OLTP 워크로드는 최신 서버 시스템 한 대로 충분히 처리할 수 있는 워크로드인데 반해, 무거운 OLAP 워크로드는 여러 대의 서버에서 처리해야 한다는 것을 알게 되었습니다.
목적은, OLTP 시스템에 영향을 주지 않고 OLAP 시스템으로 복제하는데 있습니다.
Application의 DB client library에서 사전 정의된 질의 처리 시간에 따른 라우팅을 지원합니다. ( 오래걸리는 OLAP read-only 쿼리를 replicas로 라우팅 )
ATR은 테이블 복제이며, 전체 데이터베이스를 복제하지 않습니다.
ATR의 목적은 OLAP 질의를 OLTP 서버로 부터 분리시키는 것입니다.
공통 설계 고려 사항
- row store와 column store간 복제 기능
- column store에서 row store로의 복제는 불필요하므로 구현하지 않음. (요구사항 없음)
- storage recovery log와 replication log의 분리
- physical 포멧의 recovery 로그로부터 row store에서 column store로 복제하는 것이 불가능함.
- DB의 모든 테이블을 복제하는 것 보다 일부 테이블만 복제하는 것이 더 효율적인 경우가 많음.
- 기본 스토리지 엔진의 변경 및 중단 최소화, 복제로그 분석시 불필요한 오버헤드 제거
- 엔진 내에 포함된 Sender와 replication log 생성기
- olap replicas의 지연 문제를 해소하기 위해서 엔진 내부에 replication log 생성기와 sender를 두었음
Primary Server
- 로그 기반의 레코드 레벨 복제 (병렬 로그 반영에 따른 잠재적인 충돌 문제 회피)
- 이중화 복제를 위해 record-level result logging
- RVID(record version ID)
- 아래 문제로 SQL Operation logging을 사용하지 않음
- non-deterministic SQL functions등에 대한 문제를 해결할 수 없음.
- SQL 실행 순서에 따른 문제가 발생할 수 있음.
- DML이 종료되자마자 전송 (not commit)
- olap replicas의 지연 문제를 해소하기 위해서 로그를 DML이 수행되자마자 전송함
Replicas
- 병렬 복제를 가능하게 함
- primary에서 다수의 cpu를 사용해서 로그를 생성하므로 replica가 병렬로 적용하지 않으면 속도를 따라가지 못함
- full Parallel log replay를 사용함
- 미리 정의된 최대 지연시간에 따른 질의 라우팅
- “select ... with result lag (x seconds)” 구문을 지원하여 replica로 라우팅함.
- commit 로그에 시간을 기록하고 replica에서 replay시 last commit 적용 시간을 기록하여 유지한다.
- 만약 "select .. with result lag(x seconds)" 보다 더 지연이 크다면 다시 primary로 질의를 re-route한다.
- primary가 replica로 전송할 commit로그가 없는 경우 주기적으로 dummy transaction을 commit하여 replica의 last commit replay 시간을 갱신한다.
- replica 장애 후 복구 처리
- replica 장애 시 전송하지 못한 데이터 복구
- 컬럼 스토어의 특징을 활용한 복구(뒤에 설명함)를 제공
LOG GENERATION AND REPLAY
Log Records
- Log type
- DML log type과 transaction log type
- transaction log type: precommit log, commit log, abort log
- Transaction ID
- replica에서 transaction의 atomicity를 지원하기 위해 사용됨
- Session ID:
- 하나의 세션에서 다수의 트랜잭션이 실행될수 있으므로 세션 ID를 기록
- 이 값을 통해 parallel log replay에서 활용함
DML 로그 Type
- Operation type: insert, update, delete 구분
- Table ID
- Before-update RVID(이전 RVID): database record ID
- SAP HANA는 MVCC를 사용하므로 갱신이 일어나면 신규 레코드 버전이 생성된다.
- 신규 레코드가 생성되면 테이블 내에서 유일한 신규 RVID 값이 생성된다. RVID는 8 bytes 길이를 가지고 있다. 해당 값의 증가는 atomic CAS (compare-and-swap) instruction을 이용해서 lock이나 latch 없이 구현되어있다. Insert 로그의 경우에는 Before-update RVID가 존재하지 않는다.
- Before-update RVID는 replica에서 복제 대상이 되는 레코드를 빠르게 찾기 위해 존재
- After-update RVID(이후 RVID):
- primary와 replica에서 동일한 레코드를 버전을 식별하기 위해서 사용됨
- replica의 RVID는 replay후에 이 After-update RVID로 채워짐.
- Delete로그의 경우에는 After-update RVID가 존재하지 않는다.
- Data
- 변경된 Column ID와 변경된 Column Value 쌍들의 집합
Log Generation
DML operators들이 DML 작업을 하면 DML Log를 생성하고 log buffer에 추가한다. Log Buffer는 atomic CAS 연산을 이용해서 lock-free로 구현된다. transaction log의 경우에도 트랜잭션이 완료되고 lock이 모두 해제되기 전에 log buffer에 추가한다.
하나의 log sender는 n개의 replicas로 muticast 송신을 수행한다.
위의 로직에 의해서 다음의 두 가지 속성이 만족된다.- 트랜잭션 log(precommit, commit, abort)보다 DML로그가 항상 먼저 온다.
- primary에서 트랜잭션의 커밋 순서가 유지되어 전송된다.
Parallel Log Replay
세션ID 기반 로그 디스패치 방식과 RVID 기반 직렬화 오류의 동적 탐지
SessionID-based log dispatch method and the RVID-based dynamic detection of serialization error
세션ID 기반 로그 디스패치
parallel replay를 위해서 optimistic lock-free protocol을 따름.
A라는 로그를 replay할 때 해당 로그가 적용될 레코드를 찾으면, A 로그 전에 모든 변경사항이 적용되었는지 확인 후,
적용되지 않았다면, log serialization error를 내고 재시도 한다.
위의 예제에서 Log1, Log5와 Log3은 서로 큐에 들어있어 병렬로 처리가 된다.
이 때, Log3이 반영되기전에 Log5가 수행되면 Log5의 BeforeRVID가 02이며, 해당 레코드의 현재 RVID가 01이므로 Log3을 replay하는 병렬 replayer는 해당 레코드의 RVID가 02가 될 때까지 재시도 한다. 결국 Log2와 Log3이 수행된 후 Log5가 적용된다.(replay)
Implementation Issues
DML Replay
DML Replay는 무결성 체크를 생략한다, 이유는 이미 Primary에서 체크되었기 때문이다.
레코드 락도 잡지 않는데, replica는 갱신 트랜잭션이 들어오지 못하기 때문이다.
(레코드 락을 잡지 않으면 일시적으로 unique key가 중복될 수 있으나, commit이 되지 않은 상태이므로 client가 볼 수 없는 상태이다. 그러므로, 문제가 되지 않는다.
Commit Replay
commit 작업을 precommit, commit, and postcommit로 나누고, precommit을 DML log replayer에게 할당하며, postcommit 작업을 비동기 백그라운드 스레드로 분리하였습니다.
precommit은 DML log가 성공적으로 replay 되어야 하는 지를 표시하는데 사용합니다.
커밋 로그 리플레이의 중요한 역할은 생성된 로그 트랜잭션의 DML 리플레이에 의해 생성된 레코드 버전을 커밋된 것으로 표시하는 것입니다.
핵심 아이디어는 트랜잭션 커밋 작업을 사전 커밋, 커밋, 사후 커밋의 세 부분으로 나눈 다음, 사전 커밋 로그 항목을 사용하여 병렬 DML 로그 리플레이어에 사전 커밋 작업을 위임하고 사후 커밋 작업을 비동기 백그라운드 스레드에 위임합니다.
Query Processing at Replicas
이 작업은 특별한 것을 수행하지 않고 기존 SAP HANA의 MVCC에 따라서 유효한 버전이 가시화 되는 로직을 따라갑니다.
RECOVERY AND OTHER IMPLEMENTATION ISSUES
Post-Failure Replica Recovery
Run-time Error Handling
DDL Transaction Replication
EXPERIMENTS
- OLAP과 OLTP 부하를 동시에 주기 위해서 TPC-CH benchmark program 사용
- 동일한 데이터 셋에 대해서 TPC-C와 TPC-H를 동시에 주는 프로그램
- KuaFu style replayer: 아래 논문에서 제시된 병렬 알고리즘이며, 비관적(Pessimistic) 알고리즘으로 병렬화 한 replayer이다.
C. Hong, D. Zhou, M. Yang, C. Kuo, L. Zhang, andL. Zhou. Kuafu: Closing the parallelism gap indatabase replication. In IEEE ICDE conference, pages1186–1195, 2013
- ATR: 이 논문에서 이야기 하는 낙관적(Optimistic) 알고리즘의 병렬 replayer
- 테스트 방법
- 테스트는 TPC-C를 1분 동안 실행 후 5분 동안 부하 테스트를 실행한다.
- 복제는 하지 낳고 로그가 메모리에 쌓이도록 두며 테스트가 끝나면 이중화를 진행해서 이중화 완료시간을 이용해서 처리량을 계산한다.
- 64 스레드의 ATR을 1의 처리량으로 기준을 잡고 정규화해서 표로 표현한다.
처리량 계산방식으로 replayer들이 Primary TPC-C 보다 더 빠른 이유는 TPC-C의 select 부하나 primary에서 기록된 replication용 로그와 recovery용 로그를 둘 다 써야하기 때문에 기본 TPC-C의 성능은 복제를 하면 떨어질 수 밖에 없는 구조로 보임
Multi-Replica Scalability under Mixed OLTP/OLAP Workload
결론 - SAP HANA replication의 장점
RVID-based post-failure replica recovery mechanism을 통해 replica 복구
'DBMS' 카테고리의 다른 글
NoSQL의 처리 방식에 따른 분류, 순위 | Key-Value vs Document (0) | 2023.11.29 |
---|---|
NoSQL을 사용하는 이유와 Scale-out, Scale-up - 레디스(redis) vs 멤캐시드(memcached) (0) | 2023.11.29 |
HTAP OLAP과 OLTP 지원 DBMS의 기술 분석 - 1[HTAP Databases: What is New and What is Next] (0) | 2023.11.28 |
NoSQL이란 무엇인가? (0) | 2023.11.27 |
알리바바 클라우드 폴라 디비 - PolarDB HTAP(Hybrid Transactional Analytical Processing) (0) | 2023.11.25 |