데이터베이스 트랜잭션(Transaction)에 대하여 알아보자!

시작하기 전에

해당 블로그에 작성되는 글은 주인장의 지극히 주관적인 생각이 다수이며, 대부분의 지식은 구글링을 통해 얻고 있기 때문에 옳지않은 정보가 있습니다. 

잘못된 부분이나 수정해야 하는 부분이 있다면 과감히 덧글을 남겨주세요! 모르는게 많은 새싹입니다

오늘의 주제

오늘의 주제는 일을 하다 우연히 사용하게된! Node.js의 mysql 모듈 중,  트랜잭션(Transacation)을 관리하는 기능에 대해서 포스팅을 하려고 합니다.

재밋게 읽어주세요!

우선, 글을 읽으려면 알아갈 주제에 대해서 지식을 쌓고 가는게 중요하다고 생각합니다. 그렇다면 오늘 포스팅할 트랜잭션에 대해 알아봅시다!

트랜잭션(Transaction) 이란?

"데이터베이스 작업이 일어나는 하나의 단위" 이다. 우리는 하나의 기능을 실행할 때 하나의 쿼리문만 실행하지는 않는다.(물론 하나만 사용할 때도 있다.)  예를들어 로그인 기능을 살펴 보았을 때 1. 요청받은 로그인 정보를 조회(Select) 하고, 2. 미등록 회원이라면 회원가입을 시킨다. (Insert)

이처럼 하나의 뭉치의 데이터 베이스 작업이 일어나는 동안에는 다양한 쿼리가 발생할 수 있고, 작업들은 데이터베이스 특징에 맞춰서 이루어 져야 한다. 이렇게 데이터베이스 작업이 이루어지는 하나의 작업 단위를 트랜잭션 이라고 한다.

데이터베이스 특징

데이터 베이스의 특징은 4가지로 분류된다. 수업시간에도 많이 들어보았고, 정보처리기사를 준비하며 많이 보았던 것들이다.

• 원자성(Atmoity)
• 독립성(Isolation)
• 일관성(Consistency)
• 지속성(Durability)

원자성(Atomity)이란? 이름에서 처럼 데이터베이스의 작업 단위는 하나의 덩어리로 움직여야 한다는 것이다. 작업의 실행 과정에서 총 5개의 쿼리가 작동한다고 가정할 때, 1번과 2번은 성공 3번 작업에서 실패를 한다고 해서, 1번과 2번의 작업이 데이터 베이스에 적용 되어서는 안된다. 즉, 하나의 트랜잭션과정에서 모든 데이터베이스의 작업이 반영되거나, 반영되어서는 아니된다. 

이러한 특성을 원자성(Atomity)의 "All or Nothing "이라고 한다.  이러한 All or Nothing은 트랜잭션의 RollBack과 Commit에 의해 유지된다.

독립성(Isolation)이란? 여러개의 트랜잭션 과정이 동시에 발생하더라도, 하나의 트랜잭션 과정은 다른 트랙잭션의 침범(?)을 받아서는 아니됩니다. 

트랜잭션이 진행되는 과정에서 다른 트랜잭션의 침범을 받게 되면 복구되어야 하는 경우에 복구할 수 없게 됩니다. 이러한 경우를 방지하기 위해  트랜잭션은 독립성을 유지하게 됩니다.

일관성(Consistency)이란? 데이터베이스 작업이 일어난 후에도 데이터의 총량은 같아야 함을 나타냅니다. 적다보니 말이 좀 이상한데, 이해하기 쉽게 예를 하나 들어봅시다.

탕구리(무직, level 15)는 무기를 사기 위해 상점에 가게 됩니다.

  어맛!  무기상점에서 SUPEX 강한 활(  15,000 GOLD ,재고량 : 100)을 팔고 있네요? 

SYSTEM : 탕구리님이 SUPEX 강한 활을 구매하셨습니다.

시스템 전체 활 보유량 => 탕구리 1EA , 무기상점 99EA ( 총량 : 100EA)

이렇게 데이터베이스는 하나의  거래과정이 이루어진 후에도 "SPUEX 강한 활"의 총 개수는 100개로 유지됩니다. 데이터의 총 개수가 일관성 있다고 말할 수 있죠. 이렇게 트랜잭션은 데이터가 처리되는 과정에서 데이터의 일관성을 유지하여 줍니다.

