- Transaction
- Transaction Isolation Level
- RDBMS vs NoSQL
- B-Tree / B+Tree
- olap vs oltp
- Redis
Transaction
정보의 교환이나 데이터베이스 갱신 등 연관되는 작업들에 대한 일련의 연산으로, 데이터베이스의 상태를 변화시키기 위해 수행하는 작업 단위
-
상태를 변화시킨다는 것 → SQL 질의어를 통해 DB에 접근하는 것
-
작업 단위 → 많은 SQL 명령문들을 사람이 정하는 기준에 따라 정하는 것
즉, 한꺼번에 모두 수행되어야 하는 일련의 연산들로, 쪼갤 수 없는 업무 처리의 최소 단위이다.
트랜잭션의 목적
- 데이터 부정합 방지
- 데이터베이스 서버에 여러 개의 클라이언트가 동시에 엑세스하는 경우
- 응용 프로그램이 갱신을 처리하는 과정에서 중단될 수 있는 경우
- 데이터베이스의 완전성(integrity) 유지 확신
- 데이터베이스가 수행한 일부 쿼리가 남으면 안 됨
ex) 송금시 한 계좌에서 인출 → 다른 계좌에서 입금 확인 - 트랜잭션은 서로 간섭하면 안 됨
ex) 쿼리 하나 실패 → 데이터베이스 시스템이 전체 트랜잭션 또는 실패한 쿼리 롤백
- 데이터베이스가 수행한 일부 쿼리가 남으면 안 됨
- 거래의 안정성 확보
- 테이블에서 데이터를 읽어옴
→ 다른 테이블에 데이터 입력/갱신/삭제 도중 오류 발생
→ 모든 작업 원상태로 복구 - 처리 과정이 모두 성공했을 때만 최종적으로 데이터베이스에 반영
- 테이블에서 데이터를 읽어옴
트랜잭션 특징
1. 원자성 (Atomicity)
- 트랜잭션 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.
- 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.
2. 일관성 (Consistency)
- 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환된다.
- 시스템이 가지고 있는 고정 요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.
3. 독립성 (Isolation)
- 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우, 어느 하나의 트랜잭션 실행 중 다른 트랜잭션의 연산이 끼어들 수 없다.
- 수행 중인 트랜잭션은 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.
- 기본적인 개념은 위와 같으나, 격리 수준에 따라 수행 결과 참조 가능 여부가 달라진다.
4. 영구성 (Durability)
- 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.
트랜잭션 연산
All or Nothing
트랜잭션은 모든 것을 수행하거나 아무것도 하지 않는 방식으로 DML 명령어들을 처리한다.
트랜잭션의 연산으로는 Commit과 Rollback이 있다.
1. 커밋(commit)
- 모든 작업들을 정상적으로 처리하겠다고 확정하는 명령어
- 처리 과정을 데이터베이스에 영구적으로 저장
- 커밋 수행 후
- 하나의 트랜잭션 과정 종료
- 이전 데이터가 완전히 업데이트 됨
2. 롤백(rollback)
- 작업 중 문제 발생으로 인해 트랜잭션의 처리 과정에서 발생한 변경 사항을 취소하는 명령어
- 트랜잭션의 일부가 정상적으로 처리되어도 트랜잭션이 행한 모든 연산을 취소 → 원자성 구현
- 트랜잭션이 시작되기 이전의 상태로 되돌림
- 마지막 커밋 완료한 시점으로 되돌아 감
- 마지막으로 수행한 커밋 명령까지만 정상 처리된 상태로 유지
- 커밋하여 저장한 것만 복구
- 해당 트랜잭션을 재시작 혹은 폐기
- 마지막으로 수행한 커밋 명령 이후 수행한 모든 DML 명령어 작업들을 취소시켜 이전 상태로 원상 복귀
3. 세이브포인트(save point)
- 임시저장, 부분저장
- 전체가 아닌 특정 부분에서 트랜잭션을 취소하기 위해 사용
- 현재의 트랜잭션을 작게 분할하는 것이 가능
- 여러 개의 SQL문 실행을 수행하는 트랜잭션의 경우, 사용자가 트랜잭션 중간 단계에서 지정 가능
- 취소 지점 명시 → 그 지점까지 작업 취소
- 사용 방법
SAVEPOINT 세이브포인트명;
→ 세이브포인트 지정ROLLBACK TO 세이브포인트명;
→ 해당 세이브포인트 지점까지 처리한 작업 롤백
트랜잭션의 상태
- 활동(Active): 트랜잭션이 실행중인 상태
- 실패(Failed): 트랜잭션 실행에 오류가 발생하여 중단된 상태
- 철회(Aborted): 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태
- 부분 완료(Partially Committed): 트랜잭션의 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태
- 완료(Committed): 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태
트랜잭션 복구
1. UNDO
- 컴퓨터로 무언가를 작업할 때 마음에 들지 않아 조금 전으로 되돌리고 싶을 때 행하는 작업
- "방금 전에 했던 일을 취소"
- 아직 완료되지 않은 트랜잭션이 수정한 페이지들도 디스크에 출력될 수 있으므로, 해당 트랜잭션이 어떤 이유든 정상적으로 종료될 수 없게 되면 트랜잭션이 변경한 페이지들은 원상 복구 되어야 한다.
- 사용자가 했던 작업을 반대(원상태)로 복구
- 무효화
2. REDO
- UNDO로 취소했던 작업을 마음이 바뀌어 다시 되돌리는 작업
- "취소를 취소"
- 이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업
- 사용자가 했던 작업을 그래도 다시 복구
3. 비교
4. 방법
트랜잭션 철회
시스템은 정상적으로 동작하고 있으며, 특정 트랜잭션만 철회하는 경우
- 로그를 역방향 탐색하면서 해당 트랜잭션의 UNDO 복구가 필요한 로그를 찾아 이에 해당하는 UNDO 연산 수행
- UNDO 작업에 대한 REDO 전용 로그 기록
- 이전 로그를 계속 탐색하면서 해당 트랜잭션의 시작 로그까지 도달
재시작 복구(restart recovery)
장애 발생 이후 데이터베이스 시스템이 재시작 복구 하는 경우
1. 로그 분석 단계
마지막 체크포인트 시점부터 최근 로그까지 로그를 탐색하면서 시스템 복구 시작 지점, 복구해야할 트랜잭션 등을 알아냄
2. REDO 복구 단계
복구 시작 시점부터 장애 발생 직전 시점까지 REDO가 필요한 모든 로그를 REDO 복구
3. UNDO 복구 단계
로그를 최신 시점부터 다시 역방향으로 탐색하면서 UNDO 복구가 필요한 로그들에 대해 UNDO 복구 수행
→ 여러 트랜잭션 철회 (Global UNDO)
Transaction 관리를 위한 DBMS의 전략
1. DBMS의 구조
- Query Processor (질의 처리기)와 Storage System (저장 시스템)으로 구성
- 입출력 단위: 고정 길이의 page 단위로 disk에 읽거나 쓴다.
- 저장 공간: 비휘발성 저장 장치인 disk에 저장, 일부분을 Main Memory에 저장한다.
2. Page buffer Manager or Buffer Manager
DBMS의 Storage System에 속하는 모듈 중 하나로, Main Memory에 유지하는 페이지를 관리하는 모듈이다.
Buffer 관리 정책에 따라, UNDO 복구와 REDO 복구가 요구되거나 그렇지 않게되므로, transaction 관리에 매우 중요한 결정을 가져온다.
oltp vs olap
OLTP (Online Transaction Processing)
OLTP를 직역하면 온라인 트랜잭션 처리를 의미한다.
복잡하게 말하면 복수의 사용자 PC에서 발생되는 트랜잭션을 DB서버가 처리하고, 그 결과를 요청한 사용자PC에 결과값을 되돌려주는 과정을 뜻한다. 쉽게 말해, 1개의 요청작업을 처리하는 과정을 OLTP라고 생각하면 편하다.
예를들어, 은행에 돈을 입금하는 과정을 생각해보면 약 3단계의 처리과정을 거쳐야 한다. 1단계는 돈과 카드를 은행원분께 전달하는 과정 2단계는 은행원분이 돈과 카드를 확인한 후 입금을 진행하는 과정 3단계는 입금이 확인된 내역을 확인하는 과정이다. 이 3개의 단계는 중간에 그만두면 안되는 과정이며 모든 단계가 완벽하게 끝나야 한다. 이 3개의 단계를 1개의 요청작업(트랜잭션)으로 본다면 OLTP는 이 과정을 완벽하게 처리함을 의미한다.
즉, 중간에 예상치 못한 변수로 2단계까지만 작업이 진행되고 멈추게 된다면 지금까지 진행된 1,2단계를 무효화 시켜야 한다. (이 과정을 Rollback이라고 한다.) 또한, 1,2,3단계의 작업이 정상적으로 진행되면 작업을 확정해야 한다. (이 과정을 Commit이라고 한다.) 돈이 입금되었다고 통장에 찍혀있지만, 실제로 돈이 입금되지 않으면 곤란할 것이다.
이처럼 OLTP의 의미는 무수히 많이 발생되는 각각의 작업요청을 오류없이 처리하고, 그 결과값을 실시간으로 확인시켜줘야 함을 의미한다. 조금 복잡하게 말하면 1개의 트랜잭션에서 발생되는 INSERT, UPDATE, DELETE 과정의 무결성을 보장하여 처리하고 그 결과를 SELECT 하는 과정을 OLTP라고 한다.
OLAP (Online Analytical Processing)
단어 그대로 생각해보면 온라인 분석 처리로 해석할 수 있다. OLTP가 데이터 자체의 처리에 중점이 된 용어라면, OLAP는 이미 저장된 데이터를 기반하여 분석하는데 중점이 된 용어이다.
OLAP는 데이터 웨어하우스(DW), 쉽게 말해 DB에 저장되어 있는 데이터를 분석하고, 데이터 분석을 통해 사용자에게 유의미한 정보를 제공해주는 처리방법을 의미한다. 나아가 이런 유의미한 정보를 바탕으로 보다 복잡한 모델링을 가능하게 한다.
OLAP의 이해를 돕기 위한 예를 들어보면, 만약 여러분이 회사의 대표라고 가정해보자.
1년동안 열심히 일을 했고, 1년이 끝나는 시기에 돈은 얼마나 벌었는지, 어디에 얼마만큼의 돈을 썼는지 표로 정리하고 싶다. 해당 자료를 얻기 위해 우선 필요한 것은 1년동안 사용한 내역서가 필요할 것이다. 먼저 1년동안 거래된 통장거래내역을 확보하고 이 통장거래내역을 바탕으로 수입과, 지출금액을 나누고, 다시 지출금액은 항목별로 나눠서 계산을 한다. 사람이 직접 1년 동안 벌어들인 금액과 지출항목별 금액을 정리할 수도 있지만 일일이 수작업으로 확인하다보면 정확하지 않을수도 있다. OLAP은 사람이 일일이 수작업으로 확인해야 하는 이 작업을 컴퓨터로 자료를 추출하고 분석하여 제공하는 과정을 의미한다.
즉, OLAP은 기존에 저장되어 있는 데이터를 사용자의 요구와 목적에 맞게 분석하여 정보를 제공하는 개념을 의미한다.
OLTP와 OLAP의 차이점
위의 2가지 개념은 비슷해 보이지만 전혀 다른 의미로 사용된다.
OLTP는 현재의 데이터 처리가 얼마나 정확하고, 무결한지가 중요하다. 그렇기 때문에 주로 데이터의 저장, 삭제, 수정 등의 실질적인 데이터를 수정하는 작업을 의미하는 용어이다.
OLAP는 이미 저장된 데이터를 바탕으로 어떤 정보를 제공하는지가 중요하다. 따라서 OLAP는 데이터가 무결하고, 정확하다는 전재를 바탕으로 고객 또는 사용자가 원하는 정보를 어떤식으로 표현하고 제공하는지를 의미하는 용어이다.
이 2가지 용어를 보면 알 수 있지만, 먼저 선행되어야할 부분은 바로 OLTP이다.
위의 예를 바탕으로 설명하면, 통장에 돈을 입금하는 행위가 오류가 없고, 무결해야만 OLAP에서 예로 들었던 1년간의 수입과 지출 분석이 유의미하다. 만약 OLTP 작업이 비정상적이었다면 OLAP로 아무리 멋진 자료를 만들어봤자, 그 자료는 자료로써의 가치를 상실하게 될 것이다.
OLTP는 보다 컴퓨터와 가까운 용어이고, OLAP는 보다 사용자에 가까운 용어라는 생각을 가지고 계신다면 2가지 용어에 대한 이해는 충분할 것이다.
아래는 OLTP와 OLAP의 차이점에 대해 표로 정리한 내용이다.
Reference
