#245 [feat] 최적의 회의 시간 알고리즘 QueryDsl로 마이그레이션

[KWY0218]

✒️ 관련 이슈번호

• Closes [feat] 최적의 회의 시간 query dsl jpa로 이전 #245

Key Changes 🔑

1. 내용
   • QueryDsl을 활용하여 최적의 회의 시간 알고리즘 수정

To Reviewers 📢

이전 알고리즘 방식에서는 쿼리가 아래와 같이 실행되었습니다.

• 회의 정보를 불러오는 SELECT 쿼리 1 번 실행

• 회의에 참여한 총 인원을 불러오는 SELECT 쿼리 1번 실행

• 총 AvailableDate 데이터를 불러오는 SELECT 쿼리 1번 실행

• 유저 N 명당 select 쿼리 N번 실행 (N ≥ 1)

• AvailableDate 데이터 M개 당 전체 TimeBlock 데이터를 불러오는 SELECT 쿼리 M번 실행 (1≤ M ≤ 7)

• TimeBlock 데이터 K개 당 TimeBlockUser SELECT 쿼리 K번 실행 (1≤ K ≤ 259)

  AvailableDate 당 37개의 TimeBlock이 생성될 수 있으므로 최악의 경우 37 * 7 = 259 개의 TimeBlockUser 레코드가 생긴다.

그래서 최악의 경우 1 + 1 + 1 + N + 7 + 259 , 즉 N + 266 개의 쿼리가 실행됩니다.

---

쿼리 수를 줄이기 위해서 알고리즘 일부를 수정했습니다.

• 알고리즘 내부에서 TimeBlock users를 사용하지 않고 users의 size만 필요하기 때문에 users를 구하기 위해 K번의 쿼리를 실행하지 않는 대신에 groupBy를 통해서 users의 size 값을 구한다.
• 최적, 차선의 회의 시간대를 3개 구한 후, 3개의 회의 시간대에 참여할 수 있는 users를 따로 구한다.

이러한 알고리즘 방식을 통해서 쿼리가 아래와 같이 개선되었습니다.

• 회의 정보를 불러오는 SELECT 쿼리 1 번 실행
• 회의에 참여한 총 인원을 불러오는 SELECT 쿼리 1번 실행
• 총 AvailableDate 데이터를 불러오는 SELECT 쿼리 1번 실행
• AvailableDate 데이터 M개 당 총 TimeBlock을 불러오는 SELECT 쿼리 M번 실행 (1≤ M ≤ 7)
• 최적, 차선의 회의 시간에 참여하는 User를 불러오는 SELECT 쿼리 3번 실행

그래서 최악의 경우 1 + 1 + 1 + 7 + 3 , 즉 13 개의 쿼리가 실행되며, 최소 7개의 쿼리가 실행됩니다.

[sohyundoh]

오 최적에서 찾는 방법 좋네요! 저도 시간표 로직 queryDsl로 마이그레이션 검토해보겠습니다!