재정리 - 🔥 db

📌 1. 트랜잭션 격리레벨

🔥 READ UNCOMMITTED

• Commit이나 rollback 여부에 상관없이 다른 트랜잭션에서 값을 읽을 수 있다.
• 정합성- 에 문제가 많다
• dirty read

🔥 READ COMMITTED

• RDB 대부분 기본값
• 실제 테이블의 값을 가져오는게 아니라, Undo 영역에 백업된 레코드에서 값을 가져온다.
• 두 트랜잭션이 하나의 table을 수정할 때, 하나의 트랜잭션이 값을 수정한 이후 다른 트랜잭션에서 작업이 끝나기 전 commit을 하면 , 아직 끝나지 않은 트랜잭션에서 값을 읽어들이면 값이 달라진다.
• 이는 항상 같은 값을 가져와야 하는 REAPEATABLE READ의 정합성에 위반 --> 버그 발생 위험도 증가

🔥 REAPEATABLE READ

• 트랜잭션마다 ID를 부여해서, 해당 트랜잭션의 ID보다 작은 번호의 ID에서 변경된 것만 읽을 수 있게 한다.
• Phantom read 발생가능. ( 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보이는 상황 )

🔥 Serializable

• 읽기에도 공유 잠금을 걸어놓는 상태

https://nesoy.github.io/articles/2019-05/Database-Transaction-isolation

📌 2. global transaction - XA - 2PC

🔥 2pc

• Two- Phase - Commit
• begin -> end -> commit 으로 이루어지는 1PC와 달리, 2PC는 begin -> end -> prepare -> commit 중간에 prepare을 두었다. prepare을 두는 이유는 전산 시스템에서 결과 반영을 하고 나면 되돌리기가 어렵기 때문에 먼저 결과반영이 되지 않도록 하는 예방책이다.
• 분산 DB의 트랜잭션을 처리하기 위한 방법
• blocking이 일어난다는 단점이 있다.

자료1 - 대부분
https://weicomes.tistory.com/378
자료2 - 단점
https://dongwooklee96.github.io/post/2021/03/26/two-phase-commit-%EC%9D%B4%EB%9E%80/
자료3 - 참고
https://heni.tistory.com/10

📌 3. index

• 책의 색인과 같은 구조를 한다.
• 만약 10000개의 자료가 있다고 해보자. 만약 책 이름이 java를 검색한다고 하면, 10000개의 자료에 대해서 full scan (brute force)을 할 것이다. 
• 인덱스도 결국 하나의 테이블이다.
• 동작과정은 아래 링크 참조 ( category - rowid table 을 따로 만듬 )
• 내부적으로 B-tree를 이용하기 때문에, 순차적으로 조회하는 것보다 훨씬 빠르다.

https://itholic.github.io/database-index/

---

• 인덱스는 테이블 부분에 대한 하나의 사본이다. 인덱스는 보통 key-field만 갖고 있다.
• 인덱스는 특정 column값을 갖고 있는 row를 검색하기 위해 사용된다.

https://itrainbowm.tistory.com/20

---

• INDEX를 해당 컬럼에 주게 되면 초기 table생성 시 만들어진 MYD, MYI, FRM 3개 의 파일 중에서 MYI에 해당 컬럼을 색인화해서 저장한다.
• SELECT 쿼리로 INDEX가 사용하는 쿼리를 사용시 해당 TABLE을 검색하는 것이 아니라, 빠른 TREE로 정리해둔 MYI 파일의 내용을 검색한다.
• 인덱스를 사용하지 않을 시 MYI 파일은 비어있게 된다.

⚡️ 참조

• MYD = MYsql Data file
• MYI  = MYsql Index file
• FRM = FoRMat file  ---> 테이블 구조

🔥 인덱스의 단점

추가적인 공간이 필요하다 ( 10% 정도 )

인덱스를 생성하는데 시간이 많이 소요될 수 있다.

데이터 변경이 자주 일어날 경우, 인덱스 역시 재작성 해줘야 하므로 성능에 영향이 있을 수 있다.

https://lalwr.blogspot.com/2016/02/db-index.html
https://dazemonkey.tistory.com/93

📌 4. 파티셔닝 vs 샤딩

🔥 파티셔닝 = 단편화

