[DB] DB의 클러스터링 인덱스 구조, 정규화

201890820 - DB

fsync()

메모리의 디스크 버퍼를 디스크와 동기화

starge engine

mysql은 default strage engine이 있다
- default는 바꿀 수 있다는 이야기!
원래 default가 mysql 재단에서 만든 MyISAM 엔진이었는데 InnoDB로 default가 바뀜
InnoDB는 트랜잭션을 지원하지만 MyISAM은 지원하지 않음

InnoDB

InnoDB는 Clustering Index 의 자료구조로 되어 있다

Clustering Index

PKIndex + Record Store
Index는 PK로 생성되고, Recored Store는 레코드를 순서대로 저장한다
page + record고, 그래서 컬럼 스토어가 아니라 레코드 스토어다
컬럼 별로 저장하지 않고, 레코드를 통으로 저장한다는 뜻이다
레코드 스토어는 관계형 DB, 컬럼 스토어는 NoSQL, 빅데이터를 다룰 때 활용한다
여기서 Index 가, 즉 Primary ket가 B+ Tree 자료구조로 저장되어 있다. 그래서 PK로 레코드를 빨리 찾을 수 있다
하드디스크에 저장되어 있다

DB에서의 B+ Tree

key를 PK로, value를 RID(page#, slot#)로 갖고 있다 (디스크에서 record를 읽어온다)
보통 23 구조를 가진다 (노드 키가 2개, 링크가 3개. 여기서 노드는 PK : RID 의 key:value 쌍으로 되어있다. PK가 실제 레코드 ID를 포인터로 가리키고 있다)
디스크에 안전하게 저장하고, 메모리에 올려서 빠르게 자료를 찾을 수 있어야 한다. 그래서 4KB에 맞춰져 있다
자주 사용하는 상위 노드를 buffer에 저장한 후, 빠르게 접근할 수 있게 한다
buffer는 한정된 공간이고, 공간을 잘 써야 한다. 보통 운영체제와 같이 LRU에 따른다. 루트 페이지는 buffer에 무조건 넣고, 자주 사용하는 페이지와 최신 페이지 순으로 중요하므로 그렇게 넣는다.

B Tree와 B+ Tree의 차이

B+는 가장 하위 노드인 리프만 value를 가지고 있다. B tree는 모든 노드가 value를 가지고 있다
B+는 범위 검색이 잘된다. 리프 노드에 다음 노드를 가리키는 next를 가지고 있기 때문이다. 범위 검색은 엄청나게 자주 쓰는 기능이기 때문에 B+ 가 쓰인다.

정규화

이상현상() 이 발생되지 않게 함이 가장 큰 목적.

제 1 정규형

DML이 잘되게 하기 위해서
값이 원자적이어야 한다
- 원자적?
  - 요구 사항에 따라 달라진다. 정하기 나름!
  - 하지만 원칙은 있다
    - multi-value 허용되지 않음 (array 같은)

제 2 정규형

이상 현상이 발생하지 않게!
후보키의 일부 속성에 대해 함수 종속성이 발생하는 것을 부분 함수 종속이라 한다
이러한 부분 함수 종속을 제거하는 것이 제 2 정규형이다

제 3 정규형

이행적 함수 종속 (X => Y => Z)을 제거
설계만 잘하면 제 3정규형은 만족하게 된다. 제 3 정규형을 만족하지 않는 경우는 서로 다른 성격의 객체를 한 번에 묶어서 발생하는 문제가 대부분이기 때문에, 객체 생각해서 설계를 잘하면 문제가 해결되는 경우가 대부분이다.

BCNF (Boyce - Codd - Normal - Form)

모든 후보키는 결정자이다.
다시 말해, 릴레이션 간 사이클이 생기면 안된다.

Date: August 20, 2019

Tags: DB