🔥6 - 데이터 베이스

📌 1. 정규화란?

이상 문제를 해결하기 위해 속성들끼리의 종속 관계를 분석하여 여러 relation으로 분해하는 과정

 

일반적으로 테이블을 여러개로 분리하면 속도는 상대적으로 저하되지만, 이상현상을 방지할 수 있다.

🔥 이상 문제

🌎 1. 삽입 이상

 

데이터를 저장할 때 원하는 않는 정보가 같이 삽입되는 경우

 

🌎 2. 갱신 이상

 

중복된 튜플 중 일부만 갱신하는 경우

 

🌎 3. 삭제 이상

 

삭제되지 말아야 할 정보도 같이 삭제되는 경우

https://nirsa.tistory.com/107

정규화의 단계

 

🌎 두부 이걸 다줘 ( 도부 이결 다조 )

 

1. 1차 정규화 : 도메인이 원자값

2. 2차 정규화 : 부분 함수 종속 제거

3. 3차 정규화 : 이항적 함수 제거

4. BCNF 정규화 : 결정자인데, 후보키가 아닌 것들 제거

5. 4차 정규화 : 다치종속 제거

6. 5차 정규화 : 조인종속 제거

📌 2. 샤딩 / 파티셔닝(단편화)

🔥 파티셔닝

큰 테이블이나 인덱스를 관리하기 쉬운 크기로 분리하는 방법

 

🌎 파티셔닝은 왜 생겨났는가?

 

하나의 DB에 모든 정보를 저장하는 것은 비효율적이다. 그래서 DB를 여러 대 운용하면서 '저장정보를 분산해보자' 라는 생각을 갖게 된다. 가장 쉽게 생각해 볼만 한 것은 Master DB의 데이터를 복제한 Slave DB를 두고 read를 분산하는 것이다. 그러나 이 방법으로 write는 분산되지 않는다. 

 

그래서 각각의 DB가 data를 일부분씩 나눠서 갖고 있도록 구성할 수 있는 파티셔닝의 형태를 생각하게 됐다.

 

[X테이블 -> A db] [Y 테이블 -> B db] 의 형태는 파티셔닝이 아니라, 단순히 다른 db에 테이블이 존재하는 것이다. 만약 X테이블에 트래픽이 몰린다면 결국 A db에만 트래픽이 몰리게 될 것이다.

 

[X테이블의 데이터 일부분 -> A db] [Y테이블의 데이터 일부분 -> B db] 형태로 나눠가지는 게 파티셔닝

 

🌎 파티셔닝은 테이블을 나눠 가지는 방식에 따라 수직 단편화 / 수평 단편화(=Sharding)로 나눌 수 있다.

🔥 샤딩 ( 수평단편화 )

검색을 용이하게 하기 위해 해당 데이터가 존재하는 db를 잘 찾아낼 수 있도록, 각 db에 공평하게 row가 분배되도록 하는 것이 중요하다.

🔥 수직단편화

엔티티를 분리할 때 처럼, 컬럼을 나눠 새로운 테이블을 만드는 것

 

이렇게 나누는 경우는 특정 테이블이 빈번히 참조될 때.

📌 3. Index 란?

테이블의 검색속도를 향상시키기 위한 자료구조

 

DB의 index는 책의 색인과 같다. ( Page )

 

index를 활용하지 않은 채 컬럼을 조회하려면 전체를 탐색하는 Full Scan을 이용해야 한다. Full Scan은 말 그대로 전체를 탐색하기 때문에 처리속도가 떨어진다.

DBMS 인덱스는 항상 정렬된 상태를 유지하기 때문에 원하는 값에 대한 탐색은 빠르지만, 삽입 삭제 갱신 등에는 쿼리문 실행속도가 떨어지게 된다.

https://k39335.tistory.com/26

🔥 장단점

🌎 장점

 

조회 속도를 올릴 수 있고, 전반적인 시스템 부하를 줄일 수 있다.

 

🌎 단점

 

인덱스를 관리하기 위한 추가적인 저장공간이 필요하다.

DELETE와 UPDATE 연산은 기존의 인덱스를 삭제하지 않고, '사용하지 않음' 처리를 해준다. 그래서 UPDATE와 DELETE 연산이 빈번하게 발생한다면 실제 데이터는 10만건이지만, index는 100만건을 넘을 수 있는 현상이 발생할 수 있다. 

🔥 인덱스 자료구조

🌎 Hash Table

 

Hash Table은 조회 시간이 O(1)일 정도로 빠르지만, 실제로 Index 자료구조로는 잘 사용되지 않는다. 그 이유는 Hash Table은 == 연산에만 최적화돼있고, 부등호 연산( < , > ) 에는 최적화 돼있지 않기 때문이다. 그래서 DB 인덱스에서는 B+ Tree가 일반적으로 사용된다.

 

🌎 B+ Tree

 

자식 노드가 2개 이상인 B- Tree를 개선시킨 자료구조.

 

https://mangkyu.tistory.com/96

B-트리, B+ 트리 참고
B-트리는 자식이 여러 개일수 있는 균형잡힌 트리,
B+트리는 B-트리에서 일어나는 순회작업의 단점을 개선시킨 트리라고 생각하면 될 것 같다.

https://wangin9.tistory.com/entry/B-tree-B-tree

📌 4. 트랜잭션이란?

