개요

스터디 허브 프로젝트의 성능 개선을 위해 DB 인덱스에 관해 학습하던 중 문득 성능 차이를 눈으로 보고싶다는 생각이 들어 직접 구현하게 되었습니다.

프로젝트 설계

DB 인덱스 성능 테스트가 목적이기 때문에 설계를 간단하게 구성했습니다.

데이터 입력은 아래와 같은 로직으로 진행됩니다.

1. 클라이언트가 Post 요청을 보낸다.
2. 서버측에서는 이를 받아 랜덤한 문자열을 가지는 UserEntity를 100만개를 생성한다.
3. DB에 UserEntity 100만개를 saveAll 메소드를 이용해 저장한다.

조회 성능 테스트

성능 테스트는 다음과 같은 방식으로 진행됩니다.

1. 인덱싱하지 않은 상태로 DB에서 name을 조회해 동일한 name이 있을 경우 반환한 뒤 수행 시간을 측정한다.
2. 인덱싱한 상태로 DB에서 name을 조회해 동일한 name이 있을 경우 반환한 뒤 수행 시간을 측정한다.

인덱스 하기 전

데이터 100만개를 삽입하기 위한 요청을 보내고 데이터베이스에서 100만개가 삽입된 것을 확인했습니다.

DB 내 삽입된 문자열 중 네개를 선택해 조회해 보겠습니다.

네개의 응답 속도의 평균을 내보면 94ms로 추산됩니다.

인덱스 한 이후

이번엔 DB 인덱싱을 한 뒤 조회해 보겠습니다.

기본으로 생성된 primary_key 에 대한 인덱스 이외에 하나의 인덱스가 더 생성된 것을 확인할 수 있습니다.

인덱스 생성이 완료됐으므로 DB 내 삽입된 문자열 중 네개를 선택해 조회해 보겠습니다.

WOW! 평균 10ms 로 줄어든 것을 볼 수 있습니다!

삽입 성능 테스트

인덱스는 조회 성능은 개선하지만 인덱스 유지비용 때문에 삽입, 수정, 삭제 성능이 떨어진다는 단점이 있습니다.

조회 성능 테스트에서 했던 방식과 같은 방식으로 데이터 100만개를 삽입한 뒤, 데이터를 1000개만 삽입하는 API를 따로 만들어 인덱스 하기 전과후의 성능을 비교하겠습니다.