인덱스의 필요성
인덱스는 데이터를 데이터베이스에서 빠르게 찾을 수 있는 하나의 장치로 인덱스를 설정하면 테이블 안에 내가 찾고자 하는 데이터를 빠르게 찾을 수 있습니다.
B-Tree
인덱스는 보통 B-Tree라는 자료구조로 루프 노드, 리프 노드, 브랜치 노드로 구성되어있습니다.
트리의 탐색은 루프 노드부터 이루어지며 브랜치 노드를 거쳐서 리프 노드까지 내려오게 됩니다. 이러한 인덱스가 효율적인 이유는 효율적인 단계를 거쳐서 모든 요소에 접근할 수 있는 균형잡힌 트리 구조와 트리길이의 대수확장성 때문입니다. 대수확장성이란 트리깊이가 리프 노드 수에 비해 매우 느리게 성장하는 것을 의미하며 기본적으로 인덱스가 한 깊이씩 증가할 때마다 최대 인덱스의 항목의 수는 4배씩 증가합니다.
인덱스를 만드는 방법
- MySQL
- 클러스터형 인덱스: 네이블당 하나를 설정할 수 있으며 PrimaryKey옵션으로 기본 키를 만들거나 , unique not null 옵션을 붙이면 클러스터형 인덱스를 생성할 수 있습니다. 하나의 인덱스만 생성할 때는 클러스터형 인덱스를 만드는 것이 세컨더리 인덱스를 만드는 것보다 성능이 좋습니다.
- 세컨더리형 인덱스: 보조 인덱스를 의미하며 여러개의 필드값을 기반으로 쿼리를 많이 보낼 때 생성해야하는 인덱스를 의미합니다.
MongoDB
1. 도큐먼트를 만들경우 자동으로 ObjectID가 생성되며, 해당 키가 기본키로 설정이 됩니다. 세컨더리키도 부가적으로 설정해서 기본키와 세컨더리키를 같이 사용하는 복합인덱스 또한 설정이 가능합니다.
인덱스 최적화 기법
1. 인덱스는 비용입니다.
인덱스는 두 번 탐색하도록 강요하며, 인덱스 리스트, 컬렉션 순으로 탐색하기 때문에 관련 비용이 들게 됩니다. 컬렉션이 수정되었을 때는 인덱스도 수정되어야 하는데 여기서 B-Tree의 높이를 균형있게 조절하는 비용도 들고 데이터를 효율적으로 조회할 수 있도록 분산시키는 비용또한 들게됩니다. 그렇기 때문에 쿼리에 있는 필드에 인덱스를 무작정 다 설정하는 것은 옳지 않은 방법이며, 컬렉션에서 가져와야 하는 양이 많을 수록 인덱스를 사용하는 것인 비효율적입니다.
2. 항상 테스팅.
인덱스 최적화 기법은 서비스 특징에 따라 달라지며, 서비스에서 사용하는 객체의 깊이, 테이블의 양 등이 다르기 때문에 항상 테스팅을 해야합니다. explain() 함수를 통해 인덱스를 만드고 쿼리를 보낸 이후에 테스팅을 진행하며 걸리는 시간을 최소화 해야합니다.
3. 복합 인덱스는 같음, 정렬, 다중 값, 카디널리티 순으로 해야합니다.
보통 여러 필드를 기반으로 조회를 할 때 복합 인덱스를 생성하는데, 이 인덱스를 생성할때에는 순서가 있으며 그 생성 순서에 따라 인덱스의 성능이 달라지게됩니다.
1. 어떤 값과 같음을 비교하는 ==이나 equal이라는 쿼리가 있다면 제일 먼저 인덱스를 설정해야합니다.
2. 정렬에 쓰는 필드라면 그 다음 인덱스로 설정해야합니다.
3. 다중 값을 출력해야하는 필드나 쿼리 자체가 > 이거나 < 등 많은 값을 출력해야하는 쿼리에 쓰는 필드라면나중에 인덱스를 설정해야합니다.
4. 유니크한 값의 정도를 카디널리티라고 하는데, 이 카디널리티가 높은 순서를 기반으로 인덱스를 생성해야합니다.
