[Database] 인덱스

인덱스

• 데이터를 빠르게 찾을 수 있는 하나의 장치
• 모든 요소에 접근할 수 있는 균형 잡힌 트리 구조와 트리 깊이의 대수 확장성으로 효율적임
• 대수확장성: 트리 깊이가 리프 노드 수에 비해 매우 느리게 성장하는 것

 

B-트리

• 인덱스는 보통 B-트리라는 자료구조로 이루어져 있음
• 루트 노드, 리프 노드, 브랜치 노드로 나뉨

 

 

인덱스 만드는 방법

MySQL

• 클러스터형 인덱스 와 세컨더리 인덱스 로 나뉨

클러스터형 인덱스 : 레코드들의 물리적인 저장 순서가 인덱스 순서와 동일하게 되도록 구성된 인덱스

• 인덱스의 리프 노드가 곧 데이터 레코드
• 인덱스 자체에 데이터가 포함됨
• 사전과 유사
• 보조 인덱스보다 검색 속도 빠름
• 동일하거나 인접한 키 값 가진 레코드들은 물리적으로도 인접하게 저장되어 성능 향상
• 데이터의 입력/수정/삭제는 더 느림
• 테이블당 하나 설정 가능
• 테이블 생성 시 기본키에 대해 클러스터 인덱스를 자동으로 생성
• 기본키를 지정하지 않으면 먼저 나오는 UNIQUE 속성에 대해 클러스터 인덱스 생성

 

세컨더리 인덱스(보조 인덱스) : 클러스터 인덱스가 아닌 모든 인덱스

• 보조 인덱스 생성시 별도의 페이지에 인덱스 구성
• 책 뒤 <찾아보기>와 유사
• 클러스터형보다 검색 느림
• 데이터 입력/수정/삭제는 덜 느림
• 테이블당 여러 개 생성 가능
• create index... 명령어 사용
• 하나의 인덱스만 생성할 것이라면 클러스터형 인덱스를 만드는 것이 세컨더리 인덱스 만드는 것보다 성능 좋음
  • ex) age라는 하나의 필드만드로 쿼리 보내면 클러스터형 인덱스만 필요 . age, name, email 등 다양한 필드를 기반으로 쿼리 보낼 땐 세컨더리 인덱스 사용

 

MongoDB

• 도큐먼트를 만들면 자동으로 ObjectID 가 형성 -> 해당 키가 기본키로 설정
• 세컨더리키도 부가적으로 설정해서 기본키와 세컨더리키를 같이 쓰는 복합 인덱스 설정 가능

 

인덱스 최적화 기법

1. 인덱스는 비용이다.
   • 인덱스는 두 번 탐색하도록 강요
   • 인덱스 리스트, 컬렉션 순으로 탐색하기 때문에 관련 읽기 비용이 듦
   • 컬렉션이 수정되었을 때 인덱스도 수정되어야 함
   • 컬렉션에서 가져와야 하는 양이 많을수록 인덱스 사용이 비효율적이 됨
2. 항상 테스팅하라.
   • 인덱스 최적화 기법은 서비스에서 사용하는 객체의 깊이, 테이블의 양 등에 따라 달라지므로 항상 테스팅 필요
   • explain() 함수를 통해 인덱스를 만들고 쿼리를 보낸 이후에 테스팅을 하며 걸리는 시간 최소화해야 함

     EXPLAIN
     SELECT * FROM t1
     JOIN t2 ON t1.c1 = t2.c1​

3. 복합 인덱스는 같음, 정렬, 다중 값, 카디널리티 순이다.

• 보통 여러 필드를 기반으로 조회를 할 때 복합 인덱스를 생성하는데, 이 인덱스 생성 순서에 따라 성능이 달라짐
• 어떠한 값과 같음을 비교하는 ==이나 equal이라는 쿼리가 있다면 제일 먼저 인덱스로 설정
• 정렬에 쓰는 필드라면 그다음 인덱스로 설정
• 다중 값을 출력해야 하는 필드, 즉 쿼리 자체가 >이거나 < 등 많은 값을 출력해야 하는 쿼리에 쓰는 필드라면 나중에 인덱스 설정
• 유니크한 값의 정도 : 카디널리티. 이 카디널리티가 높은 순서를 기반으로 인덱스를 생성해야 한다. 예를 들어 age와 email이 있을 때, email이 더 높다. 즉 email이라는 필드에 대한 인덱스를 먼저 생성해야 함