-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor#112 어드민용 기수순 유저 조회 추가 #113
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생하셨어요! 추가적인 방법 적어뒀습니다.
그리고 NAME_ASCENDING의 경우도 현재 성능 최적화가 안된 상태로 있을거에요! 두 가지 조회 방식을 같이 작업해주시면 좋을 것 같아요
return userGetService.findAll().stream() | ||
.sorted(Comparator.comparingInt((user -> (StatusPriority.fromStatus(user.getStatus())).getPriority()))) | ||
.map(user -> { | ||
List<UserCardinal> userCardinals = userCardinalGetService.getUserCardinals(user); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
user 수 만큼 UserCardinals를 조회할 때 반복 쿼리가 많이 나갈 것 같아요!
조회해온 User 만큼의 UserCardinals를 한 번에 조회해서 Map으로 캐싱을 해두고, 그 데이터로 정렬을 해보는 것은 어떨까요?
그렇게 되면 쿼리는 UserList 조회, UserCardinals 조회 2번으로 해결할 수 있고, 메모리 위에서 정렬을 하니 속도가 증가할 것 같아요
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
강혁님이 이미 좋은 방향으로 리뷰를 남겨주시긴 했는데,
저도 현재 방식이 userGetService.findAll()을 통해 모든 사용자를 가져온 뒤,
각 사용자마다 userCardinalGetService.getUserCardinals(user)를 호출하는 방식이기 때문에
사용자 수가 많아질수록 N+1 문제가 발생할 가능성이 커보입니다
한 번의 쿼리를 날려줘서 모든 UserCardinal을 가져온 다음에,
Map으로 캐싱하여 조회하는 아래의 방법으로 최적화가 가능할거같아서, 아래의 방식도 참고해주시면 좋을거같아용
Map<Long, List<UserCardinal>> userCardinalMap = userCardinalGetService.getAllUserCardinals()
.stream()
.collect(Collectors.groupingBy(userCardinal -> userCardinal.getUser().getId()));
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생하셨습니다 !
if(orderBy.equals(CARDINAL_DESCENDING)){ | ||
|
||
return userCardinalMap.entrySet() | ||
.stream() | ||
.sorted(Comparator | ||
.comparingInt(((Map.Entry<User, List<UserCardinal>> entry) -> (StatusPriority.fromStatus(entry.getKey().getStatus())).getPriority())) | ||
.thenComparing(entry -> entry.getValue().stream() | ||
.map(uc -> uc.getCardinal().getCardinalNumber()) | ||
.max(Integer::compare) | ||
.orElse(-1), Comparator.reverseOrder())) | ||
.map(entry -> { | ||
List<UserCardinal> userCardinals = userCardinalGetService.getUserCardinals(entry.getKey()); | ||
return mapper.toAdminResponse(entry.getKey(), userCardinals); | ||
}) | ||
.toList(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생하셨습니다 !
PR에 적어주신게 ACTIVE 먼저, 그 다음에 WAITING, LEFT 순서대로 조회하는 방식을
말씀해주신게 맞다면,
" 현재 활동 중인 기수" 를 어드민 페이지에서 관리하기 위함이니까 ACTIVE 상태인 유저들이 맨위에 오도록 하는게 맞을거같다는 생각에 저는 현재 구현된 순서가 맞아보입니다
추가적으로 개인적인 생각은 LEFT 상태인 유저의 조회가 필요없다면 빼고 조회하는게 좋을거같고,
만약 필요하다면 추후에 ACTIVE, WAITING, LEFT 를 체크박스 형태로 체크해줘서, 상태를 선택해서
조회 조건에 추가하여 검색 ? 조회? 하는 방식도 좋아보여용
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
넵! 추후 고도화 과정으로 그부분도 하면 좋겠네요
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생하셨어요!
PR 내용
PR 세부사항
관련 스크린샷
다음은 28명의 유저를 기수순으로 조회한 결과입니다.
베이스는 status를 사용했습니다
주의사항
체크 리스트