[프리온보딩 백엔드 챌린지 2월] Week 1-2 ) Transaction, ACID, Lock, Isolation Level

https://www.wanted.co.kr/events/pre_challenge_be_4

프리온보딩 백엔드 챌린지 2월 | 원티드

 

---

오라클은 유료라 MySQL을 사용하기도 함

 

 

Transaction : 업무의 최소 단위

본인이 이용하는 프레임워크의 트랜잭션을 잘 찾아볼 것(ORM)

ORM(Object Relational Mapping)

 - 객체와 관계형 데이터베이스의 데이터를 자동으로 연결해주는 것

 - 직접 SQL문을 작성하지 않음

 - Java ORM : JPA

raw query가 sql injection에 취약함

 

 

 

 

 

ACID

데이터베이스 내에서 일어나는 하나의 트랜잭션의 안정성을 보장하기 위해 필요한 성질

Atomicity (원자성) : 트랜잭션은 모두 성공하거나, 전부 실패돼야 함 (All or Nothing)

Consistency (일관성) : 트랜잭션 이전과 이후, 데이터베이스의 상태는 이전과 같이 유효해야 함

Isolation (고립성) : 트랜잭션은 다른 트랜잭션으로부터 독립되어야 함

Durability (지속성) : 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함

 

 

 

 

 

MySQL 스토리지 엔진

어떤 스토리지 엔진을 쓰냐에 따라 데이터 읽기/쓰기가 달라짐 (디폴트는 InnoDB)

- MyISAM : 테이블의 인덱스는 키 캐시를 이용해 디스크를 검색하지 않고도 빠르게 검색할 수 있음

- MEMORY : 서버가 꺼지면 날라가기 때문에 쓸 일이 거의 없을 것, 요즘은 temp 사용

- InnoDB

Buffer Pool : 테이블이나 인덱스 데이터를 캐시하는 메모리 영역. 데이터를 메모리에서 직접 액세스하여 I/O 작업 시 속도가 빠름.

트랜잭션과 외래키 지원

 

myisam에서는 중복된 값을 제외한 나머지가 insert 됐는데

innodb에서는 중복된 값이 있기 때문에 아예 명령어가 실행되지 않았음

 

SHOW CREATE TABLE : 테이블이 어떻게 생성됐는지 보여주는 명령어

 

- Undo log (임시저장공간)

insert, update, delete 등을 수행할 때 undo log에 옮겨놓고

에러가 나서 트랜잭션이 실행되지 않을 때 undo log를 다시 가져옴

 

 

 

Database Lock

트랜잭션 처리의 순차성을 보장하기 위한 방법

MySQL에서 알아서 해주기 때문에 직접 할 일은 없음

- 글로벌 락

  서버 전체에 락을 거는 것 (read 가능, write 불가)

  FLUSH TABLES WITH READ LOCK

- 테이블 락

  read lock : 데이터를 읽어오는 동안 변경 작업을 수행하지 못하게 함

  write lock : 데이터를 변경하는 동안 읽기 작업을 수행하지 못하게 함

- 네임드 락

  임의의 문자열로 잠금을 설정함

  자주 쓰진 않음, 특수한 상황에서 사용

- 메타데이터 락 : db 이름 변경, 컬럼 이름 변경 등에 사용

 

innodb lock

- 레코드 락

  테이블의 레코드에 락을 거는 것, read 할 때 알아서 걸림

  -> index와 테이블의 구조를 잘 짜는 것이 중요

- auto increment lock : auto increment를 하나씩만 할 수 있도록

 

dead lock : 교착 상태

 

 

 

 

isolation level (트랜잭션간의 격리)

innodb에서는 repeatable read

 

- read uncommitted (== dirty read)

  commit 하지 않았는데 read가 됨

- read committed

  트랜잭션이 완료된 데이터만 조회 가능

  커밋 전에는 undolog의 데이터를 읽어옴

  unrepeatable read : 처음 읽은 값과 나중에 읽은 값이 다름

- repeatable read

  트랜잭션마다 ID를 부여하여, 작은 트랜잭션ID에서 변경한 것만 읽음(undo 영역에 백업된 데이터를 이용)

  phantom read : 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다 안보였다 하는 현상

- serializable

  거의 사용되지 않음

  read lock을 걸면 아무것도 못함

 

 

 

 

---