Web/DataBase

[ Database - Intermediate ] - Lock을 활용한 concurrency control - 2PL(two-phase locking)

먼저 간단히 read-write lock에 대한 예시입니다. 우리는 이를 OS에서 많이 보았습니다. 먼저 read-lock은 read시에 획득하는 lock으로써 read_lock끼리는 동시에 이 lock에 접근할 수 있습니다. 그 이유는 read 끼리는 공유 자원을 변경하지 않기 때문이죠. 하지만 write-lock은 말 그대로 Mutex(Mutual Exclusion)을 만족시키게 하는 lock입니다. 그냥 일반적인 lock이라고 보시면 됩니다. 즉 아래와 같은 호환성 표를 이해할 수 있을 겁니다. lock을 써도 생기는 이상한 문제 위 두개의 트랜잭션이 있습니다. 한눈에 봐도 두개의 트랜잭션을 serial하게 실행하면 결괏값이 달라질 수 있다는건 알 수 있을 겁니다. 만약 위처럼 그럼 동시에 실행해보..

[ Database - Intermediate ] - Isolation level

위와같은 상황을 다시 한번 리마인드 해보겠습니다. 흐름도를 보면, x=10, y=20에서 시작해서 x는 write(y=70)된 다음 y값을 읽어서 80으로 갱신한다음에 commit했는데, tx2는 abort가 되어 x의 값이 좀 이상해지게 되는데 즉 이를 Dirty read(commit 되지 않은 변화를 읽음) 입니다. 그리고 만약 tx1이 x를 두번 읽는데, 같은 데이터의 값을 달라지는 아래와 같은 상황을 보겠습니다. 이는 isolation 관점에서 봤을 때. isolation은 마치 트랜잭션이 고립된 환경에서 실행되어야 하는데, x를 읽었더니 값이 달라지게 되면 이는 좀 이상합니다. 그리고 우리는 이를 Non-repeatable read, Fuzzy read라고 합니다. 그리고 위와같이 없던 데이터가..

[ Database - Intermediate ] - concurrency control (schedule, serializability, recoverability )

바로 트랜잭션에서 동시성을 관리하는 방법에 대해 알아보겠습니다. 우선 이전 상황을 가정할 것인데요, K가 H에게 20만원을 이체할 때 H도 ATM에서 본인 계좌에 30만원을 입금하는 상황입니다. 이러한 상황에서는 여러 형태의 실행이 가능할 수 있습니다. 위와같이 20만원 -> 30만원 트랜잭션 순서로 실행될 수 있습니다. 또한 30만원 -> 20만원 순서로 실행될 수 있습니다. 위와같이 중간에 30만원 트랜잭션이 실행될 수도 있습니다. 그리고 이전에 봤던것 처럼 기존의 30만원입금이 씹히는 즉 Lost update 현상이 나타나는 케이스도 있을 수 있습니다. 우리는 이제부터 위 하나하나의 명령어를 operation이라고 정의해보겠습니다. 그리고 이 operation을 짧게 나타내서 case 4를 아래와같..

[ Database - Intermediate ] - transaction

만약 위와같은 이체라는 작업을 한다고 해 봅시다. 이는 원자성있게 동시에 성공했을 때 "이체" 라는 작업이 성공한 것이 될겁니다. 이러한 이체라는 작업은 둘 다 정상 처리돼야만 성공하는 단일 작업이라는 것입니다. 이러한 것을 Transaction이라고 합니다. 즉 논리적인 이유로 여러 SQL문들을 단일 작업으로 묶어서 나눠질 수 없게 만든 것이 transaction입니다. START TRANSACTION; UPDATE account SET balance = balance - 200000 WHERE id = 'J'; UPDATE account SET balance = balance + 200000 WHERE id = 'H'; COMMIT; 이런식으로 transaction을 만들고 SQL구문을 작성해주고 맨..