[HANA] MVCC and GC

MVCC

• 데이터의 버전에 기반을 한 concurrent write operation을 block하지 않고 concurrent read operation을 제공
• Update operation은 lock을 통한 기존 record의 변경이 아닌 Insert new version 방식을 이용
• Read operation은 일종의 timestanp를 이용하여 읽을 DB의 상태를 결정하고 해당 버전의 데이터를 읽음
  • Transaction이 commit 되기 전까지 각 유저에게 snapshot을 제공
• 오래된 버전은 주기적으로 삭제되어야 함 (Garbage collection)
• GC관련 이슈 
  • "MinReadTS"를 가지는 Transaction이 오랜시간 동안 수행되면 GC를 block 하여 version은 누적되게 됨
  • Long-running query
    -> GC blocked
    -> Continuous growing version space
    -> Performance drop / Memory & disk size grow
  • Root cause를 분석하는 것이 중요함
    • Version number 확인
      • SELECT version_count FROM M_MVCC_OVERVIEW;
    • Check GC blocker
      • select * from m_prepared_statements where statement_id = (select current_statement_id from m_connections where connection_id = (select connection_id from m_transactions where min_mvcc_snapshot_timestamp = (select min(Value) from m_mvcc_tables where name = 'MIN_SNAPSHOT_TS') and connection_id > 0));
  • Solution
    1. Long running query를 찾아서 cancel 시킴
       • ALTER SYSTEM CANCEL SESSION <the blocker connection ID>
    2. Kill the connection
       • ALTER SYSTEM DISCONNECT SESSION <the blocker connection ID>
       • 1번이 도움이 되지 않을때 사용 권장
    3. Cancel the transaction
       • hdbcons 'transaction cancel <the blocker transaction ID>'
       • Blocker에 대한 connection 정보가 없는 경우에 권장
    4. Indexserver restart or system replication takeover

 

---

 

Internal

• HANA는 snapshot isolation을 지원함
  • 유명한 MVCC protocol
  • Transaction은 committed version의 snapshot을 읽을 수 있음
    (snapshot of the version = committed transaction에 의해 생성)
  • 두가지 유형 존재
    • Statement-level snapshot isolation (Stmt-SI)
      • HANA의 default 적용된 isolation level
      • 모든 reads는 논리적으로 Statement의 시작 시 발생됨 
      • 각 statement는 각기 새로운 snapshot timestamp를 가진 자신의 snapshot을 가짐
    • Transaction-level snapshot isolation (Trans-SI)
      • 모든 reads는 논리적으로 transaction의 시작 시 발생됨
      • 각 transaction은 각기 새로운 snapshot timestamp를 가진 자신의 Snapshot을 가짐
  • 더이상 사용되지 않은 version은 삭제되어야 하며 이를 garbage collection이라 함
    • 일반적 transaction 처리 시 무시할 수 없는 overhead 발생
      • 이를 위해 roup garbae version collector 컨셉을 사용함
    • Group으로 묶을 수 있는 동일 Transaction에서 생성된 버전들의 set로 관리 가능
• MVCC 는 garbage를 정의하기 위해 concept of visibility를 사용함
  
  • 예)
    
    
    • global minimum taimestamp = 3
    • garbage collector는 v11, v12를 garbage로 판단 (3보다 낮은 timestamp)
    • 여기서
      v13, v14는 어떤 active transaction에서도 사용되지 않으므로 garbage collect 대상임
    • OLTP 부하에서는 문제를 야기할 수 있음
      (Long transaction에 의한 이슈 - 상기 언급된 내용)
• HANA row store에서의 version management
  • INSERT/UPDATE/DELETE operation은 version space에 record version이 생성됨
    • row store = table space + version space
  • 특정 row에 version이 존재하는지 여부 -> is_versioned flag 사용
    • 버전이 존재하는 경우 (변경이 존재하는 경우)
      RID hash table을 찾아서 버전을 찾아감
    • RID hash table은 chained hash structure
      • hash bucket의 array이며 해당하는 버전 chain의 주소를 가지고 있음
      • Multiple version인 경우 linked list 형태로 이어짐 (최신이 앞으로 위치)
• Global Group Garbage Collector
  • HANA에서는 다음의 최적화 전략을 사용
    1. • Global STS tracker로 관리
         • Gloabl STS tracker = ordered list of reference-counted snapshot timestamp value
         • Snapshot이 시작되면 snapshot timestamp를 회득함
           • Tracker에 존재하면 reference count만 하나 증가시킴
           • 아닌 경우 새로운 snapshot timestamp object가 추가됨
         • Snapshot에 관련된 query나 Transaction이 처리를 마치면 reference count 값을 감소시킴
           • 0이 되면 해당 snapshot object는 삭제됨
       • Global STS tracker의 값은 increasing order로 저장됨 (따라서 최소값은 첫번째 위치)
         efficiently select the minimum global snapshot timestamp value
         
         
    2. efficiently detect a group of garbage version
  • Timestamp-based decision만 사용하게 됨
• Interval Garbage Collector
  • 다음 4단계를 포함함
    1. Global STS tracker에 의해서 유지되는 전체 snapshot timestamp값을 scanning하여 받게 되는 active snapshot timestamp의 전체 집합을 검색함 = S로 표기
    2. Interval garbage collector는 존재하는 GroupCommitContext를 scan하여 다음 조건을 찾음
       
       • Min of S < CID < max of S = P로 표기
    3. 가장 높은 CID 순서로 P의 GroupCommitContext 객체를 반복하여 Interval garbage collector가 GroupCommitContext object에 도달할 수 있는 record version에 access
    4. 도달 가능한 각 record version에 대해 식별함
  • Version 공간을 논리적으로 분할하여 Interval garbage collector가 Multiple thread에 의해 병렬로 수행할 때 유용
• Table Garbage Collector
  
  • Per-table snapshot timestamp trackers
  • Snapshot S1, S2가 long-lived snapshot인 경우 (STS=2057)
    • Table 1,2가 관련됨
    • 이와 관련이 없는 snapshot의 minimum STS=2100
  • Table garbage collection 사용됨
    • 각 Table별 STS tracker가 사용되고 Global STS에서는 2057이 삭제
• Hybrid GC
  • Hybrid GC = Global group GC + Table GC + Interval GC
  • 수행 순서
    • GT + TG + SI