refactor: 팔로잉 소식 조회 쿼리 성능 개선

[penrose15]

🌱 관련 이슈

• close ♻️ 팔로잉 소식 조회 성능 개선 #421

📌 작업 내용 및 특이사항

• 팔로잉 소식 조회 시 firstResult/maxResults specified with collection fetch; applying in memory 라는 경고 로그가 발생했습니다.
  

• 이는 oneToMany관계에서 fetch join 을 걸고, 페이징 처리를 하려 할 때 발생하는 문제로 조회한 모든 데이터를 메모리에 올린 후 페이징을 한다는 뜻입니다. (10개의 데이터만 페이징 해서 가져와야 하는데 100개를 다 들고 온 다음 앞의 10개를 자른다는 뜻입니다. )

• 이를 해결하기 위해 memory와 oneToMany 인 stroke, image를 fetchJoin에서 제외하였습니다. (Batch Size 가 지정되어 있어 in 절로 해당 stroke, image를 조회하게 됩니다.)

결과

k6으로 성능 테스트를 해본 결과입니다.

개선 전 성능입니다.

개선 후 성능입니다.

📝 참고사항

• 커밋 내용 중 memory의 주인인 member를 followingMemoryLog에 추가하여 join depth를 줄여 성능 개선을 해보려 하였으나 큰 변화는 나타나지 않아 다시 롤백했습니다.

---

24.09.23 수정

• 팔로우 알림(followLog)에서처럼 followingMemoryLog에도 Member(소식 받는 사람)를 N:1 연관관계로 추가하는 방안을 고려하였으나, 다음과 같은 이유로 적용하지 않았습니다.

1. 다중 삽입/삭제:
   followingMemoryLog에 member(소식 받는 사람) 칼럼을 추가할 경우, 수영 기록이 등록되거나 삭제될 때마다 해당 사용자를 팔로우하는 사람 수만큼 followingMemoryLog 레코드가 추가/삭제되어야 합니다.

2. 팔로우 시 다량의 데이터 추가 문제:
   사용자가 새로운 팔로우를 추가할 때, 해당 유저의 최근 100일간의 메모리 기록을 모두 followingMemoryLog에 추가해야 합니다.

3.또한 큰 성능의 차이가 나지 않았습니다. 아래는 각각 friend 로 조인하여 조회 하는 방법과 followingMemoryLog 에 member 칼럼을 추가 한 후 테스트 하였습니다. (50명 팔로우, 유저 당 100일 치 기록, 10 thread per 1sec, 100 loop)

followingMemoryLog에 member 칼럼 추가 전

followingMemoryLog에 member 칼럼 추가 후

따라서 쿼리 성능이 개선되지 않을 뿐만 아니라, 오히려 수영 기록 및 팔로잉 관련 CUD(Create, Update, Delete) 작업 성능이 저하될 것이라 판단되어 적용하지 않았습니다.

[github-actions]

Test Results

64 tests   64 ✅  2s ⏱️
17 suites   0 💤
17 files     0 ❌

Results for commit 8f5821e.

♻️ This comment has been updated with latest results.

[ywonchae1]

안 그래도 쿼리 삭제해야 한다고 말씀 드리려고 했는데 발견해 주셔서 감사합니다 !!

[ywonchae1]

이 방식은 왜 바꾼 건가요??

[penrose15]

이 편이 더 깔끔해 보여서 없애봤습니다. 다음 PR 에서 다른 Repository도 동일하게 적용해볼까 생각하고 있습니다.