데이터 베이스 상태를 변화시키기 위해서 수행하는 작업의 단위

여기서 작업의 단위는, 하나의 논리적 기능을 수행하기 위해서 한꺼번에 수행돼야 할 일련의 연산단위를 가르킨다.
https://coding-factory.tistory.com/226

🔥 4가지 원칙 : ACID

🌎 1. Atomicity 원자성

트랜잭션이 모두  DB에 반영되든가, 아니면 하나도 반영되지 않든가해야 한다.

 

🌎 2. Consistency 일관성

트랜잭션의 작업 처리의 결과가 항상 일관성이 있어야 한다.

 

🌎 3. Isolation 독립성

둘 이상의 트랜잭션이 병행 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션의 작업에 끼어들 수 없다.

 

🌎 4.Durability 지속성

트랜잭션이 성공적으로 완료됐을 경우, 결과는 영구적으로 반영돼야 한다.

https://mommoo.tistory.com/62

📌 5. Table Full Scan vs Index Range Scan

🌎 Table Full Scan : 해당 테이블 전체 블록을 읽어서 데이터를 가져오는 방식

🌎 Index Range Scan : 인덱스를 이용해서 ROWID로 데이터를 가져오는 방식

 

Table Full Scan의 경우 Multi Block I/O로 데이터를 읽기 때문에 프로세스가 데이터를 바로 처리할 수 있으나

Index Range Scan의 경우 Single Block I/O로 데이터를 읽기 때문에 데이터를 읽는 도중 I/O Call이 끝날 때까지 프로세스는 대기상태에 들어간다.

 

그래서 인접한 500개의 data를 찾을 경우에는 Table Full Scan이 빠를 수 있다.

참고 블로그
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=vefe&logNo=221402694129

인용 블로그
https://wedul.site/403

📌 6. 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

📌 7. 트랜잭션의 격리수준

트랜잭션 격리수준이란 동시에 여러 트랜잭션이 처리될 때, 트랜잭션끼리 얼마나 고립돼있는지를 나타내는 것.

즉, 특정 트랜잭션이 다른 트랜잭션을 볼 지 말지 결정하는 것.

🔥 격리수준 4가지

1. READ UNCOMMITED

2. READ COMMITED

3. REPEATABLE READ

4. SERIALIZABLE

🔥 1. Read UnCommitted

Commited 되지 않는 데이터에 접근이 가능한 것.

N개의 트랜잭션이 하나의 공유 데이터에 접근해도 전혀 보호되지 않는다.

이 단계에서는 🌎 Dirty Read 문제가 발생할 수 있다.

 

1. A 트랜잭션에서는 1번 사원의 나이를 27살에서 28살로 수정함.

2. 아직 커밋은 하지 않았음

3. B 트랜젝션에서 1번 사이의 나이를 조회

4. 28살이 조회된다.

🌎 이를 Dirty Read 라고 부른다.

5. A 트랜잭션에서 문제가 발생해서 ROLLBACK을 수행

6. B에서는 여전히 28살이 1번 사원의 나이라고 생각한다.

 

이런식으로 데이터 정합성에 문제가 많으므로, RDBMS 표준에서는 격리수준으로 인정하지도 않는다.

🔥 2. Read Committed

어떤 트랜잭션의 내용이 Commit 돼야만 다른 트랜잭션에서 조회가 가능

오라클 DBMS에서 Default 설정으로 사용하고 있고, 온라인 서비스에서 가장 많이 선택되는 격리수준이다.

 

1번 Read UnCommitted에서 생긴 Dirty Read 문제를 해결가능하다.

그러나 다른 문제가 야기될 수 있다.

 

🌎 NON - REPETABLE READ ( 데이터 부정합 문제 )

 

하나의 트랜잭션 내에서 똑같은 SELECT 문을 실행했을 경우, 항상 같은 결과를 실행해야 한다 = Repeatable READ 정합성

 

1. B 트랜잭션에서 1번 사원의 나이를 조회

2. 27살이 조회됐다

3. A트랜잭션에서 1번 사원의 나이를 27살에서 28살로 바꾸고 커밋

4. B 트랜잭션에서 다시 1번 사원의 나이를 조회

5. 28살이 조회

 

이 문제는 특히, 금전과 관련한 부분에서 문제를 야기할 수 있다.

🔥 3. REPEATABLE READ

트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 조회할 수 있는 격리수준

 

자신의 트랜잭션 번호보다 낮은 트랜잭션 번호에서 변경된(Commit 된) 것만 보게되는 것

 

🌎 1. UPDATE 부정합

 

UPDATE 이상 현상

 

🌎 2. Phantom READ

 

첫 번째에는 없던 유령 레코드가 두번 째 쿼리에서 나타나는 현상

🔥 4. Serializable

읽기 작업에도 공유 잠금을 설정하는 상태

동시에 다른 트랜잭션에서 레코드를 변경할 수 없다.

 

동시처리 능력이 다른 격리수준보다 떨어지고, 성능저하가 발생하게 된다.

인용 블로그
https://joont92.github.io/db/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B2%A9%EB%A6%AC-%EC%88%98%EC%A4%80-isolation-level/

참고 블로그
https://private-space.tistory.com/97

📌 8. 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

🌎 SQL이 나은 경우

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

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

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

관리하기 쉽다.

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

 

🌎 NoSQL이 나은 경우

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

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

 

 

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