| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 12. 동시성 제어 | Fast Forward | Next |
표준 SQL는 트랜잭션 격리의 4 레벨을 동시에 실행되는 트랜잭션들 간에 방지되어야 할 3가지 현상들의 관점에서 정의합니다. 이러한 바람직하지 않은 현상들은 아래와 같습니다.
4개의 트랜잭션 격리 레벨과 대응하는 동작은 Table 12-1에 설명되어 있습니다.
Table 12-1. SQL트랜잭션 격리 레벨
| 격리 레벨 | Dirty Read | Nonrepeatable Read | Phantom Read |
|---|---|---|---|
| 처리되지 않은 읽기 | 가능 | 가능 | 가능 |
| 읽기 처리됨 | 불가능 | 가능 | 가능 |
| Repeatable read | 불가능 | 불가능 | 가능 |
| 직렬화 | 불가능 | 불가능 | 불가능 |
PostgreSQL에서는, 4개의 표준 트랜잭션 격리 레벨을 모두 요구할 수 있습니다. 그러나 내부적으로는, Read Committed와 Serializable에 대응하는 2개의 독립한 격리 레벨만이 있습니다. Read Committed 레벨을 선택했을 때, 실제로는 Read Committed가 되어, Repeatable Read를 선택했을 때, 실제로 직렬화되게 됩니다. 이와 같이 실제의 격리 레벨은 선택한 레벨보다 엄밀하게 되는 일이 있습니다. 이것은 표준 SQL에서도 허가되고 있습니다. 이 4개의 격리 레벨에 대해서는, 발생해서는 안 되는 현상만이 정의되어 발생해야 하는 현상은 정의되고 있지 않습니다. PostgreSQL가 2개의 격리 레벨만을 제공하고 있는 이유는, 다중버전 동시성 제어 구조에 표준의 격리 레벨을 관련짓는 실제적인 방법이 이것 밖에 없기 때문입니다. 이용 가능한 격리 레벨에 대해서는 다음에 상세하게 설명합니다.
트랜잭션의 트랜잭션 격리 레벨을 설정하려면 SET TRANSACTION 커멘드를 사용해 주십시요.
PostgreSQL에서는 Read Committed가 디폴트의 격리 레벨입니다. 트랜잭션이 이 격리 레벨로 실행되면, SELECT쿼리는 쿼리가 실행되기 전까지 처리된 데이터만을 참조합니다. 아직 처리되지 않은 데이터나 쿼리의 실행 중에 동시 트랜잭션에 의해 처리된 갱신은 참조하지 않습니다 (그러나 SELECT문은 자기 자신의 트랜잭션 내에서 실행되고 갱신된 결과는 비록 아직 처리되지 않아도 참조합니다). 결과적으로, SELECT쿼리는 그 쿼리가 실행을 개시한 시점의 데이터베이스의 snapshot을 참조하게 됩니다. 하나의 트랜잭션 내에서 만나도 SELECT문이 2회 연속해 발행했을 경우, 최초의SELECT 커맨드를 처리하고 있는 중간에 다른 트랜잭션의 갱신이 처리되면, 최초와 그 다음에 발행한SELECT쿼리는 다른 데이터를 참조해 버리는 것을 주의하십시요.
UPDATE, DELETE, SELECT FOR UPDATE, 및 SELECT FOR SHARE커멘드는 대상 행을 검색할 때 SELECT커멘드와 같이 행동합니다. 이러한 커멘드는, 쿼리가 개시된 시점에서 이미 처리되고 있는 대상 행만을 발견합니다. 그러나 대상 행은 발견 될 때까지, 다른 동시 트랜잭션에 의해 이미 갱신(혹은 삭제나 락)되어 버렸을지도 모릅니다. 이러한 경우 갱신되어야 할 처리는, 최초로 갱신된 트랜잭션이(아직 진행 중 이라면) 처리 혹은 롤백(rollback) 하는 것을 기다립니다. 최초의 갱신 처리가 롤백(rollback) 되면 그 결과는 무시되어, 2번째의 갱신 처리로 원래 발견한 행의 갱신을 계속할 수 있습니다. 최초의 갱신 처리가 처리되면, 2번째의 갱신 처리에서는, 최초의 갱신 처리에 의해 행이 삭제되었을 경우는 그 행을 무시합니다. 최초의 갱신 처리가 삭제하면, 행의 업데이트된 버전에 연산되도록 적용될 것입니다. 커멘드의 검색 조건(WHERE구문)은, 갱신된 행이 검색 조건에 일치하는지 확인하기 위해 재평가됩니다. 검색 조건과 일치하는 경우, 2번째의 갱신 처리는, 갱신된 행으로부터 처리를 개시합니다. (SELECT FOR UPDATE및 SELECT FOR SHARE의 경우, 락 되고 클라이언트에 리턴되는 것은 갱신된 버전의 행을 의미합니다. )
이러한 구조에 의해 업데이트된 커멘드가, 서로 모순된 snapshot을 참조할 가능성이 있습니다. 이러한 쿼리는, 서로가 갱신하려고 하는, 같은 행에 영향을 미치는, 동시 실행 중인 갱신 쿼리에 의한 결과를 참조할 수 있지만, 데이터베이스의 다른 행에 대한 동시 실행의 쿼리 결과는 참조할 수 없습니다. 이러한 동작을 하기 위해서 복합 검색 조건을 포함한 쿼리에 Read Committed 모드를 사용하는 것은 적절하지는 않습니다. 그러나 보다 단순한 검색 조건의 경우, 이 모드의 사용은 적합합니다. 예를 들어, 은행의 잔고를 갱신하는 이하와 같은 트랜잭션을 생각해 보겠습니다.
BEGIN; UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 12345; UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 7534; COMMIT;
동시에 실행되는 2개의 트랜잭션이, 계좌 번호 12345의 잔고를 변경하려고 했을 경우, 계좌 12345의 행이 갱신되고 나서 2번째의 트랜잭션을 개시해야 합니다. 각 커멘드가 사전에 결정한 행에만 처리를 실시하기 때문에, 갱신된 버전의 행은 문제가 되는 불일치를 일으키지 않습니다.
Read Committed 모드에서 각각의 새로운 커멘드는 그 시점에 처리되는 모든 트랜잭션을 포함한 신규 snapshot을 사용해 실행을 개시합니다. 때문에 동일 트랜잭션 내의 다음 커멘드는 어떠한 경우에도 처리된 동시 트랜잭션의 결과를 참조하게 됩니다. 이 문제의 포인트는 하나 의 커멘드 내에서, 완전하게 일관된 데이터베이스의 뷰를 참조하고 있는가 하는 것입니다.
Read Committed 모드로 제공되고 있는 부분적인 트랜잭션 격리는 많은 어플리케이션에 적합합니다. 그리고 이 모드는 빠르며 사용법도 간단합니다. 그러나 복잡한 쿼리나 갱신을 실시하는 어플리케이션에서는, Read Committed 모드로 제공되는 것보다, 데이터베이스에 대해서 엄밀하게 일관성이 있는 보이는 방법을 보증할 필요가 있을지도 모릅니다.
Serializable레벨은, 트랜잭션의 격리에서 가장 엄격한 것입니다. 이 레벨에서는 트랜잭션이 동시에 일어나기 보다는 잇달아, 마치 순서대로 실행되도록 연속적인 트랜잭션의 실행을 에뮬레이트합니다. 그러나 이 레벨을 사용한 어플리케이션에서는, 직렬화의 실패에 의한 트랜잭션 재실행을 준비해 둘 필요가 있습니다.
트랜잭션이 Serializable 격리 레벨에 있을 때SELECT쿼리를 실행하면, 트랜잭션이 개시되기 전까지 처리된 데이터만을 참조합니다. 처리되지 않은 데이터나 트랜잭션의 실행 중에 다른 트랜잭션으로 갱신된 데이터는 참조하지 않습니다 (그러나 SELECT은 트랜잭션 내에 아직 처리되지 않은 데이터를 참조합니다). SELECT은 트랜잭션 내의 쿼리가 시작한 시점이 아닌, 트랜잭션 그 자체가 시작되었을 때 상태의 snapshot을 참조한다는 점으로써 Read Committed 레벨과는 다릅니다. 따라서, 단일 트랜잭션 내에 연속하는SELECT 커맨드는 항상 같은 데이터를 참조하고 있게 됩니다.
UPDATE, DELETE, SELECT FOR UPDATE, 및 SELECT FOR SHARE커멘드에서는 SELECT와 같이 대상 행을 검색합니다. 이러한 커멘드는 트랜잭션이 개시된 시점에서 처리되고 있는 대상 행만을 발견합니다. 그러나 그 대상 행은 발견 될 때까지 다른 동시 트랜잭션에 의해 이미 갱신(혹은 삭제나 락)됐을 가능성이 있습니다. 이러한 경우, serializable 트랜잭션은 최초의 갱신 트랜잭션이(아직 진행 중일 경우) 처리 혹은 롤백(rollback) 하는 것을 기다립니다. 최초의 갱신 처리가 롤백(rollback) 되면, 그 결과는 무시되어 serializable 트랜잭션에서는 원래 발견한 행의 갱신을 계속할 수 있습니다. 그러나 최초의 갱신이 처리(그리고 단지 락 될 뿐 아니라, 실제로 행이 갱신 또는 삭제)되면, serializable 트랜잭션에서는 이하와 같은 메세지를 출력해 롤백(rollback)를 실시합니다.
ERROR: could not serialize access due to concurrent update
왜냐하면 serializable 트랜잭션은 트랜잭션이 개시된 후, 다른 트랜잭션에 의해 갱신된 행을 변경하거나 락 할 수가 없기 때문입니다.
어플리케이션이 이러한 에러 메세지를 받아들였을 경우, 현재의 트랜잭션을 중단하고, 트랜잭션 전체를 다시 시작해야 합니다. 2 번째는 트랜잭션이 이전에 처리된 변경을 데이터베이스의 최초 상태로 간주하므로, 새로운 버전의 행을 새로운 트랜잭션의 갱신를 위해 시작 시점에서 사용해도, 논리적 모순은 일어나지 않습니다.
갱신 트랜잭션만 재실행할 필요가 있을지도 모릅니다. read 전용 트랜잭션에서는 직렬화의 충돌이 결코 일어나지 않을 것입니다.
직렬화 모드에서 모든 트랜잭션이 일관된 데이터베이스 상태를 참조할 수 있는 것이 보증됩니다. 그러나 동시 업데이트가 연속된 실행을 유지하는 환상을 불가능하게 만들 때, 어플리케이션은 트랜잭션을 재실행할 준비를 해두어야만 합니다 복잡한 트랜잭션을 재실행할 때의 코스트를 무시할 수 없을 정도로 클 수 있으므로, 이 모드는 Read Committed 모드에서는 잘못한 결과를 줄 가능성이 있습니다 그러므로 복잡한 논리를 가지는 갱신 트랜잭션을 실행하는 경우에게만 사용하는 것을 추천합니다. 대부분의 경우, 직렬화 모드는 데이터베이스의 동일 뷰를 참조해야만 하는 몇몇의 연속하는 쿼리를 트랜잭션이 처리할 때 필요합니다.
"serializable"인 실행의 직관적 의미(그리고 수학적 정의)는 성공적으로 처리된 2개의 동시 트랜잭션이 엄격하게 연속적으로 실행될 것이라는 겁니다. 그러나 2 개의 트랜잭션 중 어느 쪽이 먼저 나타날까를 미리 예측하긴 어렵습니다. Table 12-1에 나타낸 직렬화할 수 없는 행동을 금지하는 것이 진정한 직렬성을 충분히 보증하지 않는 다는 것을 아는 것은 중요합니다. 그리고 실제 PostgreSQL의 serializable 모드는 이 점 때문에 직렬화 실행을 보증하지 않습니다 . 예를 들어, 아래와 같은 초기 데이터를 가지는mytab라고 하는 테이블을 생각해 보겠습니다.
class | value
-------+-------
1 | 10
1 | 20
2 | 100
2 | 200
serializable 트랜잭션 A가 계산한다고 가정하고
SELECT SUM(value) FROM mytab WHERE class = 1;
value에 결과(30)를 새로운 class = 2의 행에 삽입합니다. 동시에 serializable 트랜잭션 B는 이하를 계산합니다
SELECT SUM(value) FROM mytab WHERE class = 2;
그 결과로 300을 얻으며고 결과를 class = 1의 행에 삽입합니다. 그런 다음, 양쪽의 트랜잭션을 처리합니다. 여기에서는 전술의 직렬화할 수 없는 행동은 없습니다만, 어느 쪽을 먼저 직렬화했다고 해도 발생할 수 없는 결과가 됩니다. 만약 A가 B보다 전에 실행했다고 하면, B의 합계는 300이 아닌 330으로 계산됩니다. 이과 같이 다른 순서로 실행되더라도 A로 계산되는 합계는 다른 결과가 나옵니다.
수학적으로 올바른 직렬성을 보증하기 위해 데이터베이스 시스템은 술어 락(predicate locking) 처리를 강제적으로 실시할 필요가 있습니다. 이는 동시 실행하는 트랜잭션의 쿼리 WHERE조건에 일치하는 행을 다른 트랜잭션으로부터 삽입, 변경 할 수 없다는 것을 의미합니다. 예를 들어, 트랜잭션 A가 SELECT ... WHERE class = 1이라고 하는 쿼리를 실행했을 때, 술어 락(predicate locking) 처리 시스템은 트랜잭션 A가 처리될 때까지, 트랜잭션 B가 class가 새로운 행을 삽입하는 것을 금지합니다. [1] 모든 세션이 동시 트랜잭션으로 실행된 모든 쿼리의 세부 사항을 인식해야하므로, 이러한 락 처리 시스템의 실행은 복잡하고 비쌉니다. 그리고 실제로 대부분의 어플리케이션은 이러한 문제가 생길만한 연산을 하지 않으므로, 고가의 작업의 대부분은 쓸모가 없습니다. (확실히 위의 예는 억지로 생각해 낸 것으로, 실제 소프트웨어에서 행해질 가능성은 거의 없습니다). 따라서 PostgreSQL는 술어 락(predicate locking) 처리를 실행하고 있습니다.
직렬화 되지 않을 가능성이 있는 것이 실제로 장애가 될 경우는, 명시적 락 처리를 적절히 사용하여 문제를 해결할 수 있습니다. 이하의 단락에서 보다 상세하게 설명합니다.
| [1] |
기본적으로, 술어 락(predicate locking) 시스템은 입력되는 것을 제한하여 phantom read를 예방하고, MVCC는 읽히는 것을 제한하여 phantom read를 막습니다. |