지속성(Durability)이란?트랜잭션이 성공적으로 완료되어 커밋되고 나면, 해당 트랜잭션에 의한 모든 변경은 향후에 어떤 소프트웨어나 하드웨어 장애가 발생되더라도 보존되어야 한다는 내용입니다.

트랜잭션 버퍼 관리자 & 버퍼 관리 정책

데이터베이스 시스템은 보통 비휘발성 저장 장치인 디스크에 데이터를 저장합니다. 데이터베이스의 일부분은 메인 메모리에 유지 되기도 합니다.  DBMS에서는 데이터를 고정 길이의 페이지(Page)로 저장하며 페이지(Page)는 데이터가 입출력 되는 단위가 됩니다.

이렇게 데이터를 저장하고 있는 다량의 페이지들을 관리하는 모듈을 페이지 버퍼 관리자 또는 버퍼 관리자라고 칭합니다. 

버퍼 관리자는 DBMS의 모듈 중 일부이다. DBMS는 크게 질의 처리기(Query Processor)와 저장 시스템(Storage System)으로 구성되어 있으며 버퍼 관리자는 저장시스템 구성의 일부이다.

(저장시스템은 저희가 보통 알고있는 DB engine( ex. Mysql => MyISAM, InnoDB) 같은 것들입니다.)

버퍼 관리자는 버퍼 관리 정책에 따라 트랜잭션의 UNDO 복구와  REDO 복구가 요구되거나 그렇지 않게 됩니다.

UNDO = Rollback 

수정된 페이지들은 버퍼 교체 알고리즘에 의해 디스크에 출력되고, 버퍼는 버퍼의 상태에 따라 교체됩니다.

(1) 트랜잭션이 실행되면 수정된 페이지들이 디스크에 출력될 수 있는 상태가 되어야 합니다.

(2) 트랜잭션이 진행되며 수정한 페이지들도 디스크에 출력 될 수 있기 때문에, 중간에 트랜잭션이 실패한 경우 변경된 페이지들은 원상복구 되어야 합니다.

이렇게 진행 중이던 트랜잭션 과정을  원상태로 복구시키는 과정을 "UNDO" 라고 합니다.

UNDO의 정책은 두가지로 나뉘어 집니다.

1. 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책

2. 수정된 페이지들을 최소한 트랜잭션 종료 시점까지는 버퍼에 유지하는 정책

그럼 당연히 버퍼에 유지 시켜놨다. UNDO 발생시 되돌리는게 편한거 아니야? 라고 생각 하실 수 있지만 트랜잭션 종료 시점까지 버퍼에 유지하게 되면 많은 양의 버퍼가 필요하게 되므로 메모리 문제가 발생하게 됩니다. 이러한 이유 때문에 대부분의 DBMS는 1번의 정책을 사용합니다.

REDO

일반적으로 REDO와 UNDO는 반대개념으로 많이 생각합니다. 이미 커밋된 트랜잭션의 수정을 재반영하는 복구 작업을 REDO 복구라고 합니다.

DBMS에서 이루어지는 작업은 REDO LOG에 기록됩니다.(이 기록에는 UNDO의 내용도 포함됩니다.) 시스템에 장애가 발생하였을 경우 REDO Log에 기록되 내용을 기반으로  Check Point 장애지점 까지의 DB Buffer Cache를 복구하게 됩니다. 제 생각엔 복구를 위해 Log 기록을 재실행 하는 행위를 "REDO"라고 말하는 것 같습니다. 

이 과정이 완료되면 UNDO 과정을 통해 Commit 되지 않은 데이터를 복구하게 됩니다.

REDO의 경우에는 트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 페이지들을 디스크에 쓸 것 인지 아닌지 두가지의 정책으로 구분됩니다.

1. 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책

2. 수정했던 페이지를 트랜잭션 커밋  시점에 디스크에 반영하지 않는 정책

디스크에 반영하게 되면 사실상 REDO 복구는 필요가 없게 됩니다. 

디스크에 수정한 페이지가 반영되지 않는다고 하더라도 어떤 작업을 했는지 로그에 전부 기록되기 때문에 필요시 REDO, UNDO 작업이 가능하게 됩니다.

* 출처

네이버 D2 : http://d2.naver.com/helloworld/407507

그루비 :  http://wiki.oracleclub.com/display/CORE/Undo , 

 http://wiki.oracleclub.com/display/CORE/Redo