오래 못 할 짓 하지 않기

1. 중복 데이터 문제 테이블에는 위와 같은 정보를 하나의 테이블로 만들었다. 이런 테이블에 데이터를 추가해보자 위와 같이 공통적으로 같이 들어가는 경우가 생길 수가 있다. 이런 경우에는 [ 저장 공간 낭비 / 실수로 인한 데이터 불일치 가능성 ] 문제가 생긴다. 만약 부서가 정해지지 않은 직원이 있을 경우에는? 부서에 관련된 부분은 모두 Null로 해야한다. 이번에는 임직원이 한 명도 없는 부서를 입력하려면? 이런 경우에는 직원 관련된 attribute에 모두 null이 들어간다. 이런 일이 생기는 이유 별개의 관심사가 한 테이블에 있기 때문이다. 이와 같이 두 개의 테이블로 나누면 위에 있었던 문제와 Deletion , Edit 등을 수행할 때 발생하는 문제까지 해결 가능하다. 2. Spurious ..

Locking Read MYSQL에서는 Lost Update를 Locking read 라는 기능을 이용하여 해결한다. 다음 쿼리문 같이 끝에 For Update를 붙이면 Lock 획득에 관련해서 Read , Write 둘 다 같은 Lock을 사용한다. Select ... For Update; ▶ Exclusive Lock을 가진다. = 읽고 있으면 다른 곳에서 읽는 것도 안 됨 Select ... For Share; ▶ Shared Lock을 가진다. = 쓰는 거만 동시에 안 하면 ㅇㅋ Write Skew ( In Repeatable read ) Tx 두 개를 실행시켜보자 해결법 Locking Read를 사용한다. PostSQL 에서는 데이터 수정 선빵친 놈이 있으면 늦은 놈이 Rollback Isola..

Lock 기반으로 동작하는 경우에는 Read하는 Tx끼리만 동시에 동작이 가능하다. MVCC 기반으로 동작하는 경우에는 Write만 동시에 동작하는 게 아니라면 다른 경우는 모두 동시에 동작이 가능하다. (이제부터 예시에는 Write Lock 이런 거 표시 안 함. 그냥 Write하면 Lock된 거임) (마찬가지로 Commit 되면 Unlock이 된 것) Tx2에서 x를 50으로 바꾸는데, 이게 Lock이 풀리기 전까지는 Tx2에서만 알 수 있는 공간에 x=50으로 저장해둔다. → 이 다음에 Tx1이 x값을 읽으면 Tx2에서만 알 수 있는 값인 50이 아니라 DB에 커밋되어있는 값인 10을 가져온다. 커밋되면 DB에도 50이 저장된다. Commit 을 할 때 Unlock하는 이유 = Recoverabil..

같은 x(데이터) 에 대해 Read / Write 가 있다면 정상적으로 작동하지 않을 것이다. LOCK의 역할이 이 때 쓰인다. : 데이터마다 LOCK이 있어서, 값을 수정하거나 읽기 위해서 LOCK을 취득해야한다. 그렇지 않다면 접근이 안 된다. 이 기술을 사용하여 동작하는 방식은 아래와 같다 읽는 거든 쓰는 거든 Lock은 필수다. Write Lock : Exclusive라는 특징을 가진다. Read를 하든 Write를 하든 하나의 Transaction만 가능하다. Read Lock : Shared라는 특징을 가진다. 다른 Transaction 이 read할 때 read는 같이 해도 됨. Write는 같이 X Read / Write Lock 예시 Tx2 에서 Read Lock을 건다. > Tx1에서 ..

Transaction들이 동시에 실행될 때 발생할 수 있는 이상 현상들 Dirty read 이런 상황에서 Transaction 2번을 abort = rollback을 한다면? y = 20 이 된다. 하지만 Transaction 1번을 이미 commit 했기에 x=80으로 유지된다. 이와 같이 (Rollback이 되어서) Commit 되지 않은 변화를 읽어서 생기는 현상을 Dirty read 라고 한다. Non-repeatable read 하나의 Transaction 에서 읽은 x의 값이 다르다. 이는 Isolation 관점에서 올바르지 않은 현상이다. Isolation은 여러 transaction이 동시에 실행되어도 같은 결과를 가져야하기 때문이다. 즉, Transaction 서로 영향을 받지 않고 독립..

