벨플의 즐거운 개발

클러스터 인덱스
 - 클러스터 인덱스는 데이터 위치를 결정하는 키 값이다.
 - MySQL의 PK는 클러스터 인덱스다.
 - MySQL에서 PK를 제외한 모든 인덱스는 PK를 가지고 있다.

 EX : 클러스터키가 4번인 데이터가 insert 된다 > 3번과 5번 사이에 들어가니 5번이 뒤로 밀림(F로)
 클러스터키     데이터 주소
    1                       A
    2                       B
    3                       C
    4                       D (정렬)
    5                      (F) (뒤로 밀림)

 - 클러스터 키 순서에 따라서 데이터 저장 위치가 변경된다!
   > 클러스터 키 삽입/갱신 때 성능 이슈가 발생할 수 있다.
     > MySQL의 PK는 클러스터 인덱스다.

 Q. Pk로 Auto Increment vs UUID > 인터넷에 찾아보기

 - MySQL에서 PK를 제외한 모든 인덱스는 PK를 가지고 있다. (=세컨더리 인덱스)
 - PK의 사이즈가 인덱스의 사이즈를 결정함
   > 인덱스가 데이터 주소를 가지지 않고, PK를 가지고 있으면, 데이터 insert/update시 부하가 줄어듬 / 주소를 직접 가지고 있으면, 데이터 insert/update시, 인덱스도 갱신되어야 하므로 느림
 - 세컨더리 인덱스만으로는 데이터를 찾아갈 수 없다. (세컨더리 인덱스란, PK를 제외한 인덱스 들)
  > 세컨더리 인덱스로 PK 인덱스를 항상 검색해야함 > 즉 세컨더리 인덱스로 PK를 찾고 그 PK로 데이터를 찾아감

 [클러스터 인덱스의 장점]
 - PK를 활용한 검색이 빠름, 특히 범위검색
 - 세컨더리 인덱스들이 PK를 가지고 있어 커버링에 유리 > 커버링은 인덱스 테이블 자체만으로도 데이터의 응답을 내려줄 수 있어서 실제 테이블까지 안가도 됨

 [클러스터 인덱스의 동작]
 1) Pk 인덱스 동작방식
    [노드1]
    인덱스키 주소
    Apple   2 (노드2)
    -->
    [노드2]
    인덱스키 주소
    Carrot  5 (노드5)
    -->
    [노드5] (리프노드)
    인덱스키 PK
    Cherry  2 -> PK 인덱스에 요청 -> 데이터
 2) 기본
    [노드1]
    인덱스키 주소
      1      2 (노드2)
    -->
    [노드2]
    인덱스키 주소
      2      4 (노드4)
    -->
    [노드4] (리프노드)
    인덱스키 데이터주소
      2        64     -> 데이터

1. 인덱스란 정렬된 자료구조이다
 EX: A테이블의 a라는 컬럼에 인덱스를 생성하면
     a를 pk로 하고, 그 데이터가 있는 주소가 담긴 컬럼으로 구성된 인덱스 테이블이 만들어짐 / 그리고 a는 정렬되어있다.
     따라서 A테이블의 가장 작은 a를 구하려고 하면 인덱스 테이블의 맨 위 데이터 1개만 보면 되므로 빠르다.
       > 즉, 인덱스의 핵심은 탐색(검색) 범위를 최소화 하는 것

2. 인덱스와 자료구조
 - HashMap : 단건 검색 속도 O(1)
 - 그러나 범위 탐색은 O(N) > 범위 내에 데이터를 하나하나 다 꺼내봐야 함
 - 전방 일치 탐색 불가 ex) like 'AB%' > 하나하나 다 꺼내봐야 함

 - List : 정렬되지 않은 리스트 탐색은 O(N)
 - 정렬된 리스트의 탐색은 O(logN)
 - 정렬되지 않은 리스트의 정렬 시간 복잡도는 O(N) ~ O(N*logN)
 - 삽입 / 삭제 비용이 매우 높음 : 가운데 값을 지우면 오른쪽 값들은 왼쪽으로 다 옮겨야 함

 - Tree : 높이에 따라 시간 복잡도가 결정됨
 - 트리의 높이를 최소화하는 것이 중요
 - 한쪽으로 노드가 치우치지 않도록 균형을 잡아주는 트리 사용
     > Red-Black, B+Tree

 - B+Tree : 삽입 / 삭제시 항상 균형을 이룸
 - 하나의 노드가 여러 개의 자식노드를 가질 수 있음
 - 리프노드에만 데이터 존재
     > 연속적인 데이터 접근시 유리하다.
 - 따라서 인덱스로 많이 활용되는 알고리즘이다.

데이터베이스 성능의 핵심

1) 메모리 VS 디스크

         메모리    디스크
속도     빠름       느림
영속성   휘발성     영속성
가격     비쌈       저렴

 => 결국 데이터베이스 성능의 핵심은 디스크 I/O 최소화 시키는 것

2) 성능 향상 전략
메모리에 올라온 데이터로 최대한 요청을 처리
 => 메모리 캐시 히트 적중률을 높이는 것
 => 심지어 곧바로 데이터를 쓰지 않고 메모리에 쓰고 > 디스크에 씀

3) WAL(Write Ahead Log)
메모리에 데이터 유실을 고려해 WAL(Write Ahead Log)를 사용 (전원이 내려갔을 경우)

4) 랜덤 I/O와 순차 I/O
랜덤 I/O : 무작위로 Block의 데이터를 입/출력
순차 I/O : 연속된 Block의 데이터를 입/출력
 => 대부분의 트랜잭션은 무작위하게 Write가 발생
 => 이를 지연시켜 랜덤I/O의 횟수를 줄이는 대신,
    메모리에 데이터를 저장하고, 디스크에 I/O할 때는 순차 I/O를 발생시켜
    데이터 정합성을 유지함 (WAL 기술)

Q. 중복된 데이터는 반드시 정규화 해야하는가?

1. 정규화 시 고려사항
- 얼마나 빠르게 데이터의 최신성을 보장해야 하는가?
- 히스토리성 데이터는 오히려 정규화 하면 안됨
- 데이터 변경 주기와 조회 주기는 어떻게 되는가? > 변경이 많을수록 정규화가 유리
- 객체(테이블) 탐색 깊이가 얼마나 깊은가?
  > A -> B -> C -> D (4 depth)
    > A -> B -> D : D 참조를 만든다 하지만 C의 D참조가 변하면 B의 D참조도 같이 변경되어야 함

2. 정규화를 하기로 했다면, 조회시 어떻게 데이터를 가져올 것인가?
- 테이블 조인 > 하지만 고민해야함, 데이터를 쉽게 가져올 순 있지만
              > 결합도가 높아지고, 여러 테이블에 영향을 받기 때문에, 데드락 이슈, 리소스 소요가 많아짐