[4주차] 내용 정리

[myeongjae-kim]

길다길어

• 트랜잭션은 애플리케이션에 데이터베이스에 접근하기 위한 프로그래밍을 쉽게 하기 위해 만들어졌다. 트랜잭션 덕분에 애플리케이션은 동시성 이슈를 겪지 않게 되었다.
  • 완전히 자유로워진건 아니지만..
• ACID에서 C는 아무 의미 없다, 그냥 단어를 만들기 위해 들어간 것... consistency는 애플리케이션 책임이다.
  • 그래도, 애플리케이션이 아무리 잘해도 DB에서 write skew같은거 발생하면 consistency가 깨지는데?
  • 트랜잭션의 궁극적인 목적이 consistency라고 할 수 있지 않을까?
• Oracle database에서 serializable이라고 불리는 격리 수준은 snapshot isolation을 사용한다. 다른 데이터베이스(예, MySQL)의 repeatable read와 동일한 수준이고, write skew가 발생할 수 있으므로 serializability를 달성했다고 할 수 없다.
• AID
  • Atomicity: abortability가 더 적당한 단어일 수 있음. 트랜잭션이 중간에 실패하면 데이터를 원상복구 할 수 있는 것을 말한다. 멀티스레드 프로그래밍의 atomic operation과는 다르다.
    • B-Tree는 write ahead log로 구현
    • LSM-Tree는 원래부터 로그 기반임.
  • Isolation: 트랜잭션이 다른 트랜잭션이 수정한 데이터를 볼 수 없다. 복수의 트랜잭션이 서로의 영향을 받지 않는다.
    • lock으로 구현
  • Durability: 커밋한 트랜잭션의 변경사항은 하드웨어 fault나 데이터베이스 crash가 발생해도 사라지지 않는다.
    • B-Tree는 write ahead log로 구현
    • LSM-Tree는 원래부터 로그 기반임.
• 분산 데이터베이스에서 트랜잭션을 구현하지 못할 근본적인 장애물은 없다 (현실적인 장애물은 있겠지만).
• Isolation levels
  • Read Committed
    • 예방하는 문제: Dirty reads, Dirty writes
    • row-level lock으로 해결함
  • Repeatable Read
    • 예방하는 문제
      • Read skew (nonrepeatable read라고도 불림. 하나의 트랜잭션 안에서 변경하지 않은 값이 조회하는 시점에 따라 달라지는 문제)
      • Lost update (2개의 스레드가 어떤 정수에 1씩 더했는데 +2가 아니라 +1이 되는 경우.. 고전적인 동시성 문제. MySQL InnoDB의 repeatable read는 이 문제를 예방하지 않으니 주의)
        • lost update를 예방하는 방법
          • write conflict가 감지되면 conflict를 만든 두 트랜잭션 중 하나를 취소하고 다시 시도한다 (MySQL InnoDB는 이런거 안해줌)
          • atomic write operation을 사용한다.
          • explicit lock을 사용하도록 쿼리를 작성한다 (SELECT FOR UPDATE)
    • Snapshot Isolation으로 해결함
      • readers never block writers, and writers never block readers
      • Snapshot Isolation은 MVCC(multi-version concurrency control)로 구현함
        • 트랜잭션마다 monotonic하게 증가하는 id를 부여하고, 트랜잭션의 id와 커밋 여부에 따라 다른 버전의 데이터를 조회한다.
        • 버저닝된 데이터는 생성만 할 뿐 변경되지 않는다.
        • 버저닝된 데이터에는 어떤 트랜잭션이 생성했고 어떤 트랜잭션이 지웠는지 기록한다.
        • 버저닝된 데이터를 조회할 수 있는 트랜잭션이 없어지면 데이터를 제거한다.
    • index는 변형된 B-Tree를 사용한다. append-only 혹은 copy-on-write가 적용된 B-Tree. 역시 데이터(페이지)를 업데이트 하지 않고 새로 추가한다.
    • Repeatable read는 데이터베이스마다 보장하는 범위가 달라서 그 누구도 정확한 정의를 모른다...
    • MySQL InnoDB는 phantom read를 gap lock으로 방지한다. 다른 DB에서는 serializable 수준에서 해주는건데... 좋네
  • Serializable
    • 예방하는 문제
      • write skew
        • 두 트랜잭션이 requirements와 관련된 �read 쿼리를 수행하고 requirements를 만족한 뒤 서로 다른 객체를 업데이트하는 상황에서 발생한다.
        • phantom: 하나의 트랜잭션이 변경한 데이터가 다른 트랜잭션의 search query의 결과를 바꾸는 경우. phantom의 특정 경우가 write skew를 유발한다.
    • 해결방법
      • 진짜로 serial하게 실행한다. single thread인 Redis가 이 방법을 사용함.
      • 2 Phase Locking(2PL)로 해결함. 하지만 성능 이슈 때문에 실제로 사용하긴 힘들다.
        • �writer의 lock이 reader도 block한다. reader의 lock도 writer를 block한다. 성능 이슈의 원인..
        • 트랜잭션이 한 번 잡은 락을 트랜잭션 중간에 해제하지 않고 커밋할 때 해제한다
        • where절에 범위가 들어있는 경우도 대응하기 위해 index-range locking(=next-key locking)으로 구현한다.
          • where절의 범위를 포함하는 더 큰 범위를 lock으로 잡는다. index를 통해서 range lock을 구현할 수 있음
      • Serializable Snapshot Isolation으로 해결함
        • readers never block writers, and writers never block readers
        • 비교적 최근에 나옴. 2PL보다는 성능이 훨씬 낫다
        • 낙관적 락 기법을 사용함. 트랜잭션을 일단 진행하고 conflict가 감지되면 retry를 한다.
        • 트랜잭션을 커밋하기 전에 해당 트랜잭션이 변경한 데이터를 다른 트랜잭션이 읽었는지 확인한다.
        • TODO: 구현방법 조금 더 정리..
        • TODO: SSI를 사용할 때 주의사항 정리..

[harrisleesh]

우빈쌤 : mysQL innoDB는 팬텀리드가 rr로 해소가능, gap lock 이 있다구!!
명재쌤 : index-range-lock 인가요!

[harrisleesh]

지우쌤 : https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html#innodb-gap-locks

[harrisleesh]

당근지우쌤 : 갭락이랑 넥스트키락 뭐가 다른거죠?