[REFAC] 게시글 공감 기능 다중 선택 허용에 따른 목록 조회 성능 최적화

[gogori6565]

📣 Related Issue

• close [REFAC] 게시글 공감 기능 다중 선택 허용에 따른 목록 조회 성능 최적화 #121

📝 Summary

사용자당 다중 공감을 허용하는 비즈니스 로직을 구현하며 데이터 모델을 M:N 구조로 설계하자, 게시글 목록 조회 시, 각 게시글마다 연관된 다수의 공감 데이터를 개별적으로 조회하는 N+1 문제가 발생하였습니다. 이로 인해 데이터 양에 비례하여 쿼리 수가 급격히 증가하고, 응답 시간이 선형적으로 늘어나는 성능 병목을 확인했습니다.

이에 따라 루프 기반의 개별 조회 방식을 In-clause를 활용한 Batch Fetching 전략으로 리팩토링하고, Java Stream API를 이용한 메모리 매핑을 적용하여 실행 시간을 최적화하였습니다.

[성능 개선 수치 (평균치 비교)]
Size 10 : (개선 전) 1604ms -> 401ms(최저 237ms) = 약 75% 감소
Size 20 : (개선 전) 2686ms -> 494ms(최저 441ms) = 약 82% 감소

+) 추가 Refactoring 사항: Post의 content 데이터 타입이 String -> varchar(255)로 255자만 들어가고 있어, 임의 TEXT 타입 지정으로 기획에서 정의한 2000자를 기입할 수 있도록 수정하였습니다.

📬 Reference

[실제 개선 전/후 측정 시간]
개선 전:
메서드 실행 시간 [getPostAll]: 1802ms
메서드 실행 시간 [getPostAll]: 1537ms
메서드 실행 시간 [getPostAll]: 1474ms
메서드 실행 시간 [getPostAll]: 2970ms (size: 20으로 시도)
메서드 실행 시간 [getPostAll]: 2500ms (size: 20으로 시도)
메서드 실행 시간 [getPostAll]: 2588ms (size: 20으로 시도)

개선 후:
메서드 실행 시간 [getPostAll]: 652ms
메서드 실행 시간 [getPostAll]: 314ms
메서드 실행 시간 [getPostAll]: 237ms
메서드 실행 시간 [getPostAll]: 578ms (size: 20으로 시도)
메서드 실행 시간 [getPostAll]: 464ms (size: 20으로 시도)
메서드 실행 시간 [getPostAll]: 441ms (size: 20으로 시도)

[rhkr8521]

고생하셨습니다.