Index
데이터베이스의 검색 속도를 향상시키기 위한 자료구조
예를들어 위처럼 서울에 있는 모든 레스토랑을 찾을 때 일반적으로 전체의 데이터를 조회(FTS - Full Table Scan)하면서 주소값이 서울인 것을 매번 비교하고 해당 결과들을 모아서 반환을 해 결과를 보여준다.
이러한 방식의 동작은 테이블의 데이터가 굉장히 늘어났을 때 해당 연산을 똑같이 선형적으로 많이 해야 한다는 단점이 있다.
이런 검색 방식은 굉장히 많은 성능 저하를 부르기 때문에 반드시 개선해야 하는 작업이다.
그러한 개선작업을 위해서 Index를 사용한다.
B-tree (Balanced tree)
균형 트리
전반적으로 한쪽에 치우쳐져있지 않고 트리들이 각자 적당히 분배하여 노드들을 가지고 있다.
이렇게 균형잡힌 트리는 검색을 할 때 항상 최적의 성능을 보장하기 위한 특성 중 하나이다.
탐색 트리 (정렬)
매번 정렬이 되어 있는 상태를 유지하는 특징이 있다.
예를들어 11이라는 값을 찾을 때 8보다 커 오른쪽으로 12보다 작아 왼쪽으로 10보다 커 오른쪽으로 가는 방식으로 전체를 다 조회하지 않아도 내가 원하는 값을 찾아낼 수 있다.
하지만 항상 정렬을 유지해야하기 때문에 삽입, 삭제, 업데이트에는 취약한 성능을 보인다.
탐색 트리는 항상 정렬 상태를 유지하기 때문에 쓰기 성능을 굉장히 많이 희생하면서 검색 성능을 최대한 끌어올린다는 특징이 있다.
하나의 노드에 여러 정보 저장 가능, 두개 이상의 자식을 가질 수 있다.
Index 종류
Clustered Index
- 실제 데이터 자체가 정렬
- 테이블당 1개만 존재 (실제 데이터 자체가 정렬이기 때문)
- Index의 리프 페이지가 실제 데이터
- 아래의 제약조건 시 자동 생성
- primary key (우선순위)
- unique + not null
Non-Clusterd Index
- 실제 데이터 페이지는 그대로
- 별도의 Index 페이지 생성 -> 추가 공간 필요
- 테이블당 여러 개 존재
- 리프 페이지에 실제 데이터 페이지 주소를 담고 있음
- unique 제약조건 적용 시 자동 생성
- 직접 index 생성시 Non-Clusterd Index 생성
Clustered Index & Non-Clusterd Index
Clusterd Index와 Non-Clusterd Index가 동시에 존재할 경우가 있다.
- PK column을 설정해 테이블 생성 후 자주 발생하는 조회 column에 대해 index를 추가하는 경우
- Clusterd Index는 달라지는 점이 없음
- Non-Clusterd Index는 이전에는 데이터 주소를 직접 가르키고 있었지만 현재는 Clusterd Index에서 걸어둔 column or PK 값을 가지게 된다.
Index를 사용하면 좋은 경우
- WHERE, JOIN 조건에 자주 발생하는 컬럼
- INSERT, UPDATE, DELETE 가 적게 발생하는 컬럼
- 중복도가 낮은 컬럼 (Cardinality가 높은 컬럼)
- 범위 검색이 적은 컬럼
- 데이터가 많은 테이블
Index 사용 시 주의사항
- 잘 활용되지 않는 Index는 과감히 제거하자
- WHERE 절에 사용되더라도 자주 사용해야 가치가 있다.
- 불필요한 Index로 성능 저하가 발생할 수 있다.
- 데이터 중복도가 높은 컬럼은 Index 효과가 적다.
- 자주 사용되더라도 INSERT, UPDATE, DELETE 가 자주 일어나는지 고려해야한다.
- 일반적인 웹 서비스와 같은 온라인 트랜잭션 환경에서 쓰기와 읽기의 비율은 2:8 or 1:9 이다.
- 조금 느린 쓰기를 감수하고 빠른 읽기를 선택하는 것도 하나의 방법이다.
출처 : https://www.youtube.com/watch?v=ywYdEls88Sw&list=PLgXGHBqgT2TvpJ_p9L_yZKPifgdBOzdVH&index=68
https://www.youtube.com/watch?v=edpYzFgHbqs&list=PLgXGHBqgT2TvpJ_p9L_yZKPifgdBOzdVH&index=179