• 데이터가 많아 지면 관리가 힘들어지므로, 분산해서 관리하는 기법
• performance, availability, maintainability : 성능, 가용성, 유지보수성에 장점을 갖고자 단편화를 한다.
• Master - Slave 기법으로는 read는 분산되나, write가 분산이 안된다.
• X table -> A  // Y table -> B 는 파티셔닝이 아니다.
• X table 의 일부분 -> A // X table 일부분 -> B 처럼 테이블 안에 있는 내용을 분할해야 파티셔닝이다.

🔥 수직 단편화 (vertical partitioning)

• 특정 컬럼이 빈번히 조회될 때 사용한다.

🔥 샤딩이란

What Is the Difference between Sharding and Partitioning?

Sharding and partitioning are both about breaking up a large data set into smaller subsets. The difference is that sharding implies the data is spread across multiple computers while partitioning does not. Partitioning is about grouping subsets of data within a single database instance. In many cases, the terms sharding and partitioning are even used synonymously, especially when preceded by the terms “horizontal” and “vertical.” Thus, “horizontal sharding” and “horizontal partitioning” can mean the same thing.

• 샤딩 = 파티셔닝의 한 종류 = 수평 파티셔닝

Partitioning is more a generic term for dividing data across tables or databases. Sharding is one specific type of partitioning, part of what is called horizontal partitioning.

샤딩에 대해서
https://hazelcast.com/glossary/sharding/
https://stackoverflow.com/questions/20771435/database-sharding-vs-partitioning
글의 내용
https://umbum.dev/969

🔥 샤딩의 예

• 샤드키를 기준으로 분리한다.
• 만약 memberId 를 샤드키로 분리한다면, 0~1000번 1001~2000번 으로 data를 분리할 수 있다.

http://theeye.pe.kr/archives/1917

📌 5. RDB vs NOSQL

Not Only SQL의 약자로 RDBMS의 한계를 극복하기 위해 나온 수평적 확장성을 갖고 있는 database

 

고정되지 않는 table schema를 갖고 있고, 

 

대표적인 NoSQL로 Mongo DB, Redis를 들 수 있다.

Mongo DB는 document형태로 데이터를 저장, Redis는 Key-value 값으로 값을 저장한다.

 

RDBMS 방식에서는 Scale Up이라는 수직적 확장 방식을 사용한다. 이는 단일 서버의 데이터 양을 늘릴 수 있음을 의미한다.

No-SQL 방식에서는 Scale Out이라는 수평적 확장 구조를 사용한다. 그래서 리소스 풀에 더 많은 서버가 추가될 수 있다.

🔥 SQL vs NoSQL

⚡️ RDB- SQL이 나은 경우

무결성과 일관성이 핵심인 경우

ACID를 지키기 때문에 무결성, 유효성, 신뢰성 등이 뛰어나다.

그래서 은행권 등에서는 RDBMS를 사용한다.

관리하기 쉽다.

미리 정의해놓은 테이블이 더 좋은 효율을 낼 수 있다.

 

⚡️ NoSQL이 나은 경우

RDBMS처럼 구조화하고 고정된 Table을 갖지 않아도 되므로 대규모 데이터 조합을 처리할 때 SQL보다 낫다.

데이터 집합이 광범위할수록 NoSQL은 더 좋은 선택이다.

https://www.imaginarycloud.com/blog/sql-vs-nosql/

📌 6. 정규화

• 이상현상을 해결 및 방지하기 위해 테이블을 여러개로 쪼개는 행위
• 속도는 상대적으로 저하될 수 있지만, 이상현상을 방지할 수 있다.

🔥 이상현상

삽입, 삭제, 갱신 이상

=> 원하지 않는 정보가 들어가거나, 삭제되거나, 일부만 정보를 가져오는 경우

🔥 정규화의 단계

⚡️도부 이결 다조

 

⚡️ 1차 : 도메인이 원자값

• 하나의 컬럼에는 하나의 값만

⚡️ 2차 : 부분 함수 종속 제거

•  학번 학부 등록금 과목코드 성적

값이 위와 같이 있을 때, 학번과 학부는 등록금을 결정하고, 학번과 과목코드는 성적을 결정한다.

