포스트그래스큐엘! 이제 기다리기 게임을 끝냈다.

저자 : Joseph Mitchell (jmitchell@greatbridge.com)

번역 : 정재익 (advnace@advance.sarang.net)

원문 : http://softwaredev.earthweb.com/sdopen/article/0,,12077_877181,00.html

http://www.onlamp.com/lpt/a//onlamp/2001/05/25/postgresql_mvcc.html

이 글은 PostgreSQL 이 read-write waiting time 을 줄이는 MVCC (multi-version concurrency control) 에 대해 심도 깊게 들여다 본 글이다.

대기... 가장 힘든 부분이지 않은가?

제발 기다려 주세요... 그리고 기다리고, 또 기다리고... 데이터베이스를 흔들리게 하는 가장 성가진 문제 중의 하나는 사용자가 어느 시점에서 다른 누군가가 데이터베이스를 갱신하는 동안에 대기하여야 한다는 것일 것이다. 데이터베이스 시스템이 table-level, page-level, column-level 또는 row-level locking 어느 방법을 사용하던지간에 똑같은 문제는 발생한다: 읽기 (SELECT) 과정은 쓰기 (UPDATE) 과정이 끝날때까지 기다려야 하고, 쓰기과정은 (UPDATE) 읽기 (SELECT) 과정이 종료되길 기다려야 한다.

PostgreSQL 은 종종 상용 데이터베이스 중에서 선두 주자와 비교되기도 하는데 MVCC (multi-version concurrency control) 이라는 기법을 사용한다. MVCC 는 하나의 세션이 쓰기를 위해서 row 를 locking 하고 있는 동안에 다른 세션에서 전혀 영향을 받고 그 row 로 접근할 수 있는 row-level locking 을 제공한다. 종종 경량의 소스가 공개된 데이터베이스인 MySQL 이 MVCC 를 제공한다고 알려져 왔다. 그러나 MySQL 은 오로지 읽기에서만 table-locking 만을 제공하기 때문에 비교 대상이 되질 않는다. 이것이 PostgreSQL 이 더 뛰어난 이유이다.

PostgreSQL 에서는 읽기는 결코 쓰기가 끝날때까지 기다릴 필요가 없으며, 쓰기는 읽기가 끝날때까지 기달릴 필요도 없다. 나는 "PostgreSQL 에서는 "no-locking" 이 없다는 말을 들었다 나에게 PostgreSQL 의 MVCC 에 대해서 좀더 상세하게 설명해 달라" 는 말을 들었다.

다른 데이터베이스 시스템에서는 concurrency control 과 consistency 를 유지하기 위해서 lock 을 사용한다. 그러나 PostgreSQL 은 multi-version model 을 도입하기 시작했다. PostgreSQL 에서 version 이라고 하는 것은 어느 한 순간에서 어떤 자료의 snapshot 과 같은 것이다. 사용자가 테이블로 질의를 보낼 때마다 자료의 current version 이 발생하게 된다. 자연적으로, 만약 그들이 같은 질의를 테이블로 주게 되면 new version 이 발생하며, 어떤 자료는 변경된다. 데이터베이스에서 이와 같은 변화는 UPDATE, INSERT 또는 DELETE 명령 동안에 발생하게 된다.

전통적인 row-lovel locking 과 PostgreSQL 의 MVCC 간의 근본적인 차이는 사용자가 특정 테이블로 부터 다음과 같은 예제를 통해 자료를 볼수 있는 가 없는 가 하는 것이다.

SELECT headlines FROM news_items

이 예제에서는, 명령어는 news_items 라는 테이블로 부터 자료를 읽어서, 모든 row 의 headlines 라는 컬럼을 출력해 줄것이다. row-level locking 을 사용하는 데이터 시스템에서는, SELECT 구문은 실패하고, 사용자는 다른 사용자가 동시에 실행중인 테이블 news items 로 자료의 삽입 (INSERT) 또는 자료의 갱신 (UPDATE) 이 끝날때 까지 기다려야 한다. 트랜젝션은 row 에 lock 를 걸고, 잠시 대기하게 되며, 다른 사용자가 lock 을 해제할 때까지는 테이블의 모든 row 들은 출력될 수 없게 되는 것이다. 자료를 읽을 때 너무 자주 lock 을 사용하게 되면 사용자에게 이 locking 구조가 많은 실망감을 안겨 줄것이다.

