SQL Query time 줄여보기 (2)

당황스러운 결과가 나왔다.

코드를 뜯어 고치기 위해 레포를 새로 팠고, 데이터를 조금 추가했다.

 

그림 1. 현재 조회되는 데이터의 수

 

Post는 17만, Comment는 93만, Like는 170만, User는 280만 정도가 된다.

 

그림 2. 기존 서브쿼리 지옥의 타임

이전 포스팅에서 300ms 정도로 측정되던 속도가 1초 가량으로 올라갔다. 데이터의 양에 많은 영향을 받는다는 것을 확인할 수 있고, 데이터의 양이 이보다 훨씬 늘어난다면 (Post가 1억개 이상, Like는 30억개 이상) 더 많은 부하가 걸릴 것이라는 느낌이 들었다.

아무튼, 쿼리 요청을 처음부터 재설계하다가 확인한 부분인데..

 

그림 3. SELECT * FROM "board_post"

가장 기초가 되는 쿼리이다. SELECT * FROM "board_post" 형식.

여기에 N+1을 방지하기 위해 base_user 테이블의 정보를 select related 메서드를 사용해 inner join을 한다.

 

그림 4. SELECT * FROM "board_post" INNER JOIN "base_user"

??

여기서 이미 1초가 넘어간다. 여기에 기존 코드와 같은 서브쿼리로 Comment, Like, Hitcount를 가져오면

 

그림 5. 다시 서브쿼리 지옥. 기존 쿼리

 

환장하겠네..

서브쿼리가 가져오는 시간은 0.2초 이내의 시간이었고 애초에 Inner Join이 1초 이상의 지연을 가져오게 된다는 것을 확인할 수 있었다.

애초에 서브쿼리 지옥이 문제의 핵심이 아니었던 것.

정말 처음으로 돌아가서 다시 확인을 해보기로 한다.

 

그림 6. 그림 3에 index를 추가한 쿼리

ORDER BY의 기준이 created_at인 것을 확인했다. 프로덕션 레벨의 게시판에서 저 컬럼을 기준으로 넘버링을 하진 않을 것 같지만 그런건 넘어가기로 한다. 아무튼 인덱싱 컬럼에 created_at을 추가해서 시간을 조금 줄였다(그림 3과 비교해 58ms -> 2ms). 

 

무작정 추가하고 있는 인덱스가 뒤엔 어떤 기술 부채가 될지는 예상이 가지 않는다. 그건 나중에 생각하기로 한다. 그리고 결과를 다시 확인한다.

 

그림 7. ODER BY 컬럼에 인덱스를 추가한 후 다시 쿼리 지옥

??

저거 하나로 1초가 넘어가던 서브쿼리 지옥이 0.004초까지 내려갔다.

페이지네이션에서 SELECT COUNT(*) FROM "board_post"로 요청하던 전체 글의 수가 여전히 20ms 정도의 타임을 요구하긴 하지만 어쨌든 주요 쿼리는 4ms 안에 끝나는 것을 볼 수 있다.

 

이렇게 되면 다시 문제점이 바뀐다. INNER JOIN의 문제가 아닌 ORDER BY의 문제였던 것이다.

 

그리고 20,000ms가 나오던 쿼리가 4ms로 내려가니까 뭔가 의욕과 도전정신, 성취감이 불타올라 없어져버렸다.

그래서 데이터를 더 추가하기로 한다. Post를 1억개까지 늘려보고 다시 돌려봐야겠다.