직렬성 스냅샷 격리 수준 (Serializable Snapshot Isolation)

• kind of optimistic concurrency control
• pesmisstic concurrency control

커밋 시점에 판단

Conclusions SSI instead of 2PL, if most tx overlap with each other, otherwise use two phase locking

“”” 트랜잭션을 막지 말고 커밋 시점에서 확인하자! “””

• 동시성 문제와 성능 문제를 동시에 해결할 수는 없는가?
• 2008년에 처음 기술되고 마이클 카힐의 박사학위 논문주제(현 몽고DB 부사장)

비관적 동시성 제어 vs 낙관적 동시성 제어

• 동시성 문제를 다루는 관점
  1. 비관적 동시성 제어: 뭔가 잘못될 가능성이 있다면 일단 멈춰
     • e2PL, 다중 스레드 프로그래밍에서 상호배제
  2. 낙관적 동시성 제어: 트랜잭션을 막는대신 일단 작업을 계속 진행
     • 모든 트랜잭션을 커밋되기 직전까지 진행하다 커밋시에 격리 위반을 확인해서 직렬로 실행된 TR만 커밋
     • 경쟁이 심하면 어보트시켜야 할 비율이 높아지므로 성능이 떨어짐
     • 예비용량이 충분하고 트랜잭션간 경쟁이 심하지 않으면 성능 좋음
• 스냅숏 격리와 차이
  • TR에서 실행되는 모든 읽기는 DB의 일관된 스냅샷을 본다.
  • 스냅샷 격리 + 쓰기 작업간 직렬성 충돌을 감지하고 abort할 트랜잭션 결정 알고리즘

매커니즘

• 뒤처진 전제에 기반한 결정

  • 쓰기 스큐 패턴
    • TR이 DB에서 어떤 데이터를 읽고 그 질의 결과를 조사한 후 관찰한 후 결과를 기반으로 어떤 동작을 할지 결정
    • 스냅숏 격리하에서는 트랜잭션 커밋되는 시점에 가져온 쿼리 결과가 더 이상 최신이 아닐 수 있다. 도중에 데이터가 변경되었을 수 있음 (의사 한명이 이미 호출 대기를 해제)
    • 이러한 전제를 바탕으로 트랜잭션을 진행하면서 읽기 연산을 통해 가져온 데이터가 가장 최신의 정보인지 확인해야함

  1. 오래된 MVCC 객체 버전을 읽었는지 감지

     • 스냅샷 격리의 가시성 규칙에 따라 무시된 쓰기 연산이 커밋되었는지 확인해야함
     • 커밋된게 있다면 트랜잭션이 abort 됨

  2. 과거의 읽기에 영향을 미치는 쓰기 감지

     • 데이터를 읽은 후 다른 트랜잭션에서 그 데이터를 변경할 때
     • 읽기 연산 시점에 특정 색인 항목에 대해 어떠한 트랜잭션이 해당 데이터를 읽었는지 저장하고 트랜잭션이 진행하면서 해당 항목이 변경시 관련된 트랜잭션에 알려주고 커밋될 때 판단하도록 함
     • 만약 가장 빠른 TR의 경우에는 문제 없이 동작
     • 만약 이미 다른 TR이 커밋되었다면 내껀 abort

• 성능

  1. 트랜잭션의 R/W을 추적하는 세밀함
     • 기록 오버헤드와 abort TR 판별 정확성간의 트레이드 오프
  2. 트랜잭션이 차단되지 않음
  3. 단일 CPU 코어의 처리량에 제한 되지 않음
  4. 어보트 비율이 전체 성능에 큰 영향을 미친다.