인기순 전체 게시글 목록 조회 기능의 성능 개선을 위한 QueryDsl 코드 수정 #835
Conversation
| List<Long> postIds = jpaQueryFactory | ||
| .select(post.id) |
There was a problem hiding this comment.
커버링 인덱스가 되려면 여기서 사용되는 모든 컬럼에 인덱스가 적용되어야 하나요?
DB에서는 어떤 컬럼에 인덱스를 추가적으로 설정하시는지 설명해주실 수 있나요 :)
There was a problem hiding this comment.
맞습니다. select, join on, where, order by, group by에 있는 모든 컬럼이 포함되어야 합니다. 그래서 select엔 id만 검색하게끔 쿼리를 추출했습니다.
해당 PR 적용 후 개발서버 DB에 적용할 쿼리문입니다.
drop index post_id ON post_category;
create unique index idx_post_id_category_id on post_category (post_id, category_id);
create index idx_is_hidden_vote_count_deadline ON post (is_hidden, vote_count desc, deadline);post_id 인덱스는 살펴보니, post_id와 category_id로 이루어진 인덱스더라구요. 그래서 이름을 명확하게 변경하기 위해 해당 작업을 추가하였습니다.
There was a problem hiding this comment.
알려주셔서 감사합니다 🙇🏻♂️
인덱스를 적용함으로 조회 성능을 챙길 수 있다는 장점도 있지만, 생성, 수정, 삭제 성능이 감소된다는 단점도 있을 것 같아요. 생성, 수정, 삭제 성능은 어느 정도 감소되는지 알 수 있을까요?!
설정해두신 인덱스는 커버링 인덱스에서만 사용될 인덱스인 것 같은데 위의 성능을 줄이면서 커버링 인덱스를 사용해야하는 이유가 아직 와닿지 않았어요. 이 부분에 대해서도 한번 설명해주시면 감사합니다 :)
There was a problem hiding this comment.
일단 게시글 작성, 투표 전부 테스트 해본 결과 성능 차이는 아예 없는 것으로 보입니다.
전체 게시글 목록 조회 기능은 핵심 기능 중 하나라고 생각했기에 충분히 인덱스 하나는 투자할 만한 가치가 있다고 느꼈습니다. 현재도 인기순 조회 기능만을 위해서 vote_count가 인덱스 설정이 되어있는 것처럼, 이 정도 성능 개선을 위해서라면 인덱스 하나정도 투자하는 것은 엄청난 가성비라고 생각합니다.
하지만 결국 인덱스도 데이터라서, 커버링 인덱스의 단점으로, 인덱스가 많아진다거나 인덱스 크기가 커지는 것 등등이 꼽히는 것이 사실입니다.
사실 지금도 커버링 인덱스 하나만 적용하는 것이기에 생성, 수정 기능이 아예 성능 차이가 없지만, 커버링 인덱스 종류가 좀 많아진다면 어떻게 될 지 모르겠네요.
그래서 인덱스를 최대한 재활용 가능하게끔 쿼리 관리를 꾸준히 해나가는 것도 중요한 부분으로 보입니다 :)
There was a problem hiding this comment.
이 코멘트들을 읽으면서 든 궁금증인데, 성능차이가 아예 없는 것이 가능한가요..?
There was a problem hiding this comment.
커버링 인덱스를 적용할 때와 안할 때의 조회 성능을, JMeter 부하 테스트로도 진행 했었는데요.
초당 1000건 요청(Error 6.5%) → 초당 1000건 요청 (Error 0.87%)
성능이 개선되면서 에러 비율이 많이 줄어든 모습도 볼 수 있습니다.
There was a problem hiding this comment.
데이터가 정말 많지 않은 상황에서는 인덱스에 대한 처리 비용이 정말 크지 않은 것 같네요 배워갑니다 ㅎㅎ
그래서 인덱스를 최대한 재활용 가능하게끔 쿼리 관리를 꾸준히 해나가는 것도 중요한 부분으로 보입니다 :)
말씀해주신 부분처럼 꾸준히 관리해나가는게 중요할 것 같아요!
JMeter를 통한 부하 테스트까지 진행한 점 역시 아벨이군요 👍
There was a problem hiding this comment.
혹시 insert시의 속도비교 말고 update시의 속도비교도 해보셨나요?
There was a problem hiding this comment.
workbench에서 실험해봤는데, insert와 마찬가지로 update도 인덱스 걸 때와 안 걸 때 모두 0.000sec 나옵니다 :)
| List<Long> postIds = jpaQueryFactory | ||
| .select(post.id) |
There was a problem hiding this comment.
이 코멘트들을 읽으면서 든 궁금증인데, 성능차이가 아예 없는 것이 가능한가요..?
🔥 연관 이슈
close: #833
📝 작업 요약
인기순 전체 게시글 목록 조회 기능의 성능 개선을 위한 QueryDsl 코드 수정
⏰ 소요 시간
2일 (자세히 학습하는 시간이 좀 걸림)
🔎 작업 상세 설명
QueryDsl에서 시간이 많이 드는 부분을 서브쿼리로 추출한 후 그 쿼리에 커버링 인덱스를 적용합니다.