HTAP OLAP과 OLTP 지원 DBMS의 기술 분석 2 [Parallel Replication across Formats in SAP HANA for Scaling Out Mixed OLTP/OLAP Workloads]

이 글에서는 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
• 배경
  • ETL을 이용한 OLAP의 문제점
  • OLTP와 OLAP을 하나의 시스템에서 운영하는 문제점
  • 문제 해결을 위한 시스템 설계 - Asynchronous Parallel Table Replication (ATR)
• 전체 구조
• 설계 이슈
  • 공통 설계 고려 사항
  • Primary Server
  • Replicas
• LOG GENERATION AND REPLAY
  • Log Records
  • Log Generation
  • Parallel Log Replay
  • Implementation Issues
  • Query Processing at Replicas
• RECOVERY AND OTHER IMPLEMENTATION ISSUES
  • Post-Failure Replica Recovery
  • Run-time Error Handling
  • DDL Transaction Replication
  • Routing Read-own-write Transactions
• EXPERIMENTS
• 결론 - SAP HANA replication의 장점

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 서버로 부터 분리시키는 것입니다. 

primary는 row store로 구성하고 replicas는 column store로 구성해서 OLTP 성능과 OLAP 성능을 극대화 할 수 있습니다. 

설계 이슈

공통 설계 고려 사항

1.  row store와 column store간 복제 기능 
• column store에서 row store로의 복제는 불필요하므로 구현하지 않음. (요구사항 없음)
2.  storage recovery log와 replication log의 분리
• physical 포멧의 recovery 로그로부터 row store에서 column store로 복제하는 것이 불가능함. 
• DB의 모든 테이블을 복제하는 것 보다 일부 테이블만 복제하는 것이 더 효율적인 경우가 많음.
• 기본 스토리지 엔진의 변경 및 중단 최소화, 복제로그 분석시 불필요한 오버헤드 제거
3.  엔진 내에 포함된 Sender와 replication log 생성기
• olap replicas의 지연 문제를 해소하기 위해서 엔진 내부에 replication log 생성기와 sender를 두었음

Primary Server

 

1. 로그 기반의 레코드 레벨 복제 (병렬 로그 반영에 따른 잠재적인 충돌 문제 회피)
• 이중화 복제를 위해 record-level result logging
• RVID(record version ID)
• 아래 문제로 SQL Operation logging을 사용하지 않음
• non-deterministic SQL functions등에 대한 문제를 해결할 수 없음. 
• SQL 실행 순서에 따른 문제가 발생할 수 있음.
2. DML이 종료되자마자 전송 (not commit)
• olap replicas의 지연 문제를 해소하기 위해서 로그를 DML이 수행되자마자 전송함

 

Replicas

 

1. 병렬 복제를 가능하게 함 
• primary에서 다수의 cpu를 사용해서 로그를 생성하므로 replica가 병렬로 적용하지 않으면 속도를 따라가지 못함
• full Parallel log replay를 사용함
2. 미리 정의된 최대 지연시간에 따른 질의 라우팅
• “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 시간을 갱신한다.
3. 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 기반 로그 디스패치

receiver는 로그를 수신하여 로그에 기록된 Session ID를 기반으로하는 queue에 DML 로그와 추후 설명하는 precommit, 그리고 abort 로그를 추가한다. 그리고, commit 로그의 경우 하나의 Tx log queue에 삽입한다. 

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

일반적으로 lazy replication의 장애 상황에서 보내지 못한 로그를 전송하기 위해서 store-and-forward라고 불리는 알고리즘을 사용하여 장애 시 전송하지 못한 로그를 replica로 복제합니다.  

그러나, 이 부분을 줄이기 위해서 다음과 같은 RVID기반의 재동기화 방식을 사용합니다. 

 

핵심 아이디어는 기본 테이블과 복제 테이블을 비교하여 기본 테이블과 복제 테이블 간의 RVID 불일치를 감지하는 것입니다. 열을 비교하여 두 테이블 간의 불일치를 감지하고 다른 것을 동기화 하는 것입니다.

P = {r1, r3, r5, r9}

