feat: [DB] RDB와 트랜잭션

DB/RDB&NoSQL.md

@@ -0,0 +1,38 @@
+# RDB와 NoSQL의 차이에 대해 설명해 주세요
+
+### RDB
+
+- RDB의 핵심적인 두 가지 특징
+    - 데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다
+        - 데이터 무결성과 일관성 보장
+    - 테이터는 관계를 통해 여러 테이블에 분산된다
+        - 정규화되어 저장. 중복을 최소화, 참조 무결성 유지
+        - 테이블 간 관계는 외래키로 정의
+
+### NoSQL
+
+- 스키마도, 관계도 없다
+- 데이터 중복을 허용한다
+
+## NoSQL의 강점과, 약점이 무엇인가요?
+
+- 장점
+    - 스키마가 없기 때문에 저장된 데이터를 조정하고, 새로운 필드를 추가하는 것에 유리함
+    - 데이터 자체가 각 애플리케이션에 필요한 형태로 저장되어, 데이터를 읽어오는 속도가 빠름
+- 단점
+    - 데이터 중복을 계속 업데이트해야 함
+    - 수정 시 모든 컬렉션에서 수행
+
+## RDB의 어떠한 특징 때문에 NoSQL에 비해 부하가 많이 걸릴 수 있을까요? (NoSQL이 무조건 RDB보다 빠르다는 것은 아닙니다)
+
+1. 트랜잭션 처리
+    1. ACID 트랜잭션을 보장하며, 연산과 로그 관리가 필요하다
+2. 관계 유지 - join
+3. 스키마 변경
+
+## NoSQL을 활용한 경험이 있나요? 있다면, 왜 RDB를 선택하지 않고 해당 DB를 선택했는지 설명해 주세요
+
+- JWT - Redis
+    - 대규모 처리에서 속도
+    - Key-Value
+    - TTL 관리

DB/Transaction&ACID.md

@@ -0,0 +1,41 @@
+# 트랜잭션이 무엇이고, ACID 원칙에 대해 설명해 주세요
+
+### 트랜잭션이란?
+
+- 데이터베이스의 상태를 변화시키기 위해 수행하는 작업 단위
+    - 상태를 변화시킨다는 것은?
+        - 쿼리를 통해 DB에 접근
+    - 작업 단위란?
+        - 많은 쿼리를 사람이 정하는 기준에 따라 정하는 것
+            - 송금시 → 차감 및 추가
+
+## ACID 원칙
+
+### 트랜잭션의 특징
+
+- Atomicity 원자성
+    - 트랜잭션이 DB에 모두 반영되거나, 반영되지 않아야함
+- Consistency 일관성
+    - 트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다
+- Isolation 독립성
+    - 둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 때, 어떤 트래잭션도 다른 트랜잭션 연산에 끼어들 수 없다
+- Durability 지속성
+    - 트랜잭션이 성공적으로 완료되었으면, 결과는 영구적으로 반영되어야 한다
+
+### DBMS가 지속성을 어떻게 보장할까요?
+
+- Write-Ahead Logging을 통해 실제 DB에 적용하기 전에 로그 파일에 기록
+- Checkpoint
+    - 주기적으로 체크포인트를 생성
+- Redo Logs
+    - 트랜잭션 커밋 시 변경 내용을 redo log에 기록
+- Replication
+    - 데이터를 여러 서버에 복제하여 장애 시에도 다른 복제본에서 데이터를 복구
+- Crash Recovery
+    - DB가 재시작되면 로그 파일과 체크포인트를 기반으로 미완료 트랜잭션을 롤백하고 완료된 트랜잭션을 적용
+
+### 읽기 작업에도 트랜잭션을 걸어야 할까요?
+
+- 일관된 스냅샷을 보장해야 하는 경우 - 데이터의 정확성
+- 읽기 후 쓰기 작업이 연결된 경우
+- 다중 읽기 작업이 일관성을 유지해야 하는 경우

DB/TransactionIsolactionLevel.md

@@ -0,0 +1,46 @@
+# 트랜잭션 격리 레벨에 대해 설명해 주세요
+
+## 격리 레벨과 필요성
+
+- 트랜잭션에서 일관성 없는 데이터를 허용하도록 하는 수준
+- 트랜잭션이 독립적인 수행을 해야함 → Locking을 통해 다른 트랜잭션이 관여하지 못하도록 막아야함
+    - 하지만 Locking으로 수많은 트랜잭션을 순서대로 처리하려한다면 성능은 낮을듯(Locking 범위를 줄여도)
+
+### 격리 레벨의 종류
+
+- Read Uncommitted (레벨 0)
+    - 트랜잭션 처리중이거나, 아직 Commit 되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용
+- Read Committed (레벨 1)
+    - 트랜잭션이 수행되는 동안 다른 트랜잭션이 접근할 수 없어 대기해야함
+        - Commit이 이루어진 트랜잭션만 조회 가능 (대부분의 서버 Default설정)
+- Repeatable Read (레벨 2)
+    - 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 불가능
+        - MySQL에서 Default로 사용하는 Isolation Level
+- Serializable (레벨 3)
+    - 다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 및 입력 불가능
+
+### 낮은 단계 Isolation Level을 활용할 때 발생하는 현상
+
+- Dirty Read
+    - 커밋되지 않은 수정 중인 데이터를 다른 트랜잭션에서 읽을 수 있도록하면 발생
+    - 다른 트랜잭션에 의한 변경사항을 보게됨
+    - Read Uncommitted
+- Non-Repeatable Read
+    - 한 트랜잭션에서 같은 쿼리를 두 번 수행할 때 그 사이에 다른 트랜잭션이 값을 수정 또는 삭제하면서 두 쿼리의 결과가 상이해짐 → 일관성이 깨짐
+    - Read Committed, Read Uncommitted
+- Phantom Read
+    - 한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때, 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타나는 현상
+    - 트랜잭션 도중 새로운 레코드 삽입을 허용하기 때문에 나타남
+    - Repeatable Read, Read Committed, Read Uncommitted
+
+### MySQL(InnoDB-스토리지 엔진)에서 Undo 영역과 Redo 영역에 대해 설명해 주세요
+
+- Undo 영역
+    - 트랜잭션이 변경한 데이터를 원래 상태로 되돌리기 위한 정보를 저장
+        - ROLLBACK이나 비정상 종료 대처
+    - 일관된 읽기를 지원
+        - 트랜잭션이 수행 중일 때 다른 트랜잭션에서 데이터를 읽을 경우 Undo 영역을 활용하여 변경 전 데이터를 제공
+    - 트랜잭션 실패시 데이터 복구
+- Redo 영역
+    - 커밋된 변경 사항을 영구적으로 저장하기 위한 정보를 기록
+    - 시스템 장애 발생 시 Redo 로그를 사용해 변경 사항을 재적용하여 지속성을 보장