Uncoverable Schedule 다음과 같이 schedule을 짰다고 해보자 이렇게 commit까지 한 상황에서 rollback을 하려고 한다고 생각해보자. Transaction 2번을 rollback을 하여, Transaction2가 실행되기 이전 상태인 200만원으로 돌려둔다. ▶ 그럼 Tx 2번은 더 이상 유효하지 않다. 따라서 이것과 Tx2에서 Write한 후 그 값을 읽은 Tx1도 Rollback해야한다. ▶ 하지만 Tx은 이미 commit된 상태이기 때문에 durability 속성에 의해 Rollback X [ Unrecoverable schedule ] Schedule 내에서 commit 된 Transaction이 Rollback된 Transaction이 write한 데이터를 읽은 경우..

저번 예제에 이어서... K가 H에게 20만원을 이체할 때 H도 본인 계좌에 30만원을 입금하면, 여러 형태의 실행이 가능할 수 있다. 가능한 Case 1. K에게 20을 받고, 본인에게 입금한 30넣고 2. 본인에게 30먼저 입금 , K가 H에게 20 입금 3. K가 송금 , 본인에게 30 추가 , K에게 받은 20 추 4. 1. K 잔고 확인 후 20만원 차감 2. H 잔고 확인 후 3. ( 본인 잔고 확인 후, 본인에게 30 추가 ) → 230만원 4. 2에서 확인한 값에서 20 추가 → 220만원 Transaction 을 이루고 있는 명령어 하나하나를 Operation이라고 한다. 그 Operation을 간략화 시킬 수 있는데 - Read = r - Write = w - Commit = c ▶ 그..

도입 예제 J가 H에게 20만원을 이체했을 때, 각자의 계좌는 어떻게 변하는가? 은행 입장에서는 이 두 가지 SQL문이 정상적으로 실행되어야 함. Transaction 둘 다 정상 처리되어야만 성공하는 단일 작업 ● 단일한 논리적인 작업 단위 ● 논리적인 이유로 여러 SQL문들을 단일 작업으로 묶어 나눠질 수 없게 만든 것 ● 일부만 성공하면 DB에 반영 X Transaction 형태는 ▶ Start Transaction; ▶ [' 실행하고 싶은 SQL문들 적기. '] ▶ COMMIT; // 지금까지 작업한 내용을 DB에 영구적으로 저장 + Transaction 종료 위 이체 관련 예제를 SQL에서 실행해보자 이런 뒤에 Start Transaction; update account SET balance =..

Trigger : DB에서 어떤 이벤트가 발생하면 실행되는(Trigger되는) Procedure = Insert Update Delete 예) USERS 테이블에 있는 사용자의 닉네임을 바꾸면 USERS_LOG 테이블에 이전 닉네임 + 언제까지 썼는지 업데이트하기 delimiter $$ ▶ Create TRIGGER log_user_nickname_trigger ▶ Before UPDATE // 언제 발생시킬거냐? = Update가 일어났을 때 ▶ On users FOR EACH ROW // users 테이블에서 변화가 발생하면 , Update가 되는 각 row에 대해 trigger 실행 ▶ Begin //프로시저 body에는 trigger 조건이 되었을 때 어떤 걸 실행할지 정한다. ▶ insert i..

Three-tier architecture ● Presentation : 보여지는 부분 담당 ● Logic : 서비스 관련 로직 담당 ● Data : 데이터 저장 및 관리 담당 당근마켓 예시로 Logic과 Data tier를 분석해보자 이렇게 Logic tier 에 기능이 들어가고 Data tier에 정보들이 담긴다 하지만 Data tier에서 사용되는 Stored procedure의 사용 목적은 비즈니스 로직 구현이다. 즉 Data tier 에 Business Logic을 넣는다는 것 Stored procedure의 장점 1) Application에 transparent하다. : 어떤 걸 바꾸어도 크게 틀을 바꾸지 않고도 내용을 바꿀 수 있다. = Procedure 없이 코드를 작성했을 시에는 모든 걸..