10주차 스터디

[KilJaeeun]

파트

7. 트랜잭션 ~ 아이솔레이션 레벨 격리까지

발표자

• 강병진

발표 기간

• 5월 24일 오후 10시

마감기한

• 5월 24일 오후 9시 59분

참고 링크

• 일정표 : https://clever-bull-d00.notion.site/bd201441d8a44c83a70375001278c850
• 책 : http://www.yes24.com/Product/Goods/59566585

[hyunju-song]

Ch07.트랜잭션(1)

• 트랜잭션은 내결함성을 갖춘 시스템을 위한 메커니즘으로 채택되어 왔다
• 트랜잭션은 애플리케이션에서 몇개의 읽기와 쓰기를 하나의 논리적 단위로 묶는 방법이다

애매모호한 트랜잭션의 개념

• 비관계형 데이터베이스가 인기를 얻으면서 새로운 데이터 모델을 선택하게 하고 기본적으로 복제와 파티셔닝을 제공함으로써 관계형 데이터베이스의 현 상황을 개선하는 것을 목표로 했다
• 트랜잭션을 완전히 포기하거나 약한 보장으로 의미를 재정의하기 시작했다.
• 분산 데이터베이스가 홍보되면서 태랜잭션은 확장성의 안티테제이며 고가용성을 위해서는 트랜잭션을 포기해야한다는 믿음이 퍼지기도 했다.

ACID의 의미

• 현실에서 이를 구현하는 것은 제각각이다.

원자성

• 실제로 시스템은 연산을 실행하기 전이나 실행한 후의 상태에만 있을수 있으며 그 중간상태에는 머물 수 없다.
• 여러 프로세스가 동시에 같은 데이터에 접근하려고 할때 무슨일이 생기는지 설명하지 않는다. 이는 격리성에서 다룬다
• 여러 쓰기 작업이 하나의 원자적인 트랜잭션으로 묶여있는데 결함 때문에 완료될 수 없다면 어보트되고 데이터베이스는 이 트랜잭션에서 지금까지 실행한 쓰기를 무시하거나 취소해야한다.
• 원자성이 없다면 여러 변경을 적용하는 도중 오류가 발생하면 어떤 변경은 효과가 있고 어떤 것은 그렇지 않은지 알기 어렵다.

일관성

• 애플리케이션의 속성이다
• 데이터베이스 자체에서는 일관성을 위한 어떠한 작업 및 식을 실행할 수 없다.

격리성

• 동시에 실행되는 트랜잭션은 서로 격리된다는 것을 의미한다.
• 직렬성 격리는 성능 손해를 동반하므로 현실에서 거의 사용하지 않는다.
  • 직렬성은 각 트랜잭션이 전체 데이터베이스에서 실행되는 유일한 트랜잭션인 것처럼 동작할 수 있다는 것을 의미한다.
• 보장이 좀 더 약한 스냅숏 격리르 ㄹ구현한다.

지속성

• 트랜잭션에서 기록한 모든 데이터는 손실되지 않는다는 보장

복제와 지속성

• 절대적 보장을 제공하는 한가지 기법은 없다.

단일객체 연산과 다중객체 연산

• 다중 객체 트랜잭션은 흔히 데이터의 여러 조각이 동기화된 상태로 유지돼야 할 때 필요하다
  • 어떤 읽기 연산과 쓰기 연산이 동일한 트랜잭션에 속하는지 알아낼 수단이 있어야 한다.
  • 일반적으로 클라이언트와 데이터베이스 서버 사이의 TCP 연결을 기반으로 한다.

단일객체 쓰기

• 저장소 엔진들은 보편적으로 한 노드에 존재하는 단일 객체 수준에서 원자성과 격리성을 제공하는 것을 목표로 한다.
• 원자성은 장애복구용 로그를 써서 구현할 수 있고 격리성은 각 객체에 잠금을 사용해 구현할 수 있다

다중 객체 트랜잭션의 필요성

