쿼리 횟수 및 메모리 최적화

[jaylovegood]

✨ Feature PR (to dev)

🧪 로컬 테스트 여부 (작업자 체크)

• 로컬에서 Swagger 혹은 테스트 코드로 동작을 확인했습니다.

📄 documentation 최신화 여부

변경사항과 관련된 API의 swagger documentation이 실제 동작과 일치하는지 확인합니다.

• (작업자) 확인하였습니다.
• (리뷰어) 확인하였습니다.

📌 작업 내용(what & why)

반복문 혹은 중복 조회로 인한 불필요한 쿼리 횟수를 줄이는 작업과, 메모리에 불필요하게 많은 데이터를 로드하던 부분에서 딱 필요한 만큼만 불러오도록 하는 메모리 최적화를 동시에 진행하였습니다. 쿼리 횟수를 줄여 처리 처리속도가 개선되면 간접적으로 메모리 부하도 줄어들 것으로 기대합니다.

EventService

• getDetail(): 대기 순번 계산 시 전체 WAITLISTED 로드 대신 window function 쿼리로 1행만 조회 [쿼리 횟수 최적화]
• getDetail(): CONFIRMED 전체 로드 후 take(5) 대신 Pageable.ofSize(5)로 DB에서 5행만 반환 [메모리 최적화]
• getDetail(): createdBy, requesterId 각각 findById 2회 → findAllById 1회로 통합 [쿼리 횟수 최적화]
• getMyEventsInfinite(): 이벤트 N개 × count 2회(2N 쿼리) → countByEventIdsAndStatuses 배치 2회로 감소 [쿼리 횟수 최적화] - delete(): 전체 registration 로드 후 애플리케이션 filter → findByEventIdAndStatusIn으로 DB 측 필터링 [메모리 최적화]

RegistrationService

• getRegistrationInformation(): 전체 WAITLISTED 로드 후 indexOfFirst → window function 쿼리로 1행만 조회 [메모리 최적화]
• reconcileWaitlist(): 전체 대기자 로드 대신 Pageable.ofSize(available)로 승격 대상만 로드 [메모리 최적화]
• reconcileWaitlist(): 루프 내 findById N회 → findAllById 배치 처리 1회 [쿼리 횟수 최적화]
• create(): host·user findById 최대 3회 → findAllById 1회로 통합 [쿼리 횟수 최적화]
• create(): countByEventIdAndStatus(WAITLISTED) 2회 중복 → 1회 계산 후 재사용 [쿼리 횟수 최적화]

🔥 관련 이슈

• closes 쿼리 수 줄이기 #241

[uykhc]

우선 최적화하시느라 고생하셨습니다!
코드 확인해봤는데

1. 이벤트 상세/단건 조회 쪽
   findWaitlistPositionsByRegistrationPublicIds 사용 → created_at, registration_public_id
   • EventService.kt
   • RegistrationService.kt

2. 내 신청 목록 쪽
   findWaitlistPositionsByEventIds 사용 → created_at, id
   • 쿼리: RegistrationRepository.kt
   • 사용처: RegistrationService.kt

대기순번 산정할 때 정렬 기준 중 tie break 기준이 달라 엔드포인트마다 순번이 다르게 보일 여지가 있는 것 같습니다. registration_public_id는 생성 순서와 무관하니까 id(registration id)로 통일하는 것이 좋아보입니다!