그래서 학번 학부 등록금 - 과목코드 성적 으로 테이블을 쪼갠다.

• 학번 과목번호 학년 성적

위의 예에서는 학년은 학번에만 종속적이다.

그래서 학번 - 학년과 학번 - 과목번호 - 성적으로 쪼개준다.

 

⚡️3차 : 이행적 함수 종속 제거

 

학번 학부 등록금에서 학번 -> 학부 / 학부 -> 등록금을 결정하므로, 학번이 등록금을 결정하는 구조처럼 보인다. 그런데 실제로 학번과 등록금은 관계가 없다.

그래서 학번 -> 학부와 학부->등록금을 쪼개준다.

 

⚡️BCNF : 결정자인데, 후보키가 아닌 것들 제거

 

학번 과목명 교수명

1     java    얼쑤

2    java    얼쑤

3    c#       희찬

 

위의 예에서 학번과 과목명이 교수명에 영향을 주고, 다시 교수명이 과목명에 영향을 주지만 교수명은 키가 아니다. 그래서 결정자인데 후보키가 아닌 것들을 제거한다.

 

⚡️4차 : 다치 종속 제거

 

개발자 언어 자격증

 

개발자 -> 언어

개발자 -> 자격증

 

⚡️5차 : 조인 종속 제거

 

만약 4차 정규화 이전의 data가 다음과 같다고 해보자.

개발자	언어	자격증
나	java	정보처리기사
나	c++	opic
희찬	java	빅데이터기사

이를 4차 정규화를 하게 되면 아래와 같은 테이블이 된다.

개발자	언어
나	java
나	c++
희찬	java

개발자	자격증
나	정보처리기사
나	opic
희찬	빅데이터기사

이 2개의 테이블을 합치게 되면 아래와 같이 x2가 돼버리는 문제가 발생한다.

개발자	언어	자격증
나	java	정보처리기사
나	java	opic
나	c++	정보처리기사
나	c++	opic
희찬	java	빅데이터기사

이를 해결하는 방법은 자격증-언어 테이블도 따로 만들어서 관계를 명확히 하는 것이다.

https://nirsa.tistory.com/107
+ 정보처리기사에서 공부했던 자료

📌 7. Lock

DB는 데이터를 영속적으로 저장하고 있는 시스템

 

같은 자원에 대해서 동시에 접근하려고 하면 데이터의 오염이 발생할 수 있고, 데이터의 일관성과 무결성이 깨질 수 있다.

 

수강신청 때 만 명이 신청했는데, 마지막 9999명 때 2명이 동시에 버튼을 눌렀다고 하면, 이 때 Lock을 걸어 DB의 시스템을 보호한다.

 

⚡️ Lock이란 트랜잭션 처리의 순차성을 보장하기 위한 방법

🔥 공유락 ( Shared Lock )

데이터를 읽을 때 사용되는 Lock

 

공유락은 공유 lock 끼리는 동시에 접근이 가능하다. 하나의 데이터에 여러 사용자가 접근할 수 있다는 의미.

그러나 공유락이 걸린 것에 동시에 베타락을 걸 수는 없다.

🔥 베타락 ( Exclusive Lock )

베타 Lock은 데이터를 변경하고자 할 때 사용되며, 트랜잭션이 완료될 때까지 유지된다. 베타락은 해제될 때까지 다른 트랜잭션(읽기포함)은 접근할 수 없다.

🔥 Blocking

블로킹은 Lock간의 경합 ( 베타-베타 , 베타-공유 )이 발생해서 특정 Transaction이 진행하지 못하고 멈춰있는 상태

블로킹을 해소하기 위해서는 이전의 트랜잭션이 완료(Commit OR Rollback )돼야한다.

뒤에 들어온 Transaction은 이전 Transaction이 마무리 돼야 진행될 수 있다.

 

Blocking 상황에서 Deadlock 상황이 발생할 수 있다.

https://sabarada.tistory.com/121

📌 8. query execution plan

• 사용자가 SQL을 실행하여 data를 추출하려고 할 때, Optimizer가 수립하는 작업절차를 뜻한다.
• Optimizer의 실행단계는 3단계로 분리할 수 있다.

1. SQL 해석

2. 실행계획 수립

3. 실행

https://swjeong.tistory.com/143