feat: [DB] Index 정리 (#39)

DB/Index.md

@@ -0,0 +1,60 @@
+## Index
+### 인덱스(index, 색인)
+
+- 데이터베이스에서 인덱스는 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터 베이스 테이블의 검색 속도를 향상시키기 위한 자료구조로 데이터 접근을 신속하게 하는 기능을 제공한다.
+- 인덱스를 사용하지 않으면 전체를 탐색하는 full scan을 수행해야 하지만, 인덱스를 활용하면 데이터와 데이터의 위치를 포함한 자료구조를 생성하여 빠르게 조회가 가능하다. 이때 색인 파일은 원 파일보다 크기가 매우 작아야한다.
+- 인덱스는 생성 시 정렬하기 때문에 정렬된 주소체계다.
+- 색인에는 정렬 색인과 해쉬 색인이 있다.
+    - 정렬 색인: 색인 레코드가 탐색키 기준으로 정렬되어 있는 자료구조
+    - 해쉬 색인: 탐색키를 정렬하지 않는 자료구조
+    - 정렬 색인은 정렬이 되어 있기에 범위 질의 처리에 효율적이나, 반대로 해쉬 색인은 범위 질의를 효과적으로 지원하지 못함
+- 데이터:책의 내용, 인덱스:책의 목차, 데이터 주소:책의 페이지
+
+### 인덱스 관리
+
+- DBMS는 인덱스를 항상 최신의 정렬 상태로 유지해야 빠른 탐색이 가능
+- INSERT: 새로운 데이터에 대한 인덱스 추가
+- DELETE: 삭제하는 데이터의 인덱스를 삭제 대신 **사용하지 않음 처리**
+- UPDATE: 기존 인덱스를 **사용하지 않음 처리** & **갱신된 데이터에 대한 인덱스 추가**
+
+### 인덱스의 장점
+
+- 테이블 조회 속도와 성능을 향상시킬 수 있음
+- 시스템 부하를 전반적으로 줄일 수 있음
+- 중복 데이터를 방지하거나 특정 컬럼의 유일성을 보장할 수 있음
+- JOIN, ORDER BY, GROUP BY, WHERE 절 등을 더 효율적으로 처리 가능
+
+### 인덱스의 단점
+
+- 추가적인 저장공간이 필요
+- 인덱스 관리를 위한 추가 작업 필요
+- 인덱스를 잘못 사용할 경우 오히려 성능 저하가 발생할 수도 있음(역효과)
+    - ex) INSERT, DELETE, UPDATE가 빈번한 속성에 인덱스를 사용하면 인덱스의 크기가 비대해져 오히려 성능 저하, 왜냐하면 기존 인덱스가 사라지는 게 아니고(사용하지 않음 처리) 유지되기 때문
+
+따라서 인덱스는 INSERT, DELETE, UPDATE가 자주 발생하지 않는 컬럼에 사용하는 것이 좋다.
+
+### 인덱스 자료구조
+
+- 해시 테이블(Hash Table)
+    - 컬럼의 값과 물리적 주소를 (key, value)의 한 쌍으로 저장하는 자료구조
+    - 키를 해시 함수를 이용하여 해시 값으로 변환 후, 해당 해시 값에 해당하는 값을 찾아 검색하는 방식
+    - O(1)의 시간복잡도로 빠른 검색이 가능
+    - 다만 데이터 분포에 따라 충돌 발생 가능, 또한 등호(=) 연산에만 특화되어 있어 부등호 연산(<,>)이 자주 사용되는 경우에는 적합 x
+- B-Tree
+    - O(logN)의 시간복잡도
+    - 균형 잡힌 트리(루트로부터 리프까지의 거리가 일정한 트리 구조), 두 개 이상의 자식을 가질 수 있음
+    - 각 노드 내 데이터들은 항상 정렬된 상태
+    - 한 노드에 여러 키를 가지고, 키에 대응하는 데이터도 가짐(노드마다 데이터 가짐)
+- B+Tree
+    - O(logN)의 시간 복잡도
+    - B-Tree의 변형 구조, Root Node/ Internal Node/Leaf Node로 구성된 계층 구조
+    - 모든 데이터는 리프 노드에서만 저장! 내부 노드는 검색을 위한 인덱스만 저장
+    - 모든 리프 노드가 연결 리스트로 연결되어 있으며, 키는 항상 정렬된 상태 유지⇒ 범위 검색이나 순차 검색에 효율적
+- B-Tree vs B+Tree
+
+| B-Tree  | B+Tree |
+| --- | --- |
+| 모든 노드에 키와 데이터가 함께 저장 | internal 노드에 키만 저장, 리프 노드에 키와 데이터 저장 |
+| leaf 노드끼리 연결되어 있지 않아 internal 노드를 통해서만 leaf 노드로 이동 가능 | leaf 노드끼리 서로 연결 리스트로 연결되어 있어 internal 노드를 통하지 않고 형제 노드로 이동 가능 |
+| 범위 쿼리 수행 시 루트부터 리프까지 트리 내부를 이동하면서 데이터까지 함께 조회해야 함 | 데이터는 리프에만 존재하므로 리프 노드 검색하면 연결된 리스트 따라가면서 모든 데이터 조회 가능 |
+| 순차 탐색이나 정렬 시 추가 알고리즘 필요 | 연결된 리스트를 따라가면서 순차 탐색 가능, 키는 항상 정렬된 상태 |