R = {r1, r2, r4, r8}

R \ P = {r2, r4, r8}

P \ R = {r3, r5, r9}, 

{r2, r4, r8} are deleted, {r3, r5, r9} are re-inserted to the replica.

 

이 작업에서 전체 레코드의 RVID 값을 비교하는 것이 비용이 많이 드는 것 같지만, SAP HANA의 인메모리 컬럼 저장소는 연속된 메모리에 압축된 형태로 저장되기 때문에 비용이 많이 들지 않습니다. 

 

Run-time Error Handling

섹션 4.1에서 설명한 오류 유형 외에도, 메모리 부족 예외와 같은 런타임 오류

예외와 같은 런타임 오류가 로그 재생 도중에 발생할 수도 있습니다. 저희의

간단하고 실용적인 해결책은 문제가 있는 특정 테이블에 대한 복제를

특정 문제가 있는 테이블에 대해 미리 정의된 기간 동안 재시도한 후

복제를 해제하는 것입니다. 특정 복제본이 꺼지면

꺼지면, 문제가 있는 복제본 테이블에 대한 다음 쿼리는

다른 복제본 또는 기본 복제본으로 자동으로 다시 라우팅됩니다.

 

DDL Transaction Replication

SAP HANA에서는 replica에 자체 metadata를 가지고 있지 않습니다. 하지만, primary의 metadata cache의 일부를 사용하므로 이들을 가지고 있습니다. 

특정 테이블에 DDL이 수행되면 이전의 DML 로그를 모두 처리한 후 해당 metadata들을 invalidate합니다. 

 

Routing Read-own-write Transactions

Primary에서 내가 수정한 데이터를 replica에서 조회하면 보이지 않는 문제가 있을 수 있습니다. 

이 문제에 대해서는 현재 SAP HANA에서는 트랜잭션에서 Primary의 테이블의 데이터를 수정하고 내가 수정한 테이블에 대한 olap 질의를 수행하면 Primary에서 해당 질의를 처리하도록 라우팅합니다. 

 

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, and

L. Zhou. Kuafu: Closing the parallelism gap in

database replication. In IEEE ICDE conference, pages

1186–1195, 2013

 

• ATR: 이 논문에서 이야기 하는 낙관적(Optimistic) 알고리즘의 병렬 replayer

• 테스트 방법
• 테스트는 TPC-C를 1분 동안 실행 후 5분 동안 부하 테스트를 실행한다. 
• 복제는 하지 낳고 로그가 메모리에 쌓이도록 두며 테스트가 끝나면 이중화를 진행해서 이중화 완료시간을 이용해서 처리량을 계산한다. 
• 64 스레드의 ATR을 1의 처리량으로 기준을 잡고 정규화해서 표로 표현한다. 

 

처리량 계산방식으로 replayer들이 Primary TPC-C 보다 더 빠른 이유는 TPC-C의 select 부하나 primary에서 기록된 replication용 로그와 recovery용 로그를 둘 다 써야하기 때문에 기본 TPC-C의 성능은 복제를 하면 떨어질 수 밖에 없는 구조로 보임 

 

이후의 테스트 결과로 replication overhead에서는 다음과 같은 결과를 보여줌

이중화 걸면 약 3.2% 성능 저하 발생함. 

 

Multi-Replica Scalability under Mixed OLTP/OLAP Workload

 

 

결론 - SAP HANA replication의 장점

real-time replication으로 1초 미만의 가시성을 보여줄 수 있음.

OLTP와 OLAP을 구성하는 혼합 HTAP 구조에 대해서 설계하였음.

OLAP 트랜잭션의 scalability를 확인할 수 있음

CAS를 이용한 lock-free 구조를 구현함.

SessionID-based log dispatch를 통해 병렬화 함

RVID-based dynamic detection of serialization error and retry를 통해 레코드 직렬화 문제를 해결
RVID-based post-failure replica recovery mechanism을 통해 replica 복구

 

오늘은 SAP HANA에서 OLTP와 OLAP을 지원하기 위해서 구현한 방법을 알아보고 정리해 보았습니다. 어려운데 재미는 있네요.