[Spring] 간단한 쿼리 개선

쿼리 성능 개선은 쿼리문 내에서 Join문과 서브쿼리를 개선하는 것이 전부인줄 알았던 나...

이번 쿼리 성능 개선을 통해 인덱스 최적화, 샤딩, 파티셔닝, 캐싱, 정규화와 비정규화 등 정말 많은 방법이 있다는 것을 알게 되었고 쿼리 개선에 흥미가 붙기 시작했다. 이번 성능 개선에서 내가 사용한 방법은 인덱스 최적화이다.

먼저 인덱스에 대한 개념들을 짚고 넘어가자

개선하고자 하는 API는 '필드' 테이블을 조회하는 페이징 API이다. 해당 API는 Count 쿼리와 일반 조회 쿼리, 총 2개의 쿼리가 실행된다.

 

 

---

 

☑️ 조회 쿼리

 

1️⃣ 클러스터링 인덱스 사용

먼저 쿼리 개선을 위해서는 실행계획을 통해 쿼리가 어떻게 실행되는지를 확인해야한다.

 

 

• type - ALL : 인덱스를 타지 않은 테이블 풀스캔을 의미한다.
• Using filesort : ORDER BY를 처리하기 위해 인덱스를 이용할 수 있지만 적절한 인덱스를 사용하지 못하는 경우, MySQL에서 정렬을 한 번 해야하는데 소트 버퍼에 레코드를 복사해서 정렬하는 비효율적인 작업을 하는 것을 의미한다.
  • 현재 created_at을 기준으로 정렬하고 있기 때문이다. 사실 id값으로 정렬하는 것과 의미상의 차이가 없다. 하지만 인덱스에 대한 지식없이 구현할 당시, created_at을 기준으로 정렬하는게 더 직관적이라고 생각했다. 하지만 이를 id값 기준 정렬로 바꾼다면 이미 정렬되어 있는 클러스터형 인덱스인 Primary index를 타기 때문에 성능 향상이 가능하다.
  • 수정한 쿼리의 실행 계획과 Profiling을 통해 얻은 테스트 결과이다. 아래의 3개가 created_at을 기준으로 정렬하여 풀 테이블 스캔을 한 결과이고, 위의 3개가 primary index를 탄 결과이다. 약 250% 정도의 성능향상을 확인할 수 있다.

    

    

 

 

---

 

2️⃣ No Offset 방식

 

진행중인 서비스의 조회 API는 일반적인 페이징 형식으로 구현되어 있다. 한 페이지를 조회할 때마다 카운트 쿼리가 함께 실행되어 totalCount를 받아오는 형식이다. totalCount 값을 쿼리 첫 실행시에만 보내주고 프론트단 캐시에 저장해두면 되지 않을까 라는 생각을 했다. 물론 이 방법도 가능하다.

하지만 현재 서비스는 페이지 목차를 나타내지 않고 스크롤과 더보기를 통해 추가 페이지를 나타내주고 있다. 그렇다면 totalCount 값은 총 몇 개의 항목이 검색되었는지를 명시적으로 나타내어주는 부분을 제외하면 필요하지 않은 데이터가 된다. 위와 같은 상황에 사용하는 방법이 바로 No Offset 방법이다.

 

일반적인 페이징 방식은 뒷부분의 데이터를 조회할 수록 느려집니다.

예를 들어 offset 10000, limit 20 이라 하면 최종적으로 10,020개의 행을 읽어야 한다.

(10,000부터 20개를 읽어야하니)

그리고 이 중 앞의 10,000 개 행을 버리게 됩니다.

(실제 필요한건 마지막 20개뿐이니)

뒤로 갈수록 버리지만 읽어야 할 행의 개수가 많아 점점 뒤로 갈수록 느려지는 것입니다.

No Offset 방식은 바로 이 부분에서 조회 시작 부분을 인덱스로 빠르게 찾아 매번 첫 페이지만 읽도록 하는 방식입니다.

• 위의 수정된 실행 계획의 rows를 보면 offset으로 설정한 5000개의 데이터를 모두 읽어 오는 것을 확인할 수 있다.

QueryDsl을 사용한 코드

 

 

위 코드와 같이 기존에 offset을 적용하는 대신 클라이언트로부터 이전 쿼리에서 마지막으로 조회된 Id값을 받아 where 절에 적용한다.

 

 

30만개의 데이터를 넣어 테스트 했을 때의 결과이다. 위의 결과가 offset 방식을 사용했을 때이고, 아래가 No offset 방식을 사용했을 때의 결과이다. 약 70배의 성능향상을 확인할 수 있다.

 

 

---

 

💠 보조 인덱스를 적용하지 않은 이유

위 쿼리에서는 테이블의 모든 필드 값을 쿼리에 사용한다. 또한 '필드' 테이블 컬럼들은 카디널리티가 매우 낮고 데이터 변경(삽입, 수정, 삭제) 작업이 자주 일어난다. 이러한 점들을 고려할 때 더이상의 인덱스 생성은 비효율적이라고 판단했다.