DB 내용정리

SQL : structured query language의 약자

DDL : 테이블이나 관계의 구조 생성하는데 사용되는 데이터 정의어

DML : 테이블의 데이터를 검색, 삼입, 수정, 삭제하는데 사용되는 데이터 조작어

DCL : 데이터의 사용 권한을 관리하는데 사용되는 데이터 제의어

TCL : 트랜젝션을 제어하는 명령인 rollback, commit

DCL : 권한을 주는 데이터 제의어

DROP : 테이블 자체를 삭제, rollback 불가능 -> DDL

DELETE : 데이터만 삭제. rollback 가능 -> DML

TRUNCATE : 테이블을 최초 생성된 초기상태로 만듦. ROLLBACK 불가능. -> DDL

DBMS : 사용자와 데이터 베이스 사이에서 사용자의 요구에 따라 정보를 생성, DB를 관리해주는 소프트웨어

수직확장 : 늘어나는 부하를 처리하기 위해

수평확장 : 서버 수를 늘리고 동작하는 어플리케이션의 복제본을 실행해 이중화 , 삼중화 하는 방식으로 부하를 분산시켜주는 방식.

모놀리식의 경우 수평확장이 어렵지만, 컨테이너 기술을 통해 수평 확장 가능.

NOSQL : not only sql의 약자 , 기존 rdb의 한계 극복, 수평적인 확장 가능.

nosql 의 종류 :

key-value db : key, value로 저장되는 가장 간단한 형태

wide columnar store : column family 데이터 모델, 데이터 추가시 구조 변경이 필요없고 칼럼에 업데이트 하는 방식.

document db : json, xml 같은 collection 데이터모델 구조 채택

graph db : 그래프 이론을 바탕으로 노드, 엣지 , 프로퍼티로 연결되어있는 데이터를 저장하기 위한 nosql db. 객체 또는 노드로 불리는 데이터를 플롯, 그래프에서 이를 연결하여 데이터 네트워크 구척.

key

- 특정 튜플을 식별할때 사용하는 속성 또는 속성의 집합

- 릴레이션 간의 관계를 맺는데 사용

종류

- 슈퍼키 : 각 행을 유일하게 식별할 수있는 하나 또는 그 이상의 속성들의 집합 -> 슈퍼키에서 최소성을 만족해야 후보키가 될 수 있음.

- 후보키 : 튜플을 유일하게 식별할 수 있는 최소 속성들의 집합

- 유일성 : key로 하나의 튜플을 유일하게 식별

- 최소성 : 꼭 필요한 최소 속성으로 구성

- 기본키 :

- 후보키 중에서 선택해서 대표로 삼은 키

- null값이 들어가지 못함.

- 대체키

- 후보키 중에서 기본키가 안된 나머지 키

데이터베이스 무결성 제약조건

- 개체 무결성 제약조건 : 기본키를 구성하는 모든 속성은 null을 가져서는 안됨

- 참조 무결성 제약조건 : 외래키 값은 nul이거나 참조 테이블의 릴레이션의 기본키와 동일해야함.

-> 부모 테이블의 삭제 또는 수정시 제약을 받음

- restrict : 작업 중지

- cascade : 연쇄삭제

- set default : 초기 설정값으로 변경

- set null : null로 변경

도메인 무결성 제약조건 : 릴레이션 내 튜플은 각 속성의 도메인에 지정된 값만 가져야 한다는 조건

뷰 : 허용된 테이블을 제한적으로 보여주기 위해 하나 이상의 테이블에서 유도된 가상 테이블

장점 : 테이블의 구조를 보여주지 않아 보안이 좋음.

삽입/업데이트같은 명령을 허용하지 않아서 데이터 엑세스가 제한됨 -> 보안성에서 유리함 .

뷰의 데이터가 물리적으로 저장되는 곳이 없어서 리소스를 낭비하지 않을수 잇음.

단점 : 해당 뷰와 관련된 테이블을 삭제하면 뷰도 함께 삭제됨. 큰 테이블에 대해서 뷰를 만들때 많은 메모리 사용

인덱스

데이터를 쉽고 빠르게 찾을수 잇도록 <키, 포인터> 쌍으로 구성하는 데이터 구조

테이블 내 1개 혹은 여러개 칼럼을 이용해 구성하며 접근속도를 빠르게 해줌

인덱스를 사용해야하는 경우

- 데이터의 양이 많고 검색이 변경보다 빈번한 경우, 삭제에서도 성능 향상을 보여줌.

- 인덱스를 걸고자 하는 필드의 값이 다양한 값을 가지는 경우

단점 : 변경이 자주 발생한다면 성능 저하.

인덱스 구성을 위해 추가적인 저장공간 필요

인덱스 자료 구조 : hash table, b-tree, b+tree가 존재하지만, 주로 b+tree를 사용함.

hash table : 시간적인 평균복잡도가 O(1)로 속도면에서 유리한 부분이 존재.

하지만 해시함수를 재대로 정의하지않으면 데이터의 양이 많아짐에 따라서 시간 복잡도가 O(N)에 수렴하게됨.

또한 등호(=)연산에서는 유리하나, 부등호 연산(>,<)에서는 해시 테이블은 내부 데이터가 정렬되어있지않아서 탐색이 효율적이지 않음.

b-tree : 균형트리여서 최상위 루트노드에서 리프노드의 거리가 모두 동일하기 때문에 평균 복잡도는 O(logN)

그러나 갱신이 반복되다보면 트리의 균형이 깨지면서 성능이 악화됨.

b+tree : 말단의 리프노드에만 데이터 저장 + 리프 노드들이 링크드 리스트로 연결되어있음. 따라서 부등호를 이용한 순차검색에서도 장점을 가짐.

