Indexing 적용해 성능 개선

 

 

이번 블로그에서는 인덱싱을 적용해 성능개선을 시도하면서 느꼈던 고찰에 대해서 정리하고자 한다.

 

 

1. 배경

API : 전체 회원에서 특정 조건에 맞게 회원을 검색하고자 한다.

DATA : 10000개의 회원이 DB에 존재하는 환경이다.

DB : MySql

 

 

 

2. 클러스터형 인덱스

기본적으로 클러스터형 인덱스는 기본키를 중심으로 설정된다. 특징으로는 해당 테이블은 이 기본키를 기준으로 정렬된다. 따라서 클러스터형 인덱스는 정렬에 영향을 준다. 물리적으로 영향을 준다는 말이다. 아무 설정없이도 기본적으로 테이블 생성시 생성된다.

다른 칼럼으로 클러스터형 인덱스를 설정 가능하지만 보통은 기본키로 설정해두고 세컨더리 인덱스를 사용해 다른 칼럼을 인덱스로 설정하는 것이 일반적이다.

 

 

성능 측정

 

아이디 : a 검색

 

아이디 : z 검색

 

두 요청 모두 1000건의 요청을 했고 위에서 설명했듯 데이터베이스의 크기는 10000개이다.

정렬 순으로 보면 아이디 a는 가장 상단에 위치해 있고 아이디 z는 가장 하단에 위치한다.하지만 둘의 요청 응답 시간을 확인해보면 평균적으로 1.5초정도로 두 요청에 대한 응답 속도 차이가 크게 차이 나지 않는다. 

 

이는 기본적으로 기본키는 클러스터형 인덱스로 처리되어 있으며 요청시 BTree로 검색 후 찾아가는 방식이기에 속도를 평등하게 맞춰준다는 인덱스의 특성이 적용되어서라고 보인다. 즉, 인덱스 처리시 빨리 찾을 수 있었던 데이터는 느려지고 찾는 속도가 느렸던 데이터는 빨라져 결과적으로 속도가 평등하게 맞춰준다는 느낌을 준다.

 

 

 

 

3. 세컨더리 인덱스

세컨더리 인덱스는 기본적으로 기본키 이외에 칼럼에 인덱싱을 하는 과정이다.

밑에 예시를 통해 성능을 측정해보고자 한다. 

 

 

배경

과정을 살펴보면, 현재 id는 주키이기에 클러스터형 인덱스로 설정되어 있기에 위의 결과처럼 인덱싱이 처리된 결과를 도출한다.

하지만 밑의 email 검색시 인덱싱이 처리되어 있지 않았을 때와 세컨더리 인덱싱을 통해 인덱싱을 처리했을 때의 차이를 보려고 한다.

 

 

 

세컨더리 인덱스 적용 안한 검색 성능 측정

 

이메일 : a 검색

이메일 : z 검색

 

인덱싱을 적용안하고 검색을 진행했다 위에서 설명한 말을 증명하듯 평균적으로 1000건의 요청에 대해서 1초의 차이가 발생했다. a는 데이터 검색시 상단에 위치해있고 z는 데이터 검색시 가장 하단에 위치한다. 따라서 위치에 따라 데이터 검색 속도에서 영향을 받는 것으로 보인다. 

 

 

 

 

 

세컨더리 인덱스 적용한 검색 성능 측정

 

이메일 : a 검색

이메일 : z 검색

 

위의 결과와 비교해보면 a검색시는 속도가 차이가 없지만 z 검색시 속도가 확연히 줄어듬을 확인가능하다. 대략 1초가량 속도가 향상되었다. 따라서, 인덱스 사용시 가장 위에 있는 데이터는 느려질 수 있지만 전체적으로 모두 빠르게 검색 가능하게 바뀌었음을 알 수 있다.

 

 

 

고려사항

추가적으로 생각해보면 데이터가 적다면 인덱스 적용시 느려짐을 추측해볼 수 있다. 인덱스를 사용하게 되면 인덱스를 검색 후 데이터를 검색하는 방식이다. 즉, 추가적인 검색동작이 소비된다. 또한, 인덱스는 결국 비용이다. 인덱스를 만들어야 하며 데이터 수정시 인덱스도 수정되어야 한다. 따라서 이런것들을 고려하여 적절하게 사용하는 것이 요구된다.

 

 

적용 사항

만약 프로젝트에 좀 더 적용을 해본다면, 자주 사용하는 필드를 활용해 검색하는 방법이 좋을 수도 있을 것 같고 동적 쿼리를 사용한다는 가정하에 인덱스를 생성해두고 검색하는 조건에 맞는 필드의 인덱스를 활용해 검색하는 것도 성능을 좀 더 빠르게 할 수 있는 방법이라는 생각이 든다.

 

 

 

4. 추가사항

복합 인덱스에 대한 실험은 하지 않았고 다른 블로그로 기록을 해둘 생각이다. 복합 인덱스는 보통 순서가 있다. 따라서 하나의 예시를 통해 순서에 따른 적용, 성능 측정으로 최적의 순서를 찾고 적합도를 평가해볼 생각이다.