Transaction4

세미·2022년 12월 11일
0

데이터베이스

목록 보기
7/9

Serializability

- 여러 트랜잭션을 병렬로 동시에 처리하면서도 순차적으로 수행한것과 같은 결과를 냄.
  • Isolation Level --> 각각의 트랜젝션들이 consistent한 데이터베이트 state를 보는가 안보는가의 여부와 직접적으로 관련있음. 굳이 Serializability 하지 않아도 된다는 뜻?

  • Isolation level, consistent level을 올리면 올릴수록 성능이 떨어짐. 속도가 느려질 수 있음.
    - 하지만 속도는 느리지만 이러한 스케줄로 구성을 해야되는 경우가 생길 수 있음.

    • consistency, 퍼포먼스는 반비례관계

고립성 수준을 구현하는 방식

  1. Locking
    • 연산을 수행할때 중요한 색션을 수행할때 lock으로 잠그고 실행 -> 다하면 해제
  2. Timestamps
    • 순서 타임 스템프를 찍음. 시간상의 순서를 체크.
    • 시간상의 순서를 알면 순서가 뒤집혔는지 안 뒤집혔는지 알 수 있음
  3. Multiple versions of each data item (버전관리)
    • ex) a= 2->3으로 변경. (a=2)일때 version1, (a=3)일때 version2 로 설정
    • 서로 다른 값을 읽어도 버전을 비교해서 어느값이 더 최신인지 알 수 있음. -> a=3이 더 최신의 값이라는것을 알 수 있음.

Concurrency Control(동시성 제어)

  • 트랜젝션이 동시에 실행될때 일관성(consistency)을 해치지 않도록 데이터 접근을 제어하는 기능.

Locking

  • 동시성제어에서 가장 기본이 되는 컨셉.
  • 여러 트랜젝션이 하나의 데이터를 읽거나 쓰거나함. -> 결과가 비결정적일 수 있는 문제. -> 이를 해결하는 제일 쉬운 방법이 lock
  • 자물쇠의 용도 = 내가 아닌 다른 사람이 공간에 못들어오게 막기위함. 혼자서 사용할려고.
  • 현재 어떤 트랜젝션이 데이터에 access중일때 다른 트랜젝션이 access 시도를 하고 값이 변경되면 문제가 발생함. -> 하나의 트렌젝션이 유일하게 access하도록 lock을 걸음.

1.exclusive lock

  • read, write 가 가능한 lock.
  • lock-X 라는 명령어로 호출. ex) lock-X a a에 대해서 내가 배타락을 걸음

2.shared lock

  • read만 가능한 lock
  • lock-S로 호출.
  • lock요청은 concurrency-control 매니져를 반드시 거쳐야 함.
  • 요청을 하면 매니저가 그걸 검토함. lock을 관리하는 매니저 존재.
  • 트랜젝션은 request가 granted(인정받아야)해야 진행이 가능

lock 호환성 matrix

  • 두개의 락이 존재할때 한쪽이 exclusive lock을 쓰는 순간 두 개의 lock이 공존할 수 없음. 다른 트랜젝션은 lock을 얻을 수 없음. 일관성 문제때문에

  • read,write 를 교차하면서 처리 -> cpu와 disc의 utilization을 올리기 위해.

  • write 연산때문에 일관성이 깨지는 문제가 생김. read때문에 값이 변경되고 있잖슴.

  • 둘다 shared lock을 요청 하는 경우에만 두개의 락이 공존할 수 있다.

  • Serializable: 스케줄을 재구성 했을때 confilct equivalent 해야함.

  • (serializable 하지 않다) == (트렌젝션을 순차적으로 실행한 결과와 결과값이 다르다.)

  • restricting the set of possible schedules를 통해 직렬가능성을 강제할 수 있다.
    =locking protocol로 스케줄링 할때 serializable 하지 않는 스케줄은 다 배제한다.

    • locking protocol를 이용해서 serializable한 스케줄만 선별적으로 뽑아주는것.

DeadLock

  • 교착상태
  • 서로서로 끝나기만을 기다리고 있는 상태
  • 트랜젝션은 isolation 하므로 다른 트랜젝션의 존재에 대해 인식을 하지 못함. 그냥 기다리고 있는 상태가 됨.
  • 두 트랜젝션 모두 진행 할 수 없는 상태가 됨. 서로 락을 해제해주리는 기다리는 상태가 됨.
  • 락을 해제하거나, 둘중 하나는 rollback 해야함.
  • 매니저가 제대로 통제하지 못하면 starvation 문제 발생
    - 더 정교하게 디자인이 되어야함.
    • 롤백만 한다고 데드락이 안걸리는게 아님. 똑같은 문제가 발생할 수도 있음.

0개의 댓글