4.5 인덱스
4.5.1 인덱스의 필요성
인덱스란 데이터를 빠르게 찾을 수 있는 하나의 장치를 말한다. - 마치 책의 마지막 장의 '찾아보기'
4.5.2 B-트리
인덱스는 보통 B-트리라는 자료 구조로 이루어져 있다.
이는 루트 노드, 리프 노드, 루트 노드와 리프 노드 사이의 브랜치 노드로 나뉜다.
인덱스가 효율적인 이유는 효율적인 단계를 거쳐 모든 요소에 접근할 수 있는 균형 잡인 트리 구조와 트리 깊이의 대수확장성 때문이다.
대수확장성 : 트리 깊이가 리프 노드 수에 비해 매우 느리게 성장하는 것
4.5.3 인덱스 만드는 방법
MySQL
MySQL의 경우 클러스터형 인덱스와 세컨더리 인덱스가 있다.
클러스터형 인덱스는 테이블당 하나를 설정할 수 있다. primary key 옵션으로 기본키를 만들면 클러스터형 인덱스를 생성할 수 있고, 기본키로 만들지 않고 unique not null 옵션을 붙이면 클러스터형 인덱스로 만들 수 있다.
세컨더리 인덱스는 보조 인덱스로 여러 개의 필드 값을 기반으로 쿼리를 많이 보낼 때 생성해야 하는 인덱스이다. create index... 명령어를 기반으로 만들면 세컨더리 인덱스를 만들 수 있다. 하나의 인덱스만 생성할 것이라면 클러스터형 인덱스를 만드는 것이 세컨더리 인덱스를 만드를 것보다 성능이 좋다.
MongoDB
MongoDB의 경우 도큐먼트를 만들면 자동으로 ObjectID가 형성되며, 해당 키가 기본키로 설정된다. 그리고 세컨더리 키도 부가적으로 설정해서 기본키와 세컨더리 키를 같이 쓰는 복합 인덱스를 설정할 수 있다.
4.5.4 인덱스 최적화 기법
- 인덱스는 비용이다.
- 인덱스는 두 번 탐색하도록 강요
인덱스 리스트, 컬렉션 순으로 탐색하기 때문에 관련 읽기 비용이 듦
컬렉션이 수정되었을 때 인덱스도 수정되어야 한다.
따라서 쿼리에 있는 필드에 인덱스를 무작정 다 설정하는 것은 답이 아니다.
컬렉션에서 가져와야 하는 양이 많을수록 인덱스 사용이 비효율적이 된다.
- 항상 테스팅하라.
- 인덱스 최적화 기법은 서비스에서 사용하는 객체의 깊이, 테이블의 양 등에 따라 달라지므로 항상 테스팅이 필요하다.
explain() 함수를 통해 인덱스를 만들고 쿼리를 보낸 이후에 테스팅을 하며 걸리는 시간 최소화해야 한다.
EXPLAIN
SELECT * FROM t1
JOIN t2 ON t1.c1 = t2.c1- 복합 인덱스는 같음, 정렬, 다중 값, 카디널리티 순이다.
- 보통 여러 필드를 기반으로 조회를 할 때 복합 인덱스를 생성하는데, 이 인덱스 생성 순서에 따라 성능이 달라짐
어떠한 값과 같음을 비교하는 ==이나 equal이라는 쿼리가 있다면 제일 먼저 인덱스로 설정
정렬에 쓰는 필드라면 그다음 인덱스로 설정
다중 값을 출력해야 하는 필드, 즉 쿼리 자체가 >이거나 < 등 많은 값을 출력해야 하는 쿼리에 쓰는 필드라면 나중에 인덱스 설정
유니크한 값의 정도 : 카디널리티. 이 카디널리티가 높은 순서를 기반으로 인덱스를 생성해야 한다. 예를 들어 age와 email이 있을 때, email이 더 높다. 즉 email이라는 필드에 대한 인덱스를 먼저 생성해야 한다.
