눈에 띄는 성능 향상 경험

지금까지 대용량 데이터를 경험해볼 일이 없었다. 그래서 쿼리 성능에 대해 고민해볼 일이 없었다. 그리고 오늘! 쿼리튜닝의 대단함을 느꼈다!

문제 인식

오늘 회사에서 진행하고 있는 프로젝트의 어떤 한 페이지에 접속하니, server로부터 response를 받는데 7~8초 정도 걸리는 request를 발견했다. 원인을 추적해보니 쿼리의 문제였다.

복잡한 전체 쿼리는 두고 서브쿼리를 하나씩 뜯어보니, 7~8초가 소요되는 전체 쿼리에 3~4초가 소요되는 쿼리 2개가 UNION ALL로 사용되고 있었다. 그래서 우선 서브쿼리의 성능을 개선하려고 했다.

성능저하의 원인

날짜를 조건으로 하는 WHERE문이 성능저하의 원인이었다.

우선 컬럼의 type은 timestamp이고 전체 row는 750만건이었다. 수정 전 해당 조건문은 다음과 같다.

WHERE TO_CHAR(timestamp_column,'YYYYMMDD') = TO_CHAR(SYSDATE,'YYYYMMDD')

위 조건문으로 서브쿼리를 실행할 경우, 서브쿼리만 3~3.5초 정도 소요되었다.

수정 후 조건문은 다음과 같다.

WHERE timestamp_column >= TO_DATE(TRUNC(SYSDATE)) AND timestamp_column < TO_DATE(TRUNC(SYSDATE))+1

수정된 조건문으로 서브쿼리를 실행할 경우, 0.4~0.5초 정도 소요되었다.

설명에 앞서 TRUNC('값','옵션')는 소수점을 자르거나, 날짜의 시간을 자르는데 쓰인다. 따라서 TRUNC(SYSDATE)라고 하면 시간을 제외한 날짜가 DATE형식으로 반환된다.

자세한 TRUNC() 사용법은 검색하거나 https://gent.tistory.com/192 를 참고할 수 있다.

다시 돌아와서, 수정 전·후 조건문의 차이점을 비교해보자. 포인트는 컬럼의 형변환이다.

수정 전의 조건문은 timestamp형의 컬럼을 문자형으로 변환 후, 문자형으로 변환한 SYSDATE와 비교한다. 즉, 수정 전의 쿼리를 사용할 경우, 데이터가 750만건일 때 750만번의 형변환이 실행된다.

그렇다면 수정 후의 조건문은 어떨까? 수정 후의 조건문은 컬럼의 형을 변환하지 않는다. 그렇기때문에 750만건의 데이터를 비교해도 형변환은 일어나지 않는다.

결과

전체 쿼리에 포함된 2개의 서브쿼리의 날짜 비교 조건문을 수정한 후, 7~7.5초 소요되던 쿼리가 0.7~1.1초로 주는 마법을 경험했다. 컬럼의 값을 변형하는 것은 데이터의 양이 많아질수록 더 큰 성능저하를 일으킨다는 사실을 알았다.

그 동안 쿼리의 성능개선을 어렵게만 생각해왔다. 기초가 부족하니 당연하다. 역시 기초탄탄! 공부하자! 공부해서 결과로 볼 수 있는 짜릿함을 느끼자!