• 많은 분산 데이터스토어는 다중 객체 트랜잭션 지원을 포기했다
• 다른 테이블의 로우를 참조하는 외래키를 갖는 경우
• 비정규화한 문서데이터베이스
• 보조색인이 있는 경우

오류와 어보트 처리

• 보통 데이터베이스는 가능한 모든 것을 할 것이며 그 때문에 오류가 발생하면 한일을 취소하지 않음으로써 오류 복구는 애플리케이션에 책임을 넘긴다
• 어보트된 트랜잭션을 재시도 하는 것은 간단하고 효과적인 오류처리 매커니즘이지만 완벽하지는 않다.

완화된 격리수준

• 트랜잭션 격리를 제공함으로써 애플리케이션 개발자들에게 동시성 문제를 감추려고 한다.
• 직렬성 격리는 데이터베이스가 여러 트랜잭션들이 직렬적으로 실행되는 것과 동일한 결과가 나오도록 보장한다는 것을 의미한다.
• 현실적으로는 동시성 이슈로부터 보호해주지만 모든 이슈로부터는 보호해주지는 않는 완화된 격리수준을 사용하느 ㄴ시스템이 흔하다

커밋 후 읽기

• 데이터베이스에서 읽을때 커밋된 데이터만 보게된다(더티읽기가 없음)
• 데이터베이스에 쓸때 커밋된 데이터만 덮어쓰게 된다(더티쓰기가 없음)

더티읽기 방지

• 트랜잭션에서 커밋되지 않은 데이터를 볼 수 있는 경우가 더티 읽기
• 트랜잭션이 어보트되면 그때까지 쓴 내용은 모두 롤백돼야 한다.

더티쓰기 방지

• 먼저 쓴 내용이 아직 커밋되지 않은 트랜잭션에서 쓴것이고 나중에 실행된 쓰기 작업이 커밋되지 않은 값을 덮어쓰는 경우가 더티쓰기이다.

커밋 후 읽기 구현

• 가장 널리 쓰이는 격리 수준
• 로우 수준 잠금을 사용해서 더티쓰기를 방지
• 더티읽기는 동일한 잠금을 써서 객체를 읽기 원하는 티랜잭션이 잠시 잠금을 획득한 후 읽기가 끝난 후 바로 해제하게 하는 것이다.
• 그러나 실제로 읽기 잠금을 요구하는 경우, 쓰기 트랜잭션 하나가 완료될때까지 여러 읽기 작업이 이를 기다려야 한다.

스냅숏 격리와 반복 읽기

• 각 트랜잭션은 데이터베이스의 일관된 스냅숏으로부터 읽는다.
• 백업이나 분석처럼 실행하는 데 오래 걸리며 읽기만 실행하는 질의에 요긴하다.

스냅숏 격리 구현

• 전형적으로 더티 쓰기를 방지하기 위해 쓰기 잠금을 사용한다.
• 커밋 후 읽기 격리만 제공해야한다면 객체마다 버전 두개씩만 유지하면 충분하다. 바로 커밋된 버전과 덮어쓰여졌지만 아직 커밋되지 않은 버전이다.
• 갱신은 내부에서 삭제와 생성으로 변환된다.

갱신손실 방지

• 커밋후 읽기와 스냅숏 격리 수준은 주로 동시에 실행되는 쓰기 작업이 있을때 읽기 전용 트랜잭션이 무엇을 볼 수 있는지에 대한 보장과 관련
• 갱신손실 문제는 값을 읽고 변경한 후 변경된 값을 다시 쓸때 발생할 수 있다.
• 원자적 쓰기 연산
• 명시적인 잠금
• 갱신손실 자동 감지
• Compare-and-set
• 충돌해소와 복제

쓰기스큐와 팬텀

• 두 트랜잭션이 두개의 다른 객체를 갱신할때, 그 중 일부만 실제로 갱신되었을때
• 회의실 예약 시스템
• 다중 플에이어 게임
• 사용자명 획득
• 이중 사용 방지

[jasonkang14]

일단은 Write skew까지 작성했는데 내일 시간 봐서 가보시죠 ㅋㅋ https://docs.google.com/presentation/d/1WwqHo-vkbnra9hbg0C4B0QIjOeJ6Njz8l-rsfzZXplg/edit#slide=id.p