반면에 PostgreSQL 은 lock 이 해제될 때까지 대기하는 것을 없앰으로서, 모든 사용자가 news_items 테이블 내의 자료를 동시에 볼수 있도록 허용해 준다. 이것은 여러명의 사용자가 동시에 자료의 삽입 또는 갱신 작업을 하는 동안에라도 가능하게 한다. 사용자가 SELECT 질의를 주게 되면, PostgreSQL 은 사용자가 commit 하기 전에 가졌던 자료를 가지고 snapshot (실제로는 version) 을 출력하여 준다. 모든 자료의 갱신 또는 삽입은 실행중인 트랜젝션의 일부이며, 질의가 시작된 후에 commit 되어 진 자료는 출력되지 않는다. 정말 기발하지 않은가?

A Closer Look

row-level locking 을 사용하는 데이터베이스 시스템은 구 버전의 자료는 포함시키지 않기 때문에, data consistency 를 유지하기 위해서는 lock 을 사용해야 한다. 그러나 PostgreSQL 에서 MVCC 가 동작하는 과정에 어떻게 "no locking" 인가 하는 것을 좀더 깊이 들여다 보면, 어떻게 PostgreSQL이 이러한 한계를 가지게 되는가 하는 것을 알수 있다. PostgreSQL 에서 각각의 row 는 두개의 transaction ID 를 가지게 된다. 그것은 row 를 생성될 때의 creation transaction ID 와 row 가 소멸될 때의 expiration transaction ID 이렇게 두개이다. PostgreSQL 에서 누군가가 UPDATE 를 행하게 되면, 새로운 row 가 생성되고, 이전 것은 소멸된다. 이것은 같은 row 이지만, 다른 version 이다. 데이터베이스 시스템이 구버전을 보존 하지 않지만, PostgreSQL 은 row 의 새로운 version 을 생성하는 동안에 이전의 소멸된 version 도 보관하게 된다.

이것이 PostgreSQL이 data 의 version 을 생성하는 방법이다. 그러나 어느 version 이 display 될 것인지 어떻게 알것인가? 이것은 몇가지 기준에 의해서 출력하게 된다. 질의가 시작될 때 PostgreSQL 은 1) 현재의 transaction ID 와 2) 진행중인 모든 transaction ID 두가지를 기록하게 된다. 누군가가 데이터로 접근하게 되면 PostgreSQL 은 다음 기준을 만족하는 모든 row version 을 출력할 query 를 생성하게 된다: row 의 creattion transaction ID 가 comitt ㅗ딘 트랜젝션인가, 그리고 이것이 현재의 transaction counter 보다 적은가, 그리고 row 에 expiration transaction ID 가 없는가, 또는 expiration transaction ID 가 질의가 시작할때 진행중이었는가?

그리고 이것이 MVCC 가 가진 강력한 힘이다. 이것은 PostgreSQL 에서 data 의 version 을 유지하게 하며, lock 을 피할수 있도록 해 준다. 이것은 대단히 논리적이며, 트랜젝션을 다루는데 있어서 대단히 효율적이다. 새로운 PostgreSQL 사용자는 row-level locking 을 조절하는 MVCC 의 퍼포먼스에 대단히 놀라게 된다. 특히 다중 사용자 환경에서는 더더욱 그러하다.

MVCC 의 다른 장점은 hot-backup 이다. 많은 데이터베이스 시스템들이 백업을 하는 동안 database 를 shutdown 시키던지 또는 consistent snapshot 을 얻기 위해서 모든 테이블에 lock 을 걸게 된다. 그러나 PostgreSQL 은 그렇지 않다. MVCC 는 데이터베이스가 동작 중인 동안에 완전한 백업이 가능하도록 해 준다. 이것은 단순히 데이터베이스 전체의 snapshot 을 얻록 해서 자료가 삽입, 삭제, 갱신 하는 동안에도 덤프가 되도록 함으로서 가능한 것이다.

결론적으로 말해서 PostgreSQL 의 MVCC 를 사용함으로서 실제로 얻는 지는 이익은 대단히 많다. 특히 트랜젝션이 많이 걸리는 상황에서는 대단히 효율적이다. 그러나 나의 세상에서는 왜 그렇지 않은가? 만약 PostgreSQL 의 multi-version model 이 row-level locking 보다 더 좋다는 것을 알게 된다면, 스스로 시도해 보기 바란다.