오늘은 Index에 따른 메인페이지 속도 개선과 Index 생성시 쓰기 성능은 얼마나 떨어지는가에 대한 테스트를 해볼려고 한다.
현재 메인페이지를 조회하는 API는 3개가 있는데 각각은 다음과 같다.
- Gril : 투표율 45 : 55 수준 이내에서 가장 높은 투표순
- Hot : 가장 많은 조회순
- New : 최신순
설정
데이터 개수
Index 쿼리
create index idx_post_vote_ratio_vote_count_desc on post (vote_ratio desc, vote_count desc);
create index idx_post_created_at_desc on post (created_at desc);데이터 설정
- Post에는 투표율을 나타내는 컬럼이 하나 있는데 팀원의 아이디어(역시 코테 개고수..)로 낮은 값을 저장해두고 vote_ratio >= 45 조건으로 검색을 하면 45 : 55 비율을 넘지 않는 포스트가 불러와진다는 것이다.
UPDATE post
SET vote_ratio = 40 + RAND() * 10 where 1=1;
UPDATE post
set vote_count = RAND() * 10000 where 1=1;Index 적용전
게시물 업로드 성능
- 게시물 30개 업로드 기준
Grill 조회 성능
- 10명의 유저가 1번씩 10개의 게시물 조회
New 조회 성능
- 10명의 유저가 1번씩 10개의 게시물 조회
Index 적용후
게시물 업로드 성능
Grill 조회 성능
New 조회 성능
실행계획 보기
조회 성능이 유의미한 개선이 이루어지진 않아서 실행계획을 보기로 했다.
속도가 미약하게나마 개선된 Grill API는 Index를 타지만
- 👇 Grill 쿼리 실행계획
New 쿼리는 Index를 타지 않는다. 추측해보건데, PK를 뒤로 읽는거랑 별만 차이가 없어서 그런게 아닐까 싶다.
- 👇 New 쿼리 실행계획
Cursor 기반 Pagination으로 변경
Index 적용전
Grill 조회 성능
New 조회 성능
Index 적용후
Grill 조회 성능
- 13.67 -> 3.57 -> 2.92 page 기반 페이지네이션에 비해 약 4.68배 성능개선, Index 적용 전에 비해 1.22배 성능개선이 이루어졌다.
New 조회 성능
- 26.21 -> 3.42 -> 1.57 page 기반 페이지네이션에 비해 약 16배 성능개선, Index 적용 전에 비해 2.18배 성능개선이 이루어졌다.
왜 그럴까?
지금 생각해보니 Page기반 Pagination은 결국 Vote Ratio 기준으로 정렬하는 시간이 줄어들 뿐이지 n 페이지까지 숫자를 세어야 한다는건 똑같다. 하지만 Cursor 기반 페이지네이션은 Cursor까지 인덱스를 타고가서 거기서부터 size만큼 들고오면 되기 때문에 압도적으로 성능이 좋을 수 밖에 없다.