기본적으로 카디널리티가 높고, 중복도가 낮은 컬럼을 인덱싱하는 것이 유리함.

이상 현상

- 삽입 이상

- 데이터를 삽입할때 원하지않는 값들로 인해 삽입이 되지 않는 현상.

- 삭제 이상

- 튜플을 삭제할때 다른값들도 삭제되는 현상(연쇄 삭제)

- 갱신 이상

- 데이터가 일부만 갱신되어 불일치성 발생

정규화 , 비정규화

1정규형 : 모든 속성의 도메인이 원자값으로만 이루어짐

2정규형 : 기본키의 부분집합이 칼럼을 결정하지 않음

3정규형 : 이행함수종속을 피함. 기본키가 아닌 칼럼에 일반 칼럼이 종속되는 상황을 제거.

BCNF 정규형 : 모든 결정자는 후보키임.

4정규형 :

비정규화

장점

빠른 데이터 조회 -> join 비용 감소

데이터 조회 쿼리가 간단해짐 -> 버그 발생 가능성 하락

단점

삽입시에 삽입 비용이 높음

데이터간의 일관성 문제 발생

데이터를 중복 저장하여 더 많은 저장 공간이 필요

비정규화의 종류

- 테이블 통합 : 테이블의 조인이 많이 발생하는 경우

- 테이블 분할 : 특정 속성이나 레코드가 많이 사용되는 경우 테이블을 수직/수평 분할

- 중복 테이블 추가 : 여러 테이블에서 데이터를 자주 추출할때 차라리 하나의 중복 테이블을 추가하는 방법

- 중복 속성 추가 : 조인해서 데이터를 처리할때 데이터를 조회하는 경로를 단축하기 위해 사용.

트랜젝션 : 데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 단위

특징 : ACID

1. Atomicity - 원자성 : all or nothing

- 트랜젝션에 의해 변경되는 내역을 유지하면서, 이전에 commit 된 상태를 임시 영역에 따로 저장하여 보장함.

- 현재 수행하는 트랜젝션에 문제가 발생한 경우 전체를 날리고 임시 영역 상태로 롤백

- 롤백 세그먼트 : 이전 데이터들이 임시로 저장되는 영역

2. Consistency - 일관성 : 트랜젝션의 작업처리 결과는 항상 일관적이여야함

- 데이터 모델의 모든 제약조건을 만족하는 것을 통해 데이터의 일관성을 보장함

3. Isolation - 독립성 : 트랜젝션끼리는 서로 영향을 줄 수 없음

- 세마포어처럼 lock unlock을 통한 독립성 보장.

- lock, unlock을 통해 데이터에 대한 상호배제.

4. Durability - 지속성 : 성공적으로 반영된 트랜젝션은 영구적으로 반영되어야함

트랜젝션 격리 수준

동시에 여러 트랜젝션이 실행될때 트랜젝션끼리 얼마나 서로 고립되어 있는 지를 나타내는 수준

특정 트랜젝션이 다른 트랜젝션에 변경한 데이터를 볼 수 있도록 허용할지 말지를 결정

각 트랜젝션은 기본적으로 locking을 통해 독립적으로 수행하지만, 무조건 locking하면 동시성 측면에서 비효율이 심해서

적절한 고립수준으로 성능향상 가능.

1. read uncommited : 변경 내용이 commit/ rollback 여부에 상관없이 다른 트랜젝션에서 값을 읽을 수 있는 수준

-> dirty read 발생 : commit되지 않은 상태에서 값을 참조해서 정합성에 문제 발생

2. read commited : commit된 트랜젝션에 대해서만 값을 읽어서 참조

-> 주로 이 수준의 격리를 사용.

-> dirty read가 발생하지 않음.

-> undo영역에 백업해둔 레코드에서 값을 가져옴. non-repeatable read 문제 발생 -> 트랜젝션 실행 전과 실행후가 다름 -> ACID중 Consistency 위반. -> 하지만 이렇게 오래 지속되는 경우는 거의 없어서 해당방식이 표준으로 지정.

3. Repeatable read

- 트랜젝션마다 id를 부여하고 트랜젝션 id보다 작은 트랜젝션 번호에서 변경한 것만 읽게함.

- undo 공간에 백업해둔 데이터를 사용.

- phantom read 문제가 발생

-> 다른 트랜젝션에서 수행한 변경 방법에 의해 레코드가 보였다 안보였다 하는 문제 발생.

4. serializable

- 다른 사용자는 트랜젝션 영역에 해당하는 데이터에 대한 수정 및 입력이 불가능.

- 가장 엄격한 격리 수준.

신뢰성 및 회복

1. 트랜젝션이 수행되는 동안 시스템에 오류 또는 물리적 문제가 발생하면 복구가 필요 -> 트랜젝션 내의 질의를 수행하면서 문제가 발생한 경우 -> rollback 수행

2. 시스템의 오류, 물리적문제의 경우 트랜젝션이 다시 실행되어야함 -> undo/redo 실행

checkpoint

1. 트랜젝션을 수행하면서 중간 중간 checkpoint 설정해서 성공적으로 수행되어 disk에 확실히 저장된 상태를 저장.

2. 회복 과정에서 너무 많이 돌아가지 않도록 하기위함

undo

1. 트랜젝션의 모든 작업을 하지않은 것으로 되돌림

2. failure 발생시 트랜젝션이 commit되지않고 계속 진행중일때 수행

redis

- ram에 저장해서 디스크 스캐닝없이 매우 빠르게 접근해서 사용

- key-value 기반의 nosql

- snapshot / aof 라는 백업 기능을 통해 휘발성을 막아줌