[KilJaeeun]

트랜잭션 인트로

데이터 시스템엔 여러 문제가 생길 수 있다. .. 수십년간 트랜잭션은 이런 문제를 단순화 하는 메커니즘으로 채택됨

• 정의 : 트랜잭션은 애플리케이션에서 몇 개의 읽기와 쓰기를 하나의 논리적 단위로 묶는 방법이다. = 커밋 or abort -> 부분실패의 경우의 수를 없앰
• 동시성 제어 분야를 깇게 다루며 다양한 경쟁 조건과 데이터베이스에서 커밋 후 읽기, 스냅숏 격리, serialization 과 같은 격리 수준을 어떻게 구현하는지 보자.

acid

• atomicity : 완료(commit) 혹은 abort = abortability = 일부 처리라는 개념을 없앰
• consistency : 모든 계좌에서 대변과 차변이 맞아야함 => 이건 애플리케이션 속성임. 고로 acid 에 속한다 말할 수 없음
• isolation : 동일한 데이터베이스 레코드에 접근하는 동시성(경쟁문제). 동시에 실행되는 트랜잭션은 서로 격리된다. = 직렬성 (각 트랜잭션이 유일한 트랜잭션인양 동작함) => 성능 손해 동반 <> 스냅숏 격리
• durablitiy : 커밋이 되면 하드웨어 죽더라도 트랜잭션에 기록한 모든 데이터는 손실되지 않는다. (wal, 복제 기능 디비의 경우 다른 곳에 복제했다.. -> 지속적이 보장되려면 디비는 트랜잭션이 성공적으로 커밋됐다 보고 전에 복제가 완료될 떄까지 기다려야함

단일 객체 연산과 다중 객체 연산

• 요약하면 acid 에서 원자성과 격리성은 클라이언트가 한 트랜잭션 내에서 여러번 쓰기를 하면 데이터베이스가 어떻게해야하는지를 서술한다.
• (예.안읽은 메일 + 실제온메일)

단일 객체 쓰기

• 원자성과 격리성은 단일 객체를 변경할때도 적용되는데 큰 파일을 쓴다 하자. 중간에 죽으면?

오류와 어보트 처리

• 일부 시스템은 그냥 포기함 (예. 장고 orm 의 경우 어브트된 트랜잭션을 재시도 하지 않는다. ) 데이터베이스는 가능한 모든것을 할 것이고, 그때문에 오류가 발생하면 이미 한일은 취소하지 않는다 (= 애플리케이션단에서 알아서 고치라함)

완화된 격리 수준

• 직렬성 격리는 데이터베이스가 여러 트랜잭션들이 직렬적으로 실행되는것과 동일한 결과각 나오도록 보장하는 것이다.

트랜잭션 격리

커밋 후 읽기

• 두가지를 보장한다.

  1. 데이터베이스에서 읽을때 커밋된 데이터만 보게함(더티 읽기가 없다.)
  2. 데이터베이스에 쓸때 , 커밋된 데이터만 덮어쓰게 된다.(더티쓰기가 없다)

• 더티 읽기 : 트랜잭션 커밋 전 데이터 읽기

• 더티 쓰기 : 트랜잭션 커밋 전 데이터 쓰기

커밋 후 읽기 구현

• 데이터베이스는 로우 수준 잠금을 이용해 더티 쓰기를 방지한다. (기다리는게 현실상 말이 안된다는 평가)

스냅숏 격리와 반복 읽기

• 통장 2개 이체 하고 리시버 통장이 이체 커밋전, 수중의 돈이 사라진 것같은 현상 = > 비반복 읽기, 읽기 스큐
• 읽기 스큐 : 커밋 후 읽기 격리에서는 받아들일 수 있는 것으로 여겨진다 .
• 스냅숏으로 "그 시점" 데이터를 바라보는 형식으로 해소 가능
• 스냅숏 격리 = 다중 버전 동시성 제어(multi version concurenccy control, MVCC)
• 색인 동작은 ? : 여러 버전을 색인이 바라보게해야하는데 성능 이슈 지점. 비플러스 트리 처럼 카우치DB, 데이토믹 등에서는 자식들이 새페이지 가르키게 변경
• gc, 컴팩션이 결국에 필요하게됨
• 유사 이름 : 직렬성 , 반복읽기

갱신 손실 방지

• 갱신 손실 문제는 애플리케이션이 데이터베이스에서 값을 읽고 변경한 후 변경된 값을 다시 쓸때 발생할 수 있다. (read-modify-write 죽)

해소

• 원자적 쓰기 연산 = 커서 안정성 (불행히, orm 에서 지원 잘 안함)

  update counters set value = value + 1 where key="foo";

• 명시적인 잠금 : 고민 해 봐라!
• 갱신 손실 자동 감지: read-modify-write 주기가 순차적으로 진행되도록 강제해 갱신 손실을 방지한다.
• compare-and-set : 값을 마지막으로 읽은 후 변경 안됏을때만 갱신 허용
• 충돌 해소와 복제
  • 잠금과 compare-and-set 은 단일 리더임, 리더 없는 복제의 경우, 여러 쓰기고 비동기식 복제이므로, 최신 복제가 1이라고 보장 불가.
  • 알아서 앱단에서 충돌 해소하게 유도
  • 원자적 연산은 어떤 상황에서도 잘 동작
  • 최종쓰기(last write win, lww ) 충돌 해소 방법은 갱신 손실이 발생하기 쉽다.

[wookiist]

트랜잭션

• 시스템이 신뢰성을 지니기 위해 치명적인 장애로 이어지는 것을 막아줘야 함
• 트랜잭션 내의 모든 읽기와 쓰기는 한 연산으로 실행. 전체가 성공(커밋)하거나 실패(어보트)하는 방식

애매한 트랜잭션 개념

• 높은 성능과 고가용성을 유지하려면 트랜잭션을 포기해야 한다고들 하는데 진실은 단순하지 않음

ACID 의미

• 유감스럽게도 오늘날 거의 마케팅 용어가 되어버렸다
• Atomic (원자성)
  • 오류가 생겼을 때 트랜잭션을 어보트하고 해당 트랜잭션에서 기록한 모든 내용을 취소하는 능력
• Consistency (일관성)
  • 항상 진실이어야 하는 데이터에 관한 어떤 불변 선언이 있다는 것
• Isolation (격리성)
  • 동시에 실행되는 트랜잭션은 서로 격리된다는 것
• Durability (지속성)
  • 완벽한 지속성은 존재하지 않음

단일 객체 연산과 다중 객체 연산

• 단일 객체 쓰기
  • 누군가에 동시에 바뀌지 않았을 때만 쓰기가 반영됨
  • compare-and-set 다른 단일 객체 연산은 "경량 트랜잭션" 불리기도 하지만, 오해의 소지가 있음
• 다중 객체 트랜잭션의 필요성
• 오류와 어보트 처리
  • 트랜잭션의 핵심 기능은 오류가 생기면 어보트되고 안전하게 재시도할 수 있다는 것

커밋 후 읽기

• 가장 기본적인 수준의 트랜잭션 격리 (다음의 두 가지를 보장)

  • 데이터베이스에서 읽을 때 커밋된 데이터만 보게 됨 (더티 읽기가 없음)
  • 데이터베이스에 쓸 때 커밋된 데이터만 덮어쓰게 됨 (더티 쓰기가 없음)

• 더티 읽기 방지

  • 트랜잭션이 데이터베이스에 데이터를 썼지만, 아직 커밋되거나, 어보트 되지 않았는데, 다른 트랜잭션에서 커밋되지 않은 데이터를 볼 수 있게 되는 현상.

• 더티 쓰기 방지

  • 먼저 쓴 내용이 커밋되지 않은 트랜잭션에서 쓴 것이고 나중에 실행된 쓰기 작업이 커밋되지 않은 값을 덮어 써 버림.

• 커밋 후 읽기 구현

  • 여러 데이터베이스에서는 기본 설정임
  • 더티 읽기를 막기 위해 잠금을 쓸 수도 있지만, 현실에선 잘 동작하지 않음

스냅숏 격리와 반복 읽기

• 비반복 읽기나 읽기 스큐
  • 읽기 스큐는 커밋 후 읽기 격리에서는 받아들일 수 있는 것으로 여겨짐
  • 새로고침을 통해 갱신된 계좌잔고를 볼 수 있음
  • 근데 백업을 사용해서 복원하면 비일관성이 유지되어 버림 ㅠ
  • 스냅숏 격리 = 각 트랜잭션을 데이터베이싀 일관된 스냅숏으로부터 읽는 것
• 스냅숏 격리 구현
  • 읽는 쪽에서 쓰는 쪽을 결코 차단하지 않고 쓰는 쪽에서 읽는 쪽을 결코 차단하지 않음
• 일관된 스냅숏을 보는 가시성 규칙
  • 데이터베이스는 갱신할 때 값을 교체하지 않고 값이 바뀔 때마다 새 버전을 생성해서 작은 오버헤드만 유발하고 일관된 스냅숏을 제공할 수 있음
• 색인과 스냅숏 격리
  • 단순하게 색인이 모든 객체 버전을 가리키게 하고, 색인 질의가 현재 트랜잭션에서 볼 수 없는 버전을 걸러내게 하는 방법도 있음
• 반복 읽기와 혼란스러운 이름
  • 스냅숏 격리는 반복 읽기라고도 하고 직렬성이라고도 함

갱신 손실 방지

동시에 실행되는 쓰기 트랜잭션 사이에 발생할 수 있는 충돌 중 널리 알려진 녀석

• 원자적 쓰기 연산
  • read-monify-write 주기 구현을 피하게 해줌.
  • 모든 쓰기가 쉽게 원자적 연산으로 나타나진 않음.
  • 보통은 독점적 잠금을 얻어서 구현하는데, 이를 커서 안정성이라고 부르기도 함
• 명시적인 잠금
  • 어쨌든 애플리케이션 로직에 대해 신중하게 생각해야 함. 잠금을 추가하는 걸 까먹으면 경쟁 조건이 유발됨.
• 갱신 손실 자동 감지
  • 갱신 손실이 발견되면 트랜잭션을 어보트하고, read-modify-write 주기를 재시도하도록 트랜잭션 매니저가 강제하는 방법
• Compare-and-set
  • 값을 마지막으로 읽은 후로 변경되지 않았을 떄만 갱신을 허용함으로써 갱신 손실 회피
• 충돌 해소와 복제

쓰기 스큐와 팬텀

• 쓰기 스큐를 유발하는 팬텀
  • 팬텀 : 어떤 트랜잭션에서 실행한 쓰기가 다른 트랜잭션의 검색 질의 결과를 바꾸는 효과. 스냅숏 격리는 읽기 전용 질의에서는 팬텀을 회피하지만 읽기 트랜잭션에선 팬텀이 쓰기 스큐를 유발할 수 있음
  • 충돌 구체화 : 인위적으로 데이터베이스에 잠금 객체를 추가하면 되지 않을까? 팬텀이 발생하는 것을 DB에 존재하는 로우에 대한 잠금 충돌로 변환하는 것. 근데 오류가 발생하기 쉬움 ㅠ 그리고 어려움 ㅠ

[dns02023]

트랜잭션

애매모호한 트랜잭션의 개념

ACID

원자성

• 시스템은 연산을 실행하기 전이나 실행한 후의 상태에만 있을 수 있으며 그 중간 상태에는 머물 수 없다.

  일관성

• 항상 진실이어야 하는, 데이터에 관한 어떤 선언(불변식)이 존재한다는 것
• 데이터베이스 자체보다는 애플리케이션의 속성

  격리성

• 동시에 실행되는 트랜잭션은 서로 격리

  지속성

• 트랜잭션이 성공적으로 커밋되었다면, 하드웨어 결함 or 데이터베이스가 죽더라도 기록한 모든 데이터는 손실되지 않는다는 보장

단일 객체 연산과 다중 객체 연산

• 다중 객체 트랜잭션은 흔히 데이터의 여러 조각이 동기화된 상태로 유지되어야 할 떄 필요

단일 객체 쓰기

• 단일 객체 연산은 여러 클라이언트에서 동시에 같은 객체에 쓰려고 할 떄 갱신 손실 방지에 유용하다.
• 트랜잭션은 보통 다중 객체에 대한 다중 연산을 하나의 실행단위로 묶는 매커니즘

오류와 어보트 처리

• 트랜잭션의 핵심은 오류가 생기면 어보트 => 안전하게 재시도
• 하지만, 어보트된 트랜잭션 재시도는 간단하고 효과적이지만 완벽하지는 않다.

완화된 격리 수준

• 두 트랜잭션이 동시에 같은 데이터를 변경하는 동시성 문제는 완화된 트랜잭션 격리에 의해 유발될 수 있음

커밋 후 읽기

• 가장 기본적인 트랜잭션 격리

  더티 읽기 방지

• 아직 커밋되거나 어보트되지 않은 데이터를 다른 트랜잭션에서 볼 수 있는 것이 더티 읽기
• 다른 트랜잭션들이 잘못된 결정을 하는 원인이 될 수 있음
• 트랜잭션들이 실제로는 결코 커밋되지 않을 데이터를 볼 수도 있음

  더티 쓰기 방지

• 아직 커밋되지 않은 트랜잭션에서 쓴 것을 나중에 실행된 트랜잭션이 덮어써버리는 것이 더티 쓰기
• 먼저 쓴 트랜잭션이 커밋되거나 어보트될 때까지 두 번째 쓰기를 지연시켜야 함

  커밋 후 읽기 구현

• 로우 수준 잠금을 사용해서 더티쓰기 방지
• 읽기 원하는 트랜잭션이 잠시 잠금을 획득한 후 읽기가 끝난 후 바로 해체
• 읽기만 실행하는 여러 트랜잭션들이 오랫동안 실행되는 쓰기 트랜잭션 하나가 완료될 떄까지 대기하므로 응답시간이 증가하여 운용성이 나쁨
• 그러므로 과거에 커밋된 값과 현재 쓰기 잠금을 갖고 있는 트랜잭션에서 쓴 새로운 값을 데이터베이스가 모두 기억해야 한다.

스냅숏 격리와 반복 읽기

• 각 트랜잭션은 데이터베이스의 일관된 스냅숏으로부터 읽는다.
• 백업이나 분석처럼 실행하는 데 오래 걸리며 읽기만 실행하는 질의에 요긴함

  스냅숏 격리 구현

• 읽는 쪽에서 쓰는 쪽을 결코 차단하지 않고, 쓰는 쪽에서 읽는 쪽을 결코 차단하지 않아야 함
• 커밋 후 읽기는 질의마다 독립된 스냅숏을 사용하고, 스냅숏 격리는 전체 트랜잭션에 대해 동일한 스냅숏을 사용

갱신 손실 방지

• 애플리케이션이 데이터베이스에서 값을 읽고 변경한 후 변경된 값을 다시 쓸 빼 발생
• 두 트랜잭션의 작업이 동시에 이루어지면서, 변경 중 하나는 손실 가능
• 객체를 읽을 때 그 객체에 대해 독점적인 잠금을 획득하여 원자적 갱신 연산으로 방지
• 애플리케이션에서 갱신할 객체를 명시적으로 잠금
• 자동으로 갱신 손실이 감지되어 오류 발생을 방지하는 갱신 손실 자동 감지하는 방법도 있음
• 값을 마지막으로 읽은 후로 변경되지 않았을 때만 갱신을 허용하여 갱신 손실을 회피하는 compare-and-set
• 여러 노드에 데이터의 복사본이 있는 경우에는, 쓰기가 동시에 실행될 때 한 값에 대해 여러개의 충돌된 버전을 생성하는 것을 허용하고, 사후에 충돌을 해소하고 이 